2026 Rails Anketi: 15 Yıl Sonra Aynada Kendimi Görmek
Planet Argon'un iki yılda bir yaptığı Rails Community Survey'in 2026 sonuçları çıktı. 80 ülkeden 1.800 kişi katılmış. Okurken bir anketten çok bir aynaya bakıyormuş gibi hissettim. Rakamların çoğunda ya kendi 15 yılımı, ya Teamtailor'da data migration takımında geçirdiğim 5 yılı, ya da akşamları Foxance'a ayırdığım saatleri gördüm. O yüzden bu yazı bir özetten çok, anketin bölümleri üzerinden kendi tecrübemi anlatma denemesi.
Anketin tamamı burada: railsdeveloper.com/survey/2026
Demographics: Hepimiz büyüdük
Katılımcıların %69'u 10 yıldan fazla Rails yazıyor. 4 yıldan az tecrübesi olanlar sadece %8. Ben de o %69'un içindeyim. Rails'e başladığımda Rails 3 yeni çıkmıştı, asset pipeline bir devrimdi, Heroku'ya git push yapmak sihir gibiydi.
Bu tablonun sevindirici bir tarafı var: insanlar Rails'i bırakmıyor. Ama aynı tablonun içinde bir alarm da çalıyor. Yeni gelen yok denecek kadar az. Rails Foundation'dan Amanda Perino'nun dediği gibi, yeni başlayanlar belki Rails'i duyuyor ama topluluğu bulamıyor. Ruby Türkiye'yi kurarken de tam bu boşluğu düşünüyordum. Türkiye'de Rails öğrenmek isteyen birinin bugün Türkçe olarak gidip soru sorabileceği, takılabileceği yer sayısı bir elin parmaklarını geçmiyor. Gerçi soru sormaya da artık gerek kaldı mı, onu da bilmiyorum 🤷♂️
Teams & Responsibilities: Rails kolay, domain zor
Ankette beni en çok vuran soru şuydu: "Yeni gelen geliştiriciler en çok nerede zorlanıyor?" Cevapların %66'sı aynı yeri gösteriyor: domain modeli ve iş mantığı. ActiveRecord kalıplarında zorlananlar sadece %11.
5 yıldır işim tam da bu farkın ortasında geçiyor. Data migration takımında bir müşterinin eski sistemindeki adayları, ilanları ve CV'lerini Teamtailor'a taşıyoruz. Bir CSV'yi okuyup insert_all yapmak işin en kolay kısmı. Zor kısım, "status" kolonunda yazan "Hired - pending" değerinin bu müşteri için ne anlama geldiğini çözmek. Ya da 140 bin satırlık bir dosyada e-posta adresi olmayan ama CV'si olan 300 adayı ne yapacağına karar vermek. Bu soruların hiçbiri Rails Guides'ta yok.
Lokalde gerçekçi veriyle çalışma sorusu da aynı yere çıkıyor. %42'si seed dosyası tutuyor, %29'u anonimleştirilmiş production verisi çekiyor. Sadece %16'sı "seed verisi bug reproduce etmeyi zorlaştırıyor" demiş. Bu oran bana inandırıcı gelmedi. Bir import hatasını seed verisiyle yeniden üretmeye çalıştığım her seferde, hatanın asıl sebebinin müşterinin verisindeki tek bir garip karakter olduğunu sonradan öğrendim.
Ekiplerin büyümesi de yavaşlamış. 2022'de ekiplerin %54'ü büyüyordu, bugün %30'u. Tek kişilik ekipler %19. Bunu Rails'in gerilemesi olarak okumuyorum. Daha küçük ekipler daha fazla iş çıkarabiliyor ve bunun bir kısmı Rails'in her zaman savunduğu şeyden, bir kısmı da son iki yılda hayatımıza giren AI araçlarından geliyor.
Ruby & Rails Version Updates: Upgrade bir kültür meselesi
Ruby 4.x kullananlar şimdiden %49. İşte Ruby 4 kullanıyoruz ve geçiş beklediğimden çok daha sancısız oldu. Rails'te 8.1 %64 ile önde. Ama uygulamaların %44'ü 10 yaşından büyük ve %11'i hâlâ Rails 6.x'te.
Upgrade yapmama sebepleri 2024'le aynı: zaman yok (%55), öncelik değil (%48). FastRuby'den Ernesto Tagwerker bunun teknik değil kültürel bir sorun olduğunu söylüyor ve haklı. 15 yılda öğrendiğim en net şey şu: küçük ve sık upgrade her zaman ucuzdur, büyük ve nadir olan her zaman pahalı. Bir gem'i küçük bir sürüm atlattığınızda bile başınıza neler gelebileceğini gördüm. Bir keresinde connection_pool 3.0'a geçti ve kullandığımız Sidekiq sürümüyle uyumsuz olduğu için scheduler sessizce çöktü. Bunu fark etmek, düzeltmekten çok daha uzun sürdü. Sık upgrade yapan bir ekip bu tür sürprizleri küçükken yakalıyor.
Version manager tarafında mise 2024'te %2'ydi, bugün %37.6 ve rbenv'in nefesini ensesinde hissettiriyor. İtiraf edeyim: ben hâlâ RVM kullanan %17'lik azınlıktanım. Her yeni projede GEM_HOME ile bir kez boğuşuyorum ve her seferinde "bu sefer mise'ye geçiyorum" diyorum. Bu anket o bahaneyi elimden aldı.
Configuration: Monolith kazandı, mobilde ise native
2018'de katılımcıların %62'si monolith kullanıyordu. 2026'da bu oran %80.7. Mikroservis kullananlar %3.7'ye inmiş. Mikroservis heyecanının zirvede olduğu yılları hatırlıyorum. Herkes uygulamasını parçalara bölüp sonra o parçaların birbirleriyle nasıl konuşacağını çözmeye çalışıyordu. Topluluk sessiz sedasız geri döndü. Bugün benim için ideal yapı hâlâ iyi organize edilmiş bir monolith ve yanında gerçekten ayrı yaşaması gereken birkaç küçük servis. Import servisimiz bunun bir örneği.
Background job tarafında Sidekiq %61 ile lider, ama Rails 8 ile varsayılan gelen Solid Queue iki yılda %35'e ulaşmış. İki dünyayı da kullanan biri olarak ikisinin farklı problemleri çözdüğünü düşünüyorum. Kişisel projemde ek bir servis kurmadan job çalıştırmak harika. İşte ise binlerce satırlık chunk'ları işleyen job'lar, bellek sınırları ve bağlantı havuzları söz konusu olduğunda Sidekiq'in olgunluğuna güveniyorum.
Mobil kısım benim için en kişisel olanıydı. Katılımcıların %63'ü sadece web yapıyor. Mobil uygulaması olanların %33'ü tamamen native, %20'si Hotwire Native kullanıyor. Foxance'ın iOS uygulamasına Hotwire Native ile başladım. Web görünümlerini bir native kabuğun içine koymak ilk hafta büyülü geliyordu. Sonra her ekranda biraz daha "neredeyse native" hissine takıldım: geçişler, klavye davranışı, liste kaydırma. Sonunda uygulamayı Swift ile baştan yazmaya karar verdim, Rails tarafı da JSON API oldu. Ankette native'in Hotwire Native'in önünde çıkması bana sürpriz olmadı. Hotwire Native hızlı başlamak için mükemmel, ama App Store'da bir kullanıcının gözünden bakıldığında fark kapanmıyor.
Learning: Bir şey yap ve yayına al
Katılımcıların ilk iki yılında en çok işe yarayan yöntem kendi uygulamasını yapıp yayına almak (%39). İkinci sırada mevcut bir uygulamada çalışmak var (%25). Ben de Rails'i tutorial bitirerek değil, yarım bıraktığım bir sürü yan projeyle öğrendim. Hâlâ öyle öğreniyorum. Foxance da aslında yeni şeyleri denediğim bir laboratuvar.
Katılımcıların sadece %4'ü ilk yıllarında AI ile öğrenmiş, çünkü çoğumuz başladığımızda böyle bir şey yoktu. Ama bugün "en çok neyden faydalanıyorsun" sorusunda AI araçları %32 ile kitapların hemen arkasında. 2028 anketine katılacak yeni bir geliştiricinin ilk öğretmeni büyük ihtimalle bir agent olacak. Rails bu konuda şanslı. Convention over configuration, bir agent'ın "bu dosya nerede olmalı" sorusunu tahmin etmesine gerek bırakmıyor.
Online topluluklara katılım ise %40.5'ten %34.8'e düşmüş. Bu, Ruby Türkiye için hem kötü bir haber hem de bir görev tanımı. Ama hala canlı tutmaya çalıştığımız başka bir yer var. Biraz olsun insan dokunuşunu hissetmek istediğimiz yer. rubyforum.org
Gems & Open Source: devise'ı seviyoruz, devise'dan nefret ediyoruz
En sevilen gem listesinin birincisi devise. En sinir bozucu gem listesinin birincisi de devise. Bu kadar Rails'e özgü bir sonuç olamazdı. Herkesin bir devise hikâyesi var. Benimki, bir sürü override'ın arasında kaybolup sonunda "keşke bunu kendim yazsaydım" dediğim bir proje. Rails 8'in authentication generator'ı tam bu yüzden önemli. Artık yeni projelerimde devise'a hiç uğramıyorum.
Listenin asıl sürprizi 4. sıraya yerleşen ruby_llm. Ruby'nin AI dünyasında Python'un gölgesinde kalmak zorunda olmadığının en iyi kanıtı. LLM entegrasyonu yazarken Ruby'nin okunabilirliği gerçekten fark yaratıyor.
Bir de açık kaynak katkısı meselesi var: katılımcıların %50'si "nadiren" ya da "hiç" katkı vermiyor. Ben de bu yarının içindeyim ve bundan gurur duymuyorum.
JavaScript + Rails: Hotwire ana akım oldu, React gitmedi
Turbo %65, Stimulus %59. Hotwire artık bir alternatif değil, Rails'in kendisi. Ama React hâlâ %40'ta ve bu gerçekçi bir tablo. Olgun ürünlerde ayrı bir frontend katmanı yaşamaya devam ediyor ve kısa vadede de bırakacak gibi durmuyor.
İlginç olan şu: "uygulamanın en kırılgan yeri neresi" sorusunda frontend %25 ile birinci. Aynı ankette katılımcıların %32'si hiç JavaScript testi yazmıyor. Bu iki rakam yan yana konunca ortaya çıkan tabloyu açıklamaya gerek yok.
Code Integrity & Security: Kırılganlık listesi, benim iş tanımım
RSpec %75, RuboCop %87, Brakeman %64. Bunlar artık neredeyse standart. Katılımcıların %26'sı test/kod oranını bilmiyor ki bu da dürüst bir cevap.
Beni asıl ilgilendiren "uygulamanız nerede kırılgan" sorusuydu. Cevaplara bakınca kendi iş tanımımı okuyor gibi oldum: üçüncü parti API entegrasyonları (%18), background job'lar (%16), dosya yüklemeleri (%6). Data migration'da işin büyük kısmı tam bu üçünün kesiştiği yerde geçiyor. Bu alanda öğrendiğim en pahalı ders şu oldu: retry: false ile işaretlenmiş bir job, bellek yetmediği için worker öldüğünde iz bırakmadan kayboluyor. Kaybolan tek bir chunk da bütün import'u "bekliyor" durumunda sonsuza kadar kilitleyebiliyor. O günden beri bir job'ın idempotent olması ve worker ölümünden sağ çıkması, benim için o job'ın ne kadar güzel yazıldığından çok daha önemli.
Test tarafında RSpec'ten Minitest'e geçenlerin oranı (%5.5) tersi yönde geçenlerden (%1.9) neredeyse üç kat fazla. İşte RSpec yazıyorum ama kişisel projelerde Minitest'e ve sade model/request testlerine döndüm. Headless Chrome'un tuş vuruşlarını kaçırdığı flaky system testlerle saatlerimi kaybettikten sonra, browser testlerinin verdiği güvencenin maliyetine değmediğine karar verdim.
Deployment & DevOps: Kamal her şeyi değiştirdi
Bu bölüm anketin en hareketli bölümü. Kamal 2024'te %2.4'tü, bugün %23.8. Rails 8'in onu varsayılan yapması, son yıllardaki en etkili kararlardan biri olabilir. Hetzner %18'e, bare metal %15'e çıkmış. Katılımcıların %10.8'i son iki yılda Heroku'dan ayrılmış, %12.5'i ayrılmayı planlıyor.
Heroku ile ilişkim aşk-nefret karışımı. 15 yıl önce bana deploy etmeyi sevdiren platform Heroku'ydu. Bugün ise sınırlarına çarptığımda her çözümün "bir üst plana geç" olması canımı sıkıyor. En öğretici anım, küçük bir Redis planının 20 bağlantı limitinin, birkaç worker dyno'nun Sidekiq havuzlarıyla çarpılınca nasıl bir anda dolduğunu ve tüm worker'ların crash loop'a girdiğini izlediğim gündü. O gün "PaaS rahat, ama limitlerini bilmen gerekiyor" dersini aldım. İnsanların Kamal ve Hetzner'a kaçmasının bir sebebi de bu: kendi sunucunuzda en azından limitleri siz belirliyorsunuz.
GitHub Actions %55'ten %69'a çıkmış, günde birden fazla deploy yapanlar %41'e yükselmiş. CI tartışması fiilen bitti.
Databases: SQLite ciddiye alınıyor
PostgreSQL %84 ile tartışmasız lider ve öyle kalacak. Ama "tercih ettiğin veritabanı" sorusunda SQLite iki yılda %3.9'dan %7.3'e çıkmış. Birkaç yıl önce production'da SQLite kullandığını söyleyen biri gülünç bulunurdu. Bugün Rails 8 ile yeni bir projeye SQLite ile başlamak bana en mantıklı varsayılan gibi geliyor: tek sunucu, tek dosya, sıfır yönetim. Proje büyürse PostgreSQL'e geçmek dünyanın sonu değil.
Redis kullanımı ise Solid Queue ve Solid Cache'e rağmen %64'ten %76'ya yükselmiş. İlk bakışta çelişkili görünüyor, ama değil. Büyük uygulamalar Sidekiq'te kalıyor, yeni uygulamalar da Redis'i cache ve rate limit için kullanmaya devam ediyor. Redis ölmüyor, sadece zorunlu olmaktan çıkıyor.
OS, Editors & Servers: Editör eriyor
macOS %75, VS Code %44.7, Puma %92. Bu rakamlarda sürpriz yok. Sürpriz Zed'in (%10.2) ve Cursor'ın (%5.4) ilk kez listeye girmesi.
Ama bence bu sorunun kendisi eskidi. Günlük akışımda kodun büyük kısmını artık terminalde yada Claude Code desktop içinde geçiyorum. Editörü hiç açmadığım günler var. Claude Desktop zaten terminali veriyor, terminali bile açmaya gerek kalmayabilir 🤭
AI Adoption: Artık bir yan konu değil
Bu yılın yıldızı bu bölüm. Ekiplerin %57'si AI'ı düzenli olarak işine entegre etmiş, sadece %3'ü hiçbir AI aracı kullanmıyor. Araçlarda Claude Code CLI %70 ile açık ara birinci, modellerde Claude Opus %55.
Bu rakamlar benim günlük hayatımın birebir fotoğrafı. Claude Code artık iş akışımın merkezinde. Ben daha az kod yazıyorum, daha çok tarif ediyorum, gözden geçiriyorum ve karar veriyorum. Bu hafta işte AI ile bir import agent'ı prototipledim. Kullanıcı CSV'yi yüklüyor, agent dosyayı doğruluyor, sorunları tek tek soruyor ve onay aldıktan sonra import'u yapıyor. İki yıl önce bir çeyreğe yayılacak bir fikri birkaç günde çalışır hale getirmek, bu anketteki "AI beni daha yetkin yapıyor" diyen %74'ün neden orada olduğunu çok iyi açıklıyor.
Yine de katılımcıların %50'si AI'ın hızının yeteneklerinin değerini tehdit ettiğini düşünüyor. Bu kaygıyı anlıyorum ama paylaşmıyorum. AI kod yazmayı ucuzlattı, ama neyin yazılması gerektiğini bilmeyi ucuzlatmadı. Bir agent CSV'yi okuyabilir. "Bu müşteri için 'Hired - pending' aslında reddedilmiş aday demek" bilgisini ise ona ancak o domain'de yıllarını geçirmiş biri verebilir. Anketin başında yeni geliştiricilerin en çok domain bilgisinde zorlandığını (%66) görmüştük. AI çağında bu zorluk ortadan kalkmıyor, değerli hale geliyor.
Bir de liderlik meselesi var. "Liderlik AI'ın etkisini görmezden geliyor" diyenler sadece %12. Yani şirketler AI'ı ciddiye alıyor. Asıl soru artık "kullanacak mıyız" değil, "nasıl düzgün kullanacağız".
The Future of Rails: %91
Katılımcıların %91'i Rails'i tercih ettiği server-side framework olarak görüyor, %72'si "kesinlikle katılıyorum" demiş. %77'si yeni geliştiricilere Rails öğrenmelerini öneriyor.
Bu rakamlara biraz şüpheyle bakmak lazım, çünkü Rails'i bırakanlar zaten bu ankete katılmıyor. Ama 15 yıl sonra hâlâ aynı framework'ü açtığımda heyecanlanabiliyorsam, bu %91'in bir kısmı da gerçek. Rails'in en büyük başarısı bence moda olmadan uzun ömürlü olabilmesi. Her yıl yeni bir framework "Rails'i öldürecek" diye ortaya çıktı. Rails hâlâ burada ve 8. sürümüyle belki de en iyi döneminde.
Nereye gidiyoruz?
15 yıl sonra bu ankete bakınca Rails'in olgunluk döneminin en iyi halinde olduğunu düşünüyorum. Rails 8; Kamal, Solid Queue, SQLite ve built-in authentication ile "tek kişi bir ürün çıkarabilir" iddiasını slogan olmaktan çıkardı. AI araçları da bu iddiayı ikiye katladı. Monolith'e dönüş, SQLite, kendi sunucunu yönetmek, flaky testlerden kaçmak... Hepsi aynı yöne işaret ediyor: daha az parça, daha az sürpriz. Rails'in 20 yıldır savunduğu şey buydu, topluluk sonunda buna geri döndü.
Endişem tek: topluluk yaşlanıyor. Rails'i seven çok insan var ama yeni nesli çekmekte zorlanıyoruz. Bunun çözümü Rails Foundation'dan çok yerel topluluklarda. Türkçe, güncel ve pratik Rails içeriği hâlâ çok az ve bu boşluk, Ruby Türkiye olarak doldurmak istediğimiz şeydi artık ben de bunu yapmak istemiyorum. AI ile zaten her şey yapılabilir bir hale geldi.
2028 anketi için birkaç tahminim var. O zaman açıp kaçının tuttuğuna bakacağım:
- Kamal %40'ı geçecek, Heroku %15'in altına inecek. Yeni projelerin varsayılan stack'i Kamal, ucuz bir VPS ve SQLite ya da PostgreSQL olacak.
- Solid Queue, yeni projelerde Sidekiq'i geçecek. Ama büyük ve eski sistemler uzun süre Sidekiq'te kalacak. Toplam kullanımda Sidekiq hâlâ birinci olacak.
- Tek kişilik ekipler %25'i aşacak. Rails 8 ile AI'ın birleşimi, eskiden 3–4 kişilik bir ekibin yaptığı işi tek kişiye yaptırabiliyor.
- "Upgrade için zamanımız yok" cevabı belirgin şekilde düşecek. Mekanik upgrade işi agent'lara geçecek. Ama kültürü değişmeyen ekipler yine geride kalacak.
- Editör sorusu ya kalkacak ya da tamamen değişecek. Agent'lar kodun büyük kısmını yazdığında hangi editörü kullandığımızın pek önemi kalmayacak.
- Mobilde ayrışma büyüyecek. Hotwire Native basit, içerik ağırlıklı uygulamalarda büyüyecek. Kullanıcı deneyiminin kritik olduğu ürünler ise benim Foxance'ta yaptığım gibi native'e ve Rails API'ye yönelecek.
- Değerli geliştiricinin tanımı değişecek. Kod yazma hızı fark yaratmayacak. Domain'i bilen, AI'ı yönlendirebilen ve sistemin nerede kırılacağını önceden görebilen geliştiriciler öne çıkacak.
Siz anketin hangi kısmında kendinizi buldunuz? Yorumlarda buluşalım 🤗
Comments ()