- Yapay zeka destekli geliştirme, kod üretim hızını insanın anlama hızının önüne geçiriyor ve “bilişsel borç (cognitive debt)” oluşturuyor
- Kod düzgün çalışsa ve testleri geçse bile, geliştiricinin kodun yapısını ve nedenlerini kendisinin anlayamadığı durum birikiyor
- İnceleyicinin değerlendirme sınırları, organizasyonun örtük bilgi kaybı, yeni geliştiricilerin öğrenme eksikliği gibi etkenler bu borcu hızlandırıyor
- Organizasyonlar yalnızca hız odaklı metrikleri (DORA, story point vb.) ölçtüğü için anlama eksikliğini yakalayamıyor
- Üretkenlik ile anlama arasındaki kopukluk büyüdükçe, uzun vadede bakım başarısızlığı, bilgi kopuşu ve mühendis gelişiminde duraklama riskleri artıyor
Anlamadaki gecikme (The Comprehension Lag)
- Manuel kodlama, üretim ve özümseme süreçlerini aynı anda yürütür; yazma sürtünmesi düşünmeyi teşvik eder
- Kod yazarken doğal olarak zihinsel modeller ve sezgi oluşur
- Yapay zeka destekli geliştirme bu süreci ayırır; çıktı hızı sıçrarken anlama hızı insan sınırlarına bağlı kalır
- Çıktı ile anlama arasındaki bu fark tam olarak bilişsel borçtur ve teknik borçtan farklı olarak hız metriklerinde görünmez
- Sorun daha sonra MTTR artışı, değişiklik başarısızlık oranının yükselmesi gibi güvenilirlik metriklerinde ortaya çıkar
Organizasyonların gerçekte ölçtüğü şeyler (What Organizations Actually Measure)
- Organizasyonlar yalnızca gözle görülür çıktıları ölçer (özellik sayısı, commit sayısı, inceleme hızı vb.)
- Geçmişte çıktı ile anlama bağlantılı olduğu için, bir özellik yayınlandıysa anlaşıldığı varsayılırdı
- Ancak yapay zeka çağında yüzeysel anlayışla bile özellik yayınlamak mümkün, bu varsayım artık geçerli değil
- Organizasyon metrikleri anlama eksikliğini yakalayamadığı için, performans değerlendirmesi ve ödül sistemleri çarpılıyor
İnceleyicinin ikilemi (The Reviewer’s Dilemma)
- Yapay zeka sayesinde junior geliştiriciler seniorlardan daha hızlı kod üretebilir
- Senior inceleyiciler, çok büyük kod hacmini derinlemesine incelemeye zaman bulamadığından inceleme derinliğinden ödün verir
- Sonuç olarak “incelenmiş kod = anlaşılmış kod” varsayımı çöker
- Organizasyon baskısı hızı öncelediği için, inceleme kalitesinden çok çıktı miktarına odaklı bir kültür güçlenir
Tükenmişlik örüntüsü (The Burnout Pattern)
- Yapay zeka araçlarını kullanan mühendisler, yüksek çıktı ile düşük güven duygusunun bir arada olduğu bir yorgunluk yaşar
- Kod çalışır, ancak kendi yaptıkları sistemi tam olarak anlayamama kaygısı sürer
- Hız odaklı değerlendirme sistemleri, derin anlayış için zaman ayırmayı dezavantaja dönüştürür ve bilişsel borcu hızlandırır
Organizasyonel hafızanın çöküşü (When Organizational Memory Fails)
- Organizasyon bilgisi, belgelenmiş açık bilgi ile geliştiricilerin zihnindeki örtük bilgiden oluşur
- Yapay zeka ile geliştirme, örtük bilgi oluşum sürecini (doğrudan uygulama deneyimini) kısaltır; bu yüzden bilgi birikimi oluşmaz
- Sonuçta sistem çalışır, ancak onu anlayabilen insanlar giderek ortadan kaybolur
- Sorun çıktığında, sistemin bağlamını açıklayabilecek kimse kalmayabilir
Bilişsel borcun birikmesi (How the Debt Compounds)
- İlk olarak, kod eskidikçe risk artar — yazıldığı anda bile eksik anlaşılmış kod zamanla tamamen opak hale gelir
- İkinci olarak, olay müdahalesinde toparlanma süresi hızla artar — “kara kutunun yaptığı kara kutu”yu debug etme durumu ortaya çıkar
- Üçüncü olarak, geleceğin senior mühendisleri eksik kalır — yapay zekaya bağımlılık öğrenme eğrisini ortadan kaldırır ve uzun vadeli liderlik boşluğu yaratır
Direktörün bakış açısı (The Director’s View)
- Yöneticiler yalnızca üretkenlik artışı, takvimlerin kısalması, iş gücü verimliliği gibi olumlu sinyalleri görür
- “Anlama derinliği” ya da “açıklanabilirlik” için ölçüm metrikleri olmadığı için bilişsel borç raporlanmaz
- Bu nedenle veri odaklı karar alma rasyoneldir ama eksiktir; gerçek risk gizli kalır
Bu modelin sınırları (Where This Model Breaks)
- Bilişsel borç kavramı her işe aynı şekilde uygulanmaz
- Basit tekrarlı işler veya hızlı deneyler için uygun olabilir
- Geçmişte de anlama seviyesi kişiden kişiye değişiyordu; bu, yeni bir olgudan çok dağılımın kayması olabilir
- Gelecekte araçların ve dokümantasyonun gelişmesiyle anlama farkı azalabilir
Ölçüm sorunu (The Measurement Problem)
- Organizasyonlar yalnızca ölçebildiklerini optimize eder
- Hız ölçülebilir, ancak anlama ölçülemez
- Anlama, değerlendirme sistemine yansımadığı sürece hız odaklı teşvikler sürecektir
- Bu, bireylerin ya da yöneticilerin başarısızlığı değil; geçmiş dönemin ölçüm sisteminin bugünkü gerçeklikle uyuşmamasının sonucudur
- Sonunda bu fark, bakım maliyetinin artması, olay müdahalesinin gecikmesi, sistem kırılganlıklarının görünür hale gelmesi gibi sonuçlarla ortaya çıkabilir
- Yazı, şu sonuçla biter: “Sistem, ölçtüğü şeye göre optimize edilir. Ama bugün ölçtüğümüz şey artık önemli olanı taşımıyor.”
3 yorum
Ben de bu aralar benzer şeyler düşündüğüm için, dün bilişsel borçla ilgili bir blog yazısı yazdım. Sanırım herkes benzer dertleri düşünüyor.
Kod anlayışını nasıl ölçmeliyiz? Bunu, dahili kod tabanı üzerinden kısa sınavlar hazırlayıp değerlendirerek mi yapmalıyız?
Hacker News görüşleri
Son birkaç aydaki deneyimlerim yazıyla çok örtüşüyor
Üzerinde çalıştığım proje istikrarlı biçimde büyüdü ama mühendis sayısı aksine azaldı
Testlere bağımlılığı artırdık ve simülatör tabanlı geliştirmeye geçtik. Gerçek sistemde doğrulama yapmak nadir hale geldi ve bunu yaptığımızda da en karmaşık kısımlarla uğraşıyoruz
Geçen yıldan beri, birkaç ay uğraştığım özelliklerin ayrıntılarını bile hızla unuttuğumu fark ediyorum. Bu, kodlama ajanları ciddi biçimde devreye girmeden önce de böyleydi
Ajanlar gelince PR incelemeleri çok daha örtük hale geldi; bağlam kafamda kalmadığı için bilinçli olarak odaklanmam gerekiyor. Ekip arkadaşlarım da aynı deneyimi aktarıyor
Şu anda kodla birlikte ajanın planını commit etmek gibi çeşitli denemeler yapıyoruz. Bu sayede süreç daha sistematik ve açık hale geliyor
Ama mühendislik yöneticisinin bu artan bilişsel yükün pek farkında olmadığını düşündüm
Yazının öncülü olan “geliştirici 6 ay önce yazdığı kodu hatırlar” varsayımı yanlış
Eskiden beri kodu yazarken anlamak, okurken anlamaktan daha kolaydı. Joel Spolsky de “kodu okumak, yazmaktan daha zordur” demişti
“Anlaşılmayan kod” sorunu AI öncesinde de vardı
Örneğin Microsoft’un Pinball kodunu silme vakasında, eski dış kaynak kodu o kadar karmaşıktı ki kimse anlayamadı ve sonunda özellikten vazgeçildi
Oracle RDBMS kod tabanı örneği de benzer
“Normal çalışıyor ama yabancı gelen sistem” ifadesi dikkat çekiciydi
Bu, geliştiricinin yöneticiye dönüşürken hissettiği duyguya benziyor. Koddan uzaklaştıkça anlayış daha soyut ve kopuk bir his veriyor
“Derinlemesine anlamaya çalışan mühendis hız metriklerinde geride kalıyor” sözü en acı gelen kısımdı
Piyasa kalite yerine hıza öncelik veriyor ve sonunda temkinli mühendislerin işten çıkarıldığı bir yapı ortaya çıkıyor
Belki de artık “LGTM, LLM” çağına geçiyoruzdur
Sektör her zaman aşırılığa kaçar ve sonra dengeyi bulur. Sorun, 20 kat verimlilik isteyip %100 sorumluluk bekleyen imkânsız beklentiler
Sonunda ya anlamaktan vazgeçmek ya da en fazla %20 civarında bir verimlilik artışını kabul etmek gerekiyor
Richard Gabriel’in Worse Is Better felsefesini hatırlatıyor
AI kodu çoğu zaman doğruluktan çok sadeliği seçiyor ama “çalışıyorsa kazanır” şeklindeki gerçekçi yaklaşım galip gelebilir
Bir kez çalışan bir sistem oluştuğunda, sonrasında kademeli olarak iyileştirilebilir
Bizim ekip de son 6 ayda yazıda anlatılan olguyu birebir yaşadı
AI destekli geliştirmenin örtük bilgi birikimini kesintiye uğrattığı tespiti tam isabet
Yine de bu durum geçici bir ara dönem olabilir
Uzun vadede LLM’ler kod yapısını iyi düzenleyip, insanın yalnızca gerektiğinde derinlemesine anlamasını sağlayan meta düzeyde bir değer sunabilir
Dokümantasyon yetersizse ürün destek ekipleri de ağır darbe alır
Müşteri ürünün nasıl çalıştığını sorduğunda, mühendis bile kendi yazdığı kodu iyi bilmiyorsa yanıt vermek zorlaşır
Güncelleme hızı yüksek olduğunda diğer ekiplerin yetişmesi zor olur
Yüksek seviyeli diller ortaya çıktığında da benzer şeyler yaşanmıştı ama sonuçta sorun olmadı
O halde LLM’lerin kodu anlama işini soyutlaması da sorun olmayabilir mi?
Fark şu: derleyiciler deterministik, LLM’ler ise olasılıksal