Anlama Borcu: Fatura Tek Başına Gelir

Neredeyse her gün yapay zeka kodlama ajanlarıyla üretim yapıyorum. Bu yazıyı, Copilot'ı bir kez deneyip ürkmüş ve kenara çekilmiş biri olarak yazmıyorum. Tam aksine, bu araçlara kendisini fazlasıyla kaptırmış ve tam olarak nerede kırıldıklarını birebir deneyimlemiş solo bir kurucu olarak, diğer uçtan yazıyorum.

Üstelik kırılan şey kod da değil. Kod genellikle derleniyor, testleri geçiyor ve diff'te oldukça temiz görünüyor. Kırılan şey anlama becerimiz — ve tek kişilik bir ekipte, bu kaybı sizin yerinize üstlenecek başka kimse yok.

💡 TL;DR: Özet ve Anahtar Çıkarımlar

• Anlama Borcu: Sisteminizdeki kod miktarı ile sizin gerçekten anladığınız kısım arasında sessizce büyüyen uçurum.
• Tek Kişilik Risk: Ekiplerdeki kıdemli denetçi (review) mekanizması solo geliştiricilerde yoktur. Hem yazan hem de denetleyen sizsinizdir.
• Veriler: AI kullanımı kod churn oranını ikiye katlıyor (%6-7) ve güvenlik başarı oranlarını %55'te sabit tutuyor. Kıdemliler artan inceleme yükü nedeniyle %19 yavaşlıyor.
• Çözüm: Koddan önce spesifikasyon yazın, AI çıktısını güvenilmez girdi kabul edin, tip sistemlerini sıkı kullanın (%94 derleme hatasını yakalar) ve doğrulamayı otomatize edin.

Diff'te görünmeyen borç

Teknik borç dürüsttür. Onu görebilirsiniz. Bir kestirme yol kullanmışsınızdır, bunun bir kestirme yol olduğunu bilirsiniz ve geri dönüp düzeltmek için bir not bırakırsınız. Göz önündedir.

Ancak hiçbir yerde görünmeyen ikinci bir borç türü daha var; o da yapay zeka araçlarının kitlesel ölçekte ürettiği borçtur. Buna anlama borcu (comprehension debt) diyelim: sisteminizde şu anda var olan kod miktarı ile bu kodun ne kadarının gerçekten herhangi bir insan tarafından anlaşıldığı arasındaki uçurum. Teknik borcu bilerek ve isteyerek hanenize yazarsınız. Anlama borcu ise, neden çalıştığına dair zihinsel bir model oluşturmadan, her "çalışan" öneriyi kabul ettiğinizde sessizce birikir.

Bunun tehlikeli olmasının sebebi, her iki borcun da canlı ortam (production) patlayana kadar tamamen aynı hissettirmesidir. Anlamadığınız temiz bir kod tabanı ile derinlemesine anladığınız kirli bir kod tabanı, analitik panelinde aynı görünür. Ancak gece saat 2'de hissettirdikleri çok farklıdır.

Veriler aslında ne söylüyor — ve neyi söylemiyor

Bu konuyla ilgili çoğu yorum sınırını aşıyor, bu yüzden net ve kesin konuşalım; zira durumun gerçeği zaten yeterince endişe verici.

Güvenlik. Veracode’un 2025 GenAI Code Security Raporu 80'den fazla kodlama görevinde 100'ün üzerinde modeli test etti. Vakaların %45'inde model, bilinen bir güvenlik açığı üretti. Cross-site scripting (XSS) için başarısızlık oranı %86, log injection için ise %88 oldu. En kritik detay ise şu: Daha büyük ve yeni modeller anlamlı derecede daha iyi sonuçlar elde edemedi. İki yıllık süreçte sözdizimi (syntax) başarı oranları %95'in üzerine tırmanırken, güvenlik başarı oranları %55 civarında çakılı kaldı. Bu durum, yeni model güncellemelerini bekleyerek aşabileceğimiz geçici bir pürüzün değil, yapısal bir sorunun işaretidir.

Sürdürülebilirlik. GitClear 2020 ile 2024 yılları arasında değiştirilen 211 milyon satırı analiz etti. Kod churn oranı —yani committlendikten sonraki iki hafta içinde yeniden yazılan veya geri alınan satırlar— yapay zeka öncesi taban çizgisine kıyasla kabaca ikiye katlandı (kesite bağlı olarak %3'ten %6-7 seviyelerine çıktı). Yinelenen kod blokları, kopyala-yapıştır kodun ilk kez refaktör edilen kodu geride bıraktığı yıl olan 2024'te yaklaşık sekiz kat arttı. Buradaki baskın eğilim, "birleştir ve yeniden kullan" yerine "ekle ve geç" şeklinde işliyor. (İnternette dolaşan "%5.5'ten %7.9'a" churn rakamlarına dikkat etmek gerek. Bu oranlar ikincil özetlerden türetilmiş olup GitClear'ın kendi birincil verileriyle uyuşmuyor. Eğilim gerçek, ancak bu spesifik sayı ikilisi şüpheli. Atıfta bulunacaksanız aklınızda bulunsun.)

Doğrudan ölçülen anlama seviyesi. Buradaki en ilginç çalışma, bizzat bu araçları geliştiren Anthropic’ten geliyor. Yapılan rastgele kontrollü bir deneyde, yapay zeka desteği kullanan yazılımcılar, sadece birkaç dakika önce kullandıkları kavramları kapsayan bir testte %17 (yaklaşık iki harf notu) daha düşük skor elde ettiler. Manşetlerin gözden kaçırdığı nüans ise şu: Yapay zeka kullanımı, bilgiyi kalıcı olarak hafızada tutamamayı garanti etmiyor. Skorlarını korumayı başaranlar, yapay zekayı sadece kod yazdırmak için değil; problemi sorgulamak, nedenini sormak ve açıklama talep etmek için kullananlardı. Esasen: araca sadece "kod yaz" diyenler anlama becerilerinin düştüğünü görürken, aracı "bu neden bu şekilde çalışıyor?" diye açıklama yapmaya zorlayanlar yerlerini korudular. Değişken olan araç değil, onu nasıl tuttuğunuzdur.

Ekip düzeyindeki yeniden dağılım. Popüler tartışmalarda iki farklı çalışma birbirine karıştırılıyor ve aradaki fark oldukça önemli. METR'ın kontrollü deneyi, deneyimli yazılımcıların yapay zeka kullandıklarında kendi görevlerinde %19 daha yavaş olduklarını ve işin ilginç yanı, buna rağmen daha hızlı olduklarına inandıklarını ortaya koydu. Farklı bir çalışma (açık kaynaklı projelerde Copilot kullanımına yönelik bir analiz) ise yapay zekanın gelişinden sonra üretkenlik artışının çoğunlukla junior geliştiricilere yansıdığını; kıdemli yazılımcıların ise ~%6.5 daha fazla kod incelemek zorunda kaldığını ve kendi kişisel çıktılarında %19'luk bir düşüş yaşadığını gösterdi. Bir nevi temizlik ekibine dönüştüler. Aynı oranlar, ancak farklı mekanizmalar; bunları birbirine karıştırmamak gerek.

İşte tam da bu ikinci bulgunun üzerinde durmak istiyorum; çünkü tek başına çalışan herkes için çok şey ifade ediyor.

Solo founder: sistemin kanarya kuşu

Bir ekipte, anlama borcunun gidebileceği bir yer vardır. Junior yazılımcılar hızlıca kod üretirken, senior yazılımcılar inceleme (review) yükünü üstlenirler: hatalı varsayımları yakalar, yanlış yerleştirilmiş kodları taşır ve servis sınırlarının neden var olduğunu sorgularlar. Veriler de tam olarak durumun böyle olduğunu ve senior üretkenliğinin bu yüzden düştüğünü gösteriyor. Bu durum kıdemliler için can sıkıcı olsa da sistemin bir amortisörü (shock absorber) vardır.

Solo çalışırken ise ortada bir amortisör yoktur. Tab tuşuna basan junior da sizsiniz, o hatayı yakalaması gereken senior da. Bir saat önce hızlıca kod yazan aynı zihinden, şimdi taze ve şüpheci bir gözle inceleme yapması beklenir — ancak bunu yapamaz; çünkü o odadaki tek zihinsel model, yapay zekanın ona teslim ettiği ödünç modeldir. Ortada kestirme yollardan gitmemiş ikinci bir çift göz yoktur.

Dolayısıyla ekipleri koruyan o iş yükü dağılımı sizin için geçerli değildir. Borç başka yere gitmez. Tek bir zihinde katlanarak büyür — ve ödünç alınmış bir zihinsel model, onu tutan kişi ne kadar kıdemli olursa olsun, canlı ortamda çıkacak bir krizde ayakta kalamaz.

Yapay zekanın yazılım ekiplerini nasıl yok ettiğine dair popüler yazıların tamamen gözden kaçırdığı nokta tam da burasıdır. Bu sorun büyük ekiplerde en kötü seviyede değildir. En kötü durum, kendi sisteminizi anlamayı bıraktığınızı kimsenin fark edemeyeceği, en sessiz ve en küçük ölçekte yaşanır.

Peki ne işe yarıyor? (Hâlâ bu araçları kullanan birinden)

Size yapay zekayı daha az kullanmanızı söylemeyeceğim. Ben de öyle yapmıyorum ve veriler de çözümün bu olduğunu göstermiyor — anlama becerisini koruyanlar da yapay zekayı yoğun bir şekilde kullanıyordu, sadece farklı bir yöntemle. Buradaki temel değişim, neyi korumaya değer gördüğünüze karar vermektir.

Pratikte bu durum benim için birkaç disipline indirgendi:

Koddan önce spesifikasyonu birincil kaynak yapın. Varsayılan iş akışı şöyledir: Yapay zeka kodu yazar, insan göz ucuyla bakar ve yayına alır. Bu tamamen tersten bir yaklaşım. İnsanın asıl sahip çıkması gereken şey, yapay zeka ajanı işe başlamadan önce yazılmış olan niyettir — yani ne yapılacağı ve neden yapılacağı. Kod sadece bir uygulama (implementation) detayından ibarettir. Eğer bir kodun neden var olduğunu sade bir dille anlatamıyorsam, test paketi ne derse desin o iş benim için bitmemiş demektir.

Kritik alanlardaki yapay zeka çıktılarına güvenilmeyen girdi (untrusted input) muamelesi yapın. Yetkilendirme (auth), ödemeler, paraya veya kullanıcı verilerine dokunan her şey ve sistem sınırları... Buraları her seferinde tanımadığım birinin pull request'ini inceler gibi incelerim. "Bunu yapay zeka yazdı" bir savunma mekanizması değildir; regüle edilen bir alanda bu sadece bir itiraftır.

Tip sistemlerini sadece bir tarz seçimi değil, gerçek bir güvenlik bariyeri olarak kullanın. ETH Zürich tarafından yapılan bir araştırma büyük dil modelleri kaynaklı derleme (compilation) hatalarının %94'ünün tip kontrolü (type-check) hataları olduğunu ortaya koydu. Bu, güçlü bir tip sisteminin, bir modelin mekanik hatalarının ezici çoğunluğunu size ulaşmadan yakalayacağı anlamına gelir. Yapay zeka destekli bir iş akışında tip tanımlamaları birer detaycılık (pedantry) değildir. Onlar, işe alabileceğiniz en ucuz kod denetçisidir (reviewer).

Kendi yorgun muhakemenizden daha fazla güvendiğiniz bir doğrulama katmanı inşa edin. İkinci bir insan olmadığı için denetim sürecini dışsallaştırmak zorunda kaldım: karmaşıklığı ve sapmaları (complexity & drift) işaretleyen otomatik testler, denetimler ve analizler... Böylece, bir ajanla üç saat boyunca keyifli bir akışa kapılıp giden versiyonumun dışında, döngüde şüpheci bir şeyler yer alabiliyor.

Bunların hiçbiri yapay zekaya güvensizlik duymakla ilgili değil. Bu, kalibre edilmiş bir güvendir: aracın nelerde güvenilir olduğunu, tam olarak nerede başarısız olduğunu bilmek ve süreci bu iki duruma göre tasarlamak. Körü körüne güvenmek ile paranoyakça reddetmek kolaya kaçmaktır. Asıl iş ortada duran dengeyi bulmaktır.

Asıl risk

Ortalıkta dolaşan rahatlatıcı bir hikaye var: Bunların hiçbirini kafaya takmayın, çünkü gelecekteki daha akıllı bir model her şeyi temizleyecek. Hayır, temizlemeyecek. Bir model sözdizimini (syntax) refaktör edebilir. Ancak hiç sahip olmadığı anlamı refaktör edemez. Eğer bir sistemin neden o şekilde kurulduğunu hiçbir insan anlamadıysa, yapay zekanın onu "temizlemesi" sadece incelenmemiş eski varsayımların üzerine yenilerini yığmaktır. Bu, borcu ödemek değildir; sadece faizi kapatmak için daha fazla borç almaktır.

Sektörün en ciddi oyuncularının nereye vardığını görebilirsiniz. Milyarlarca cihazda çalışan SQLite, artık yapay zeka tarafından üretilen katkıları (contributions) açıkça reddediyor; çünkü standartları tam hesap verebilirlik üzerine kurulu ve olasılıksal çıktılar bununla tamamen uyumsuz. Zig, NetBSD, GIMP ve qemu da benzer sınırlar çizdi. Bunlar teknoloji karşıtı gericiler değil. Tam aksine, kodlarına en çok güvendiğimiz, gerçekten kritik sistemler için her bir satırın bir insan tarafından anlaşılması gerektiğine karar veren kişiler.

O kadar uzağa gitmek zorunda değilsiniz, ben de gitmedim. Ancak buradaki temel yargıyı içselleştirmek gerekiyor: Artık kıt ve değerli olan şey kod üretme yeteneği değil, o koda kefil olabilme yeteneğidir — neden var olduğunu ve ne zaman yanlış olduğunu bilebilmektir.

Solo bir kurucu için bu lüks bir tercih değil, işin kendisidir. Piyasa yakında çalışan yazılımlar üretebilen ancak bunu açıklayamayan insanlarla dolup taşacak. Bu geçiş sürecinde hayatta kalanlar en çok kod üretenler olmayacak. Yayınladıkları şeyi hâlâ anlamaya devam edenler olacak.

Anlama olmadan elde edilen hız, üretkenlik değildir; sadece bir borçtur. Ve tek başınıza çalışırken, o borcu geri ödeyecek tek kişi sizsiniz.