Kod satırı sayısı daha iyi bir halkla ilişkiler sorumlusu buldu
(curlewis.co.nz)- Geliştirici üretkenliği değerlendirmesi, kod miktarından çok müşteri değeri, gelir ve güvenilirlik gibi sonuç metrikleri ile yapılmalı
- Google, Anthropic, OpenAI ve Cursor’un son dönemdeki AI kodlama tanıtım rakamlarının tamamı, üretilen kod oranı ya da kod satırı sayısı gibi nicel iddialara odaklanıyor
- GitHub Copilot’ın geçmişteki %55 iş hızı artışı iddiası doğrulanabilir bir sonuçtu; ancak “AI tarafından yazılan kod oranı”, iyileşme olup olmamasından bağımsız olarak artabilir
- Gerçek araştırmalar karışık sonuçlar veriyor; Cui et al.’ın +%26 tamamlama oranından METR’in "%19 daha yavaş" bulgusuna ve sonraki geri dönüşüne, ayrıca şirketlerin %90’ının ölçülebilir etki görmediğini söyleyen ankete kadar, organizasyon düzeyindeki etki yaklaşık %10 seviyesinde
- AI benimsenmeli, ancak performans ölçümü DORA metrikleri, güvenilirlik, anlamlı değişiklik hızı, gelir ve müşteri değeri gibi doğrulanmış ölçütlere dayanmalı
Kod satırı metriğinin geri dönüşü
- 15 yıl önce bir SaaS şirketindeki iki kıdemli geliştiriciden birinin diğerinden %40 daha fazla kod yazmış olması, tek başına onun daha iyi geliştirici olduğu anlamına gelmezdi
- Asıl önemli olan neyin yayına alındığı (ship) ve bunun müşteriye, gelire ve istikrara nasıl katkı yaptığıdır; kod satırı sayısı ve PR adedi ise onlarca yıldır kötü ölçüm yöntemleri olarak biliniyor
- 2026’da sektörün öne çıkardığı başlıca rakamların tamamı AI tarafından yazılan kod oranına odaklanıyor
- Google: yeni kodun %75’i AI tarafından üretiliyor
- Anthropic: birleştirilmiş prodüksiyon kodunun yaklaşık %80’i Claude tarafından yazılıyor, mühendisler çeyrek başına "8 kat daha fazla kod" dağıtıyor
- OpenAI: benzer şekilde yaklaşık %80
- Cursor: “günde 100 milyondan fazla satır kurumsal kod yazılıyor”
- Bu rakamların hepsi hacim (volume) iddiası ve "AI tarafından yazılan kod oranı", aslında daha cilalı bir tanıtım cümlesi bulmuş kod satırı sayısından ibaret
- Bu şirketlerin hepsinin aynı zamanda AI satıcısı olması, benimsenme oranlarını şişirme motivasyonunu güçlendiriyor
Eskiden performans iddia ediliyordu
- Birkaç yıl önce temel rakamlar, ölçek bakımından değil, tür olarak farklıydı
- GitHub’ın öne çıkan iddiası, Copilot kullananların işleri %55 daha hızlı tamamladığı yönündeydi
- Buna çok eleştiri gelmişti, ancak bu bir sonuç (outcome) iddiasıydı: iddialıydı, yanlışlanabilirdi ve değerle ilgiliydi — yanlışsa yanlış olduğu gösterilebilirdi
- 2026’daki iddialar ise başarısız olamayacak şekilde kurgulanmış durumda
- "Kodun %75’i AI tarafından yazılıyor" ifadesi, daha hızlı dağıtım, daha az arıza ya da müşteri memnuniyeti gibi gerçek iyileşmeler olmadan da doğru olabilir ve artmaya devam edebilir
- Hacim rakamları ancak benimsenme duraksadığında hayal kırıklığı yaratır; benimsenmenin gerçek olduğu konusunda ise çoğu kişi zaten hemfikir
- İddialar büyüdü ama söyledikleri şey küçüldü
Reklam panosuna çıkmayan kısım
- Bu arada asıl olan, sonuç kanıtlarının daha karmaşık hâle gelmesi oldu
-
Benimsenmeyi destekleyen sonuçlar
- Cui et al.: yaklaşık 5.000 geliştiricide tamamlanan iş +%26, özellikle junior geliştiricilerde en büyük artış — neredeyse tartışmasız
-
Ters yöndeki kanıtlar
-
METR’in geri adımı
- 2026 Şubat’ta METR fiilen tutumunu geri çekti — takip eden tahmin hız artışına (speedup) döndü (hata payı çok geniş)
- Geliştiriciler artık AI olmadan çalışmayı reddettiği ve ajan tabanlı işlerin süresini güvenilir biçimde kendi kendine raporlayamadığı için, araştırma tasarımının kendisi rafa kaldırıldı
- En güncel pozisyon şu: 2026’da AI’nin geliştirici hızını artırması muhtemel, ancak bunun derecesi temiz şekilde ölçülemiyor
-
Şirket düzeyindeki etki
- NBER’in yaklaşık 6.000 yöneticiyle yaptığı anket: şirketlerin %69’u AI kullanıyor, ancak yaklaşık 10 şirketten 9’u ölçülebilir bir üretkenlik etkisi görmediğini bildiriyor
- Çapraz araştırma uzlaşısı, organizasyon düzeyinde yaklaşık %10 artış yönünde — faydalı ama "artık geliştiriciye gerek yok" denecek düzeyde değil
- Hâlâ sadece "%19 daha yavaş" sonucunu alıntılayan şüpheciler de cherry-picking yapıyor; araştırmalar güncellenmeye devam ederken sektör yalnızca ölçtüğü şeyi değiştiriyor
AI versiyonu gösteriş metrikleri
- Bu yalnızca AI satıcılarının sorunu değil
-
Olgunluk modelleri ve merdivenler
- Carnegie Mellon SEI ve Accenture birkaç gün önce AI Adoption Maturity Model yayımladı — 5 seviye, 8 boyut; "kuruluşların %95’i gelir elde etmiyor" istatistiği pazarlamada kullanılıyor
- Steve Yegge’nin "AI-assisted development’ın 8 seviyesi" yaklaşımı, hangi araçların kullanıldığına ve ne kadar denetim olduğuna göre sıralama yapıyor
- Tüm araç satıcıları olgunluk merdivenleri çıkarıyor ve en üst basamak genellikle "kendi ürünlerini daha fazla kullanmak" oluyor
- Bu merdivenler, benimsenme yoğunluğunu ölçüp buna olgunluk adını veren, sadece farklı paketlenmiş aynı ikame ölçütler
-
Tanım karmaşası
- Augment, 219 mühendislik liderine "AI-native engineering" tanımını sorduğunda 219 farklı yanıt aldı
-
Anthropic’in iki yüzü
- Bir yandan "8 kat daha fazla kod yayınlanıyor" iddiasını öne sürerken, aynı zamanda bu yılın en titiz araştırmalarından birini sundu
- RCT sonuçlarına göre AI destekli geliştiriciler, az önce yayımladıkları kodun anlaşılabilirliği konusunda %17 daha düşük puan aldı ve istatistiksel olarak anlamlı bir üretkenlik artışı görülmedi
- Araştırma tarafı bulgularını güncellerken pazarlama tarafı hâlâ hacim sayıyor; iki durum aynı anda doğru olabiliyor
Bu meseleye neden dikkat etmek gerekiyor
- Bu rakamlar süs değil; bütçeleri, performans beklentilerini ve iş gücü planlarını etkiliyor
-
AI gerekçesiyle işten çıkarmalar
- Şubat ayında Jack Dorsey, Block çalışanlarının %40’ından fazlasını (4.000+ kişi) işten çıkardı ve AI’yi açık biçimde temel gerekçe olarak sundu — "daha küçük ekipler, yaptığımız araçlarla daha çok ve daha iyi iş çıkarabilir"
- Birkaç hafta sonra Atlassian da %10 (yaklaşık 1.600 kişi) küçülmeye gitti ve "AI’nin gereken yetkinlik bileşimini ya da rol sayısını değiştirmediğini varsaymak dürüst olmaz" dedi
- Dorsey aynı açıklamada işlerin sağlam olduğunu ve brüt kârın büyümekte olduğunu da belirtti
-
Üretkenlik iddialarına dair soru işaretleri
- "AI sayesinde herkes daha üretken, dolayısıyla daha az kişiye ihtiyaç var" deniyorsa, bunun kanıtını görmek gerekir; ancak şu an böyle bir kanıtın olmadığı düşünülüyor
- İş gücünün bir bölümünün gerçekten atıl ya da eksik kullanıldığının gösterilmesi gerekir; ürün/SaaS şirketlerinin sonsuz yol haritaları olduğu için artan kapasite normalde müşteri değerine ve hıza yansırdı — bu da MAU, dönüşüm ve gelirde görünmeliydi
- İşten çıkarma tercih edilmişse, bu üretkenlik iddiasının zaten başka nedenlerle alınmış bir kararın (aşırı işe alım, yatırımcı baskısı) PR aracı olarak kullanıldığına işaret eder
- Verimlilik temelli küçülme bazen haklı olabilir, ancak böyle durumlarda token sayısı, "AI tarafından yazılan kod oranı" ya da olgunluk merdiveni seviyesi değil, zaten kullanımda olan bireysel performans sistemleri kullanılmalı
- Seçim ölçütü gösteriş metrikleri ise bu seçim, "ruj sürülmüş bir piyango"dan ibarettir
Sonuç
- Bu, AI karşıtı bir tutum değil; aksine tüm mühendislerin her gün AI kullanması gerektiği görüşü savunuluyor
- AI-first ya da AI-proficient adı ne olursa olsun, yeni araçları ve en güncel modelleri merakla denemek gerekiyor
- Sektör yüksek seviyeli dilleri, IDE’leri, otomatik tamamlamayı, agile’ı ve devops’u içine aldı; her seferinde eski günleri özleyen direnişçiler oldu ama sonunda katıldılar
- Bu kez farklı olan şey hız — "cloud" geçişi birkaç yıl ertelense de hayatta kalınabiliyordu, ama AI için bu süre birkaç ay olabilir
- AI benimsemek başlangıç çizgisidir, skor tabelası değil
- Mühendislik performansını nasıl ölçeceğimiz zaten biliniyor — DORA metrikleri, güvenilirlik, anlamlı değişiklik oranı ve nihayetinde gelir ile müşteri değeri
- Kanıtlanmış yöntemleri bırakıp AI gösteriş puanlarına yönelmek için bir neden yok
- Satıcı sunumlarında, yönetici değerlendirmelerinde ve LinkedIn akışında sorulması gereken soru şu: "Bu bir sonuç mu, yoksa hacim mi?"
- Çalışma biçimi AI-first, ölçme biçimi ise kanıtlanmış (battle-tested) olmalı
1 yorum
Hacker News görüşleri
Bu tuhaf akış sanki Şubat 2026’daki OpenAI blog yazısında [1] zirveye ulaştı. Yakın zamanda ana sayfaya çıkan yazı da [2] buydu; ajanların %100 yazdığı bir şey üretme sürecini anlatıyor
Ama o şeyin gerçekte ne olduğu ya da kullanıcıya nasıl bir değer sunduğu açıklanmıyor. En yakın açıklama, “bu ürün içeride yüzlerce kişi tarafından kullanıldı ve her gün kullanan ileri düzey iç kullanıcılar da var” seviyesinde
Buna karşılık 1 milyon satır kod olduğu bilgisi ilk birkaç yüz kelime içinde tam iki kez tekrarlanıyor
[1] https://openai.com/index/harness-engineering/
[2] https://news.ycombinator.com/item?id=48416264
“1 milyon satır kod” ise ve “ajan %100 yazdı”ysa, daha da öyle gibi geliyor. Ya da departman vikisi için bir JS menüsüdür; fiilen jquery’yi MS JScript ile yeniden yazıp JS 5’e derleyen bir şey olabilir
LLM ne kadar güçlü olursa olsun, bakım yapılabilirliğinin de neredeyse hiç olmayacağını tahmin ederim
https://github.com/openai/symphony
Podcast röportajında bunun kullanıcıların indirdiği bir Electron uygulaması olduğu ve bu yüzden düzenli olarak yeni build’ler üretildiği söyleniyor. Buradaki “Autonomous Merging Flow” bölümüne bakın: https://www.latent.space/p/harness-eng
Microsoft tarafındaki birinin “mühendis başına ayda 1 milyon satır kod istiyorum” gibi bir şey yazdığı aklıma gelip duruyor. Konuştuğum mühendislerin çoğuna bu bir hiciv gibi gelmişti ama aslında hiç hiciv değildi ve birçok CEO’nun LLM ile kod üretimine bakışını oldukça iyi yansıtıyordu
Yine de son birkaç ayda, bakım yapılamaz miktarda kod satırı üretme konusundaki aşırı heyecanın biraz söndüğü hissi var. Daha pratik ve gerçekçi görüşler kamusal olarak daha fazla paylaşılmaya başlandı ve bazı teknoloji şirketlerinin en üst kademelerine de yavaş yavaş ulaşıyor gibi. Belki de henüz her şey tamamen mahvolmadı
Gerçekte kodun büyük kısmı hiç test edilmiyordu
Ayda 1.000.000 satır / ayda 25 gün / günde 8 saat / saatte 60 dakika
Bunu kod incelemesi yapan kişiler için oldukça büyük bir sorun gibi görüyorum
Mühendis başına ayda 1 milyon satır kod üretmek isterken, bu satırların şirkete nasıl para kazandıracağını ya da bu süreçte ne kadar token’ın ne maliyetle yanacağını düşünmemiş olmaları, herhalde pek de iyi düşünülmüş bir plan değildi
Buna karşılık teknik borç ifadesi yöneticileri aynı şekilde yakalayamadı. Borç genelde sorun çıkarabilecek bir şey olarak görülür ama sorun çıkarmadığı sürece kaçınılması ya da ele alınması gereken bir şey sayılmaz; bu yüzden sürekli ertelenir
Çalıştığım iki küçük şirkette de bunu gördüm. Birkaç ay önce Claude Cowork geldiğinde herkes çok heyecanlıydı; hâlâ her gün kullanıyorlar ama beklenen sihre kıyasla oldukça hayal kırıklığına uğramış durumdalar
Çıktının sıradan ve gereksiz uzun olduğu, en temel şeyleri bile yanlış yaptığı, token sınırına sürekli takıldığı ve elde yapmanın daha hızlı olduğu için sonunda yeniden elle yapıldığı yönünde şikâyetler var
Başta aracı yanlış kullanma payı olabilir ama insanlar, AI CEO’larının, LinkedIn satıcılarının ve YouTube’daki AI takviyesi pazarlamacılarının söyledikleriyle gerçeklik arasında hâlâ bir fark olduğunu fark ediyor
Şirket “AI herkesi daha üretken yaptı, bu yüzden daha az kişiye ihtiyaç var” diyorsa, bunun kanıtını görmek isterim. Şu anda böyle bir kanıtın var olduğuna inanmıyorum
Aslında yaptıkları şey palavra sıkmak ve COVID dönemindeki aşırı işe alımı geri sarmak için AI’ı bahane etmek. Aynı anda da yatırımcılara, en yeni moda teknolojiyi benimseyip daha çevik ve maliyet verimli bir organizasyon hâline gelmiş gibi görünmelerini sağlıyor
Ben yatırımcıların en yeni moda teknolojiyi benimsemekten çok kâra önem verdiğini sanıyordum
Ayrıca “yatak odasındaki herhangi bir aptalın bile kullanabildiği parlak teknolojiyi biz de kullanıyoruz!” diyen bir şirket, aynı zamanda tamamen rekabetsiz bir şirkettir
Sektörümüz onlarca yıldır “yaptığımız iş karmaşık ve uzun sürdüğü için üretkenlik kolayca ölçülemez” diye anlatıp durdu; sonra yapay zeka ortaya çıkar çıkmaz kod satırı sayısı, Nx çarpanlar, haftalık ticket sayısı gibi şeylerin bir anda faydalı ya da nesnel metriklermiş gibi el üstünde tutulması bitmek bilmeyen bir komedi gibi
Kod satırı sayısı gibi metrikleri reddetmemizin nedenleri değişmedi. Esas olan kod çıktısı değil, kalite çıktısı. Yapay zeka da insanlardaki sorunların aynısını taşıyor. Ama nedense öğrendiklerimizi bir kenara atıyoruz ve bu biraz utanç verici
Çünkü gevşek biçimde dahil olan ama agresif ve talepkar yöneticiler her zaman vardı. Çalışandan daha fazla emek sıkmak ana işi olan ve koordinasyon gibi şeylere katkı sunmayan yöneticilerin de ne yazık ki ekonomik bir değeri var
Bu yüzden gerçek performans ile kod satırı sayısı gibi ölçümler arasında örtüşen iki yaklaşımın bulutu hep vardı
Yapay zeka, böyle gevşek biçimde dahil olup sadece talepte bulunan yöneticileri tatmin edecek tüm araçları sunuyor. Bu yüzden artık kod satırı sayısını ve özellik eklemeyi metrik olarak seven daha fazla insan olacak. Çünkü artık bu daha kolay
A+ bir kıdemli geliştirici 8 ay boyunca bir özellik geliştirip sonunda o özellik hiç yayımlanmazsa ya da MVP çöpe atılırsa, o A+ kıdemli geliştirici boşa harcanmış olur ve üretkenliği de aynı projedeki iki B+ mühendise eşit hale gelir
Bu aslında çok yaygın bir sorun ama işe alımda ya da proje kaynak dağıtımında genelde görmezden geliniyor. Yapay zeka bunu anlamlı biçimde değiştirmeyecek
Ekip işi çok daha hızlı bitirebilir ama üst taraftaki bürokratik katman büyük olasılıkla aynı kalır; o durumda da yapay zeka kodlamasından gelen kazanç çok sınırlı olur. Yapay zekaya uyum sağlamak için şirketi tepeden tırnağa yeniden kurmak gerekir ama bu neredeyse hiç olmaz
Sondaki yapay zeka itişi tuhaf derecede temelsiz. Ne gerekçe var, ne hedef, ne de faydaya dair bir iddia; sadece “işte yapay zekayı kullanın, geliştiriciler yeniyi benimsemeli” deniyor
Son zamanlarda okuduğum yazılar arasında da kısa bir bağlamla yapay zekayı eleştiriyormuş gibi yapıp sonunda yapay zeka reklamına bağlanan bir yazı vardı; ikisini birbirine bağlayan hiçbir şey yoktu
Yatırımcılar ve büyük müşteriler de büyük sözleşmelere imza atmadan önce yeniden düşünecek
O yüzden yapay zekayı kullanmak zorundasın. Maliyet ve faydayı küçük küçük hesaplamamalısın. Dünya bu yöne gidiyor ve yazılım geliştirerek geçinmek istiyorsan senin de o yönde olman gerek
“Bu kez fark hız. Cloud’u birkaç yıl geç benimseyip yine hayatta kalabilirdin. Yapay zekada bu birkaç ay olabilir” kısmı tuhaf
Yazar, yapay zeka şirketlerinin ürünlerinin vazgeçilmezliğine dair yaptığı yapay zeka yanlısı iddiaların çürütülemez olduğunu anlıyor gibi görünüyor ama hemen ardından “dur, beni yapay zeka karşıtı sanmayın” diye geri çekiliyor
Bu iddia, yazının geri kalanında eleştirdiği üretkenlik iddialarından nasıl daha titiz olabilir? Birkaç ay içinde yapay zekayı benimsemezsen “hayatta kalamazsın” demek?
Bunu bir yapay zeka CEO’su söylediğinde de gerçek olmuyor; bir yapay zeka CEO’sunun saçmalığını işaret eden biri herhangi bir nedenle aynı şeyi söylediğinde de gerçek olmuyor
Yapay zeka yüzünden insan çıkardığını söylemek yorum alanı fazla geniş bir ifade ve sorumluluğu kendinden alıp yapay zekaya yüklüyor. Gerçekte CEO’nun yaptığını yapay zekanın suçuymuş gibi göstermemek gerekir. Çalışanları yapay zekaya uygun biçimde yeniden eğitebilirdi ama bunu yapmadı. Neden? Belki de sebep yapay zeka değildir
Metni gerçekten kendim yazdım; başka yerlerde söylendiği gibi bir “AI slop” ile üretmedim, o yüzden muhtemelen son kısımda “insani biçimde sloppy” oldum
“Dur” kısmını gerekçelendiremediğim doğru ama yine de insanların yapay zekayı denemesi gerektiğini düşünüyorum. Deney yapmalı ve kendilerine yardımcı olan yolu bulmalılar. Benzer mühendisler arasında bile değer elde etme biçimlerinin yelpazesi çok genişti
Aracı gerçekten denemenin maliyeti neredeyse yok ve “bilinçli biçimde benimseyip kanıtlanmış sıkıcı yöntemlerle ölçün” yaklaşımı, “benimsemezsen ölürsün” ile aynı şey değil
Bir şirket “yapay zeka herkesi daha üretken hale getirdi, bu yüzden daha az kişiye ihtiyacımız var” dediğinde, üstü kapalı olarak şirketin daha üretken olmak istemediğini söylemiş olur.
Demek istedikleri, daha üretken olan daha az kişiye daha az ödeme yapıp aynı üretkenliği istemeleridir.
Üretim birimi başına işverenin aldığı para ile çalışanın aldığı para arasında neden bir dengesizlik var?
Daha az kişiyle aynı çıktıyı elde ediyorsanız, şirketin ya da ülkenin üretkenliği iyileşmiş demektir.
Daha az kişiyle aynı üretkenlik söz konusuysa, çıktı da buna paralel olarak azalır; dolayısıyla şirket için bir kazanç yoktur ve sabit maliyetler varsa durum hatta daha kötü bile olabilir.
https://www.mckinsey.com/featured-insights/mckinsey-explaine...
Kod satırı sayısını, ofiste geçirilen süreden çok da farklı görmüyorum. Pandemiden önce sürekli “Ofiste değilse çalıştığını nasıl bileceğiz?” denirdi.
Basit. Tüm çalışan değerlendirmelerinde kullandığınız çıktı ölçütleri ile onların işe ne kattığına bakarsınız.
Kod satırı sayısının hâlâ bir borç değil de bir varlık gibi görülmesinde biz mühendislerin de büyük payı olduğunu düşünüyorum. Yaptığımız şeyle gurur duyuyoruz ama bir şeyin ne kadar “büyük” olduğunu anlatmak için bir metriğe ihtiyaç duyuyoruz ve sonunda hesaplaması en kolay olana geri dönüyoruz.
Terminolojiyi değiştirmeliyiz. Özellikle de “...ve bunun maliyeti N satır kodddu” gibi ifadeleri daha sık kullanmalıyız. O kod satırlarını ne için harcadığımızı da söylemeliyiz.
“Yeni özellik X’i hayata geçirdim ve yalnızca 200 satır tuttu.”
“O bug’ı bulmak gerçekten çok zordu ama sonuçta sadece 6 satır koda mal oldu.”
“X durumunda yaptığımız şeyi Y durumunda yapmadık ama sonradan o ayrımın kendisinin gereksiz olduğu ortaya çıktı. Böylece sorunu düzeltirken aynı anda 20 satır koddan tasarruf ettik.”
Kod satırları ödediğimiz bedeldir. Ne satın aldığımızı söylemeden 200 dolar harcadık diye övünmeyiz. Kod satırlarında neden böyle yapıyoruz?
“Geç başvurduğum için 200 dolar daha ödemek zorunda kaldım” ile “El boyaması zanaatkâr işi seramik bir lamba askısını sadece 200 dolara aldım; Amazon’daki fabrika üretimi olanlar 1.200 doların üzerinde” demek tamamen farklı şeylerdir ve koddaki karşılığı da tam olarak aynıdır.