Developer'lara sorduğunda AI onları %20 hızlandırıyor. Kronometre tuttuğunda %19 yavaşlatıyor. Aynı insanlar, aynı işler.
Ekibine Cursor aldın, Claude Code aldın. Herkes memnun. Aylık fatura geliyor ve patronun soruyor: bu para neye gidiyor? Elinde ya hiçbir şey var ya da "ekip memnun" cümlesi. İkisi de yeterli değil.
Son bir yılda bu soruya cevap arayan ciddi araştırmalar birikti. Hepsini okuduk. Kısa özet: AI'ın ekibine ne yaptığını ölçmek mümkün, ama bugün çoğu ekibin baktığı yerden bakarak değil.
Utilization
Araç gerçekten kullanılıyor mu, kim kullanıyor?
Impact
İşe yarıyor mu, neyi bozuyor?
Cost
Kazanılan saat, harcanan paradan büyük mü?
Hislere neden güvenemezsin
METR'in 2025 yazında yayımladığı randomize deney, bu konuda elimizdeki en rahatsız edici veri. 16 deneyimli açık kaynak geliştirici, kendi tanıdıkları repo'larda, 246 gerçek issue üzerinde çalıştı. Yarısında AI kullandılar, yarısında kullanmadılar.
- Başlamadan önce "AI bizi %24 hızlandırır" dediler.
- Ölçüm sonucu: AI ile işleri %19 daha yavaş bitirdiler.
- Deney bittikten sonra bile "%20 hızlandık" sandılar.
Aynı dönemde DORA'nın yaklaşık 5.000 kişilik anketinde katılımcıların %80'inden fazlası "AI verimimi artırdı" dedi. Ama aynı ankette %30'u AI'ın ürettiği kodun doğruluğuna güvenmediğini söyledi. İki cümle de doğru, ikisi de aynı kişilerden geliyor.
METR çalışması 2025 başındaki araçlarla yapıldı. O günden beri modeller de harness'lar da değişti. Bu bulguyu "AI yavaşlatır" diye okuma. Dayanıklı olan kısım şu: algı, güvenilir bir ölçüm birimi değil. Kendi ekibinde de olmayacak.
Kazanç herkese eşit dağılmıyor
"AI ekibi %30 hızlandırır" cümlesi tek başına anlamsız. Stanford'un yaklaşık 100.000 developer üzerinde yürüttüğü saha çalışması, kazancın nereye dağıldığını gösteriyor — ve dağılım hiç homojen değil.
| İş tipi | Karmaşıklık | Kazanç aralığı |
|---|---|---|
| Greenfield (sıfırdan) | Düşük | ~%30–40 |
| Greenfield | Yüksek | ~%10–15 |
| Brownfield (mevcut kod) | Düşük | ~%15–20 |
| Brownfield | Yüksek | ~%0–10, bazı ekiplerde negatif |
Eşleştirilmiş 46 ekipte medyan kazanç ~%10 çıkmış. Ama üst çeyrek ile alt çeyrek arasındaki fark dört katına çıkmış. Yani ortalama, senin ekibin hakkında neredeyse hiçbir şey söylemiyor.
Bu veriler yayımlanmış bir makaleden değil, bir konferans konuşmasından geliyor. Aynı slaytı aktaran kaynaklar uç hücrelerde farklı rakamlar veriyor. Kesin sayı değil, aralık olarak oku.
Deneyim tarafında da benzer bir ayrışma var. Microsoft, Accenture ve bir Fortune 100 şirketinde toplam 4.867 developer ile yapılan kontrollü deneylerde tamamlanan task sayısı ortalama %26 arttı. Ama Microsoft kolundaki kırılıma bakınca: kısa kıdemli developer'larda kazanç %21–40, uzun kıdemlilerde %7–16.
Hızın bir faturası var
DORA 2025'in merkezi tezi net: AI bir amplifikatör. Var olanı büyütüyor. İyi ekip daha iyi, dağınık ekip daha dağınık oluyor. Veri de bunu destekliyor — AI adoption ile delivery throughput arasında pozitif, delivery stability ile negatif korelasyon var.
Faros AI'ın 22.000 developer ve 4.000'den fazla ekipten iki yıllık telemetrisi, bu iki tarafı yan yana koyuyor:
İyileşenler
- Epic / developer: +%66
- Task throughput: +%33,7
- PR merge oranı: +%16,2
Bozulanlar
- Code churn: +%861
- Incident / PR oranı: +%242,7
- Review'suz merge edilen PR: +%31,3
Senior engineer vergisi
Aynı veri setinde en çarpıcı kısım review tarafı. İlk review'a kadar geçen medyan süre %156,6 artmış. Ortalama code review süresi %199,6, review'da geçen medyan süre %441,5 artmış.
AI kodu yazmayı ucuzlattı, okumayı ucuzlatmadı. Darboğaz klavyeden review'a taşındı.
— Brick perspektifiÖlçüm panonda review süresi yoksa, yanlış yeri izliyorsun demektir. Ekibin daha çok PR açıyor ama senior'ların takvimi doluyorsa, kazandığın zamanı başka bir yerden geri veriyorsun.
Peki ne ölçeceksin?
DX'in çerçevesi pratikte en işe yarayanı: kullanım, etki ve maliyet. Üçünü birden takip etmezsen hikâyenin sadece hoşuna giden kısmını görürsün.
1. Kullanım
- Günlük ve haftalık aktif kullanıcı
- AI destekli PR yüzdesi, AI kaynaklı commit oranı
- Agent'lara devredilen task sayısı
Shadow AI'ı hesaba kat. Kişisel lisansla araç kullananları saymazsan adoption rakamın olduğundan düşük, kazanç rakamın olduğundan yüksek çıkar.
Referans için: DX'in 435 şirket ve 135.000'den fazla developer'ı kapsayan verisinde adoption %91. Merge edilen kodun AI kaynaklı oranı 2025'in son çeyreğinde %22, 2026'nın ilk çeyreğinde %27,4 — günlük kullananlarda %30,8.
2. Etki
Doğrudan ölçebileceğin şey developer başına haftalık kazanılan süre. Benchmark ortalama 3,6 saat; günlük kullananlarda 4,1. Dolaylı metrikleri — PR throughput, change failure rate, kod bakım yapılabilirliği — tek başına değil, birlikte oku.
PR throughput için gerçekçi beklenti %7–15. Satıcıların anlattığı 3–10 kat değil. Bu aralığı beklentini kalibre etmek için kullan.
3. Maliyet
2026'da developer başına aylık toplam AI harcaması $200–600 bandında. Net süre kazancı = kazanılan saat − AI maliyeti. Bu çıkarma işlemini yapmadığın sürece ROI'den bahsedemezsin.
Hangi metrik hâlâ anlamlı?
AI'ın bozduğu
- Commit ve PR sayısı
- Lines of code
- Deployment frequency, lead time
- Memnuniyet skorları
Hâlâ ayakta duran
- Time to recover (MTTR)
- Escaped defect rate
- İş ve müşteri sonuçları
Mantık basit: çıktı üretmek neredeyse bedava hale geldi. Hacim metrikleri artık "eksik ölçüm" değil, doğrudan yanıltıcı.
Ölçmediğin şeyi yönetemezsin. Yanlış ölçtüğün şeyi ise yanlış yönetirsin.
Ölçerken yapılan dört hata
Yanlış ölçüm, ölçmemekten daha kötü. Çünkü ona bakarak karar veriyorsun.
Metriği hedefe çevirmek
Gergely Orosz'un aktardığı bir vaka: bir şirket layoff sonrası verimlilik metriği olarak "AI destekli PR yüzdesi" ve haftalık PR sayısını belirliyor. Sonuç tahmin edilebilir — insanlar listede olmamak için metrikleri şişirmeye başlıyor. Aynı hafta üç farklı büyük şirketten developer'lar token kullanımının ölçüldüğünü ve "tokenmaxxing" yapıldığını yazdı.
Bir ölçüm hedef haline geldiğinde, iyi bir ölçüm olmaktan çıkar.
— Goodhart yasasıBireysel performans ölçmek
Bu metrikleri asla bireysel değerlendirmede kullanma. Ekip seviyesinde topla ve neden ölçtüğünü şeffaf anlat. Aksi halde ilk ölçtüğün şey ekibin güveni olur.
Baseline almadan başlamak
Anketi ve temel metrikleri araçları dağıtmadan önce al. İş akışı değiştikten sonra algısal ölçümleri geriye dönük yeniden üretemezsin. Bu geri alınamaz bir adım.
Öğrenmeyi hesaba katmamak
Anthropic'in 2026 Şubat'ında yayımladığı deneyde çoğunlukla junior 52 developer izlendi. AI ile çalışanlar sonraki kavrama testinde 17 puan düşük skor aldı (%50'ye karşı %67). En büyük fark debugging sorularındaydı. Hız avantajı ise istatistiksel olarak anlamlı çıkmadı.
AI'ı anlamak için kullananlar — soru sorup açıklama isteyenler — bilgiyi çok daha iyi tuttu. Fark araçta değil, kullanım biçiminde. Junior'ını en çok hızlandıran araç, aynı zamanda onun senior olmasını en çok geciktiren araç olabilir.
Şirketler pratikte ne ölçüyor?
| Şirket | Ne ölçüyor | Ne çıkmış |
|---|---|---|
| Dropbox | DAU/WAU, CSAT, kişi başı kazanılan süre, AI harcaması, change failure rate | AI kullananlar haftada %20 daha fazla PR merge ediyor; change failure rate düşmüş |
| Booking.com | Enablement programı + adoption ve throughput takibi | PR merge oranı %16 yüksek; change throughput +%31; adoption +65 puan |
| Microsoft | "Bad developer days" — sürtünme ve toil metriği | Incident mitigation süresi, meeting overhead |
| AI tarafından yazılan kod yüzdesi | ~%25 | |
| Webflow | AI kullanan ve kullanmayan PR throughput karşılaştırması | ~+%20 |
| 6 çokuluslu şirket | Onboarding süresi (10. PR'a kadar geçen gün) | Günlük kullananlarda 91 gün → 49 gün |
İşe yarayan örneklerin ortak noktası dikkat çekici: Dropbox ve Booking.com'un ikisinde de bir enablement programı var. Aracı dağıtmakla iş bitmiyor. DORA'nın amplifikatör tezi tam da bu.
Bu tabloların hepsi "AI kullanan ve kullanmayan" karşılaştırması — yani korelasyon, nedensellik değil. Zaten hızlı olan developer'lar aynı zamanda AI'ı erken benimseyen developer'lar olabilir. Kendi verini yorumlarken de bunu aklında tut.
30 günde ne yapabilirsin
- Baseline al, bu hafta. PR throughput, cycle time, change failure rate ve kısa bir developer anketi. Araç dağıtmadan önce.
- Üç boyutu birden takip et. Kullanım, etki ve maliyet. Tek boyut her zaman yanıltır.
- Bir "bozulma" metriği ekle. MTTR veya escaped defect rate, hız metriğinin tam yanında dursun.
- Ekip seviyesinde ölç, kişi seviyesinde asla. Ve neden ölçtüğünü açıkça söyle.
- Gerçekçi bekle. %7–15 throughput artışı iyi bir sonuç. 3 kat bekliyorsan yanlış soruyu soruyorsun.
AI'ın ekibini hızlandırıp hızlandırmadığını bilmiyorsan, sorun AI'da değil. Ölçüm sisteminde. Ve o sistemi kurmak için token'a değil, iki haftalık disipline ihtiyacın var. 🧱
