Anlama Borcu: Fatura Tek Başına Gelir

Yapay zeka kodlama araçlarını neredeyse her gün kullanıyorum. Bu yazıyı, Copilot'ı bir kez deneyip ürken ve kenara çekilen biri olarak yazmıyorum. Bu araçlardan yoğun biçimde yararlanan ve asıl riskin nerede başladığını gören solo bir kurucu olarak yazıyorum.

Kod çoğu zaman derleniyor, testleri geçiyor ve kod farkında temiz görünüyor. Tehlikeli olan, sistemin artık yapabildikleriyle benim hâlâ açıklayabildiğim, hata ayıklayabildiğim ve güvenle değiştirebildiğim kısım arasındaki fark.

Ben bu farka anlama borcu diyorum. Kod tabanı, onu anlamak için kurduğum zihinsel modelden daha hızlı büyüdüğünde bu borç birikiyor. Tek başıma çalışırken eksik bağlamı kendiliğinden üstlenecek bağımsız bir incelemeci yok. Hem hızdan hem de ne yaptığımı anlamaktan ben sorumluyum.

Kısaca

• Anlama borcu, kötü veya dağınık kodun başka bir adı değil. Temiz görünen ve bütün testleri geçen kod da yeterince anlaşılmamış olabilir.
• Sorunu yapay zeka tek başına yaratmıyor. Asıl borç, kararın gerekçesini kurmadan veya kaydetmeden değişikliği kabul ettiğimizde oluşuyor.
• Tek başına çalışmak, riskin her ekipten daha büyük olduğunu kanıtlamıyor. Fakat sistem için bağımsız bir zihinsel model taşıyabilecek ikinci kişiyi ortadan kaldırıyor.
• Benim çözümüm niyeti baştan yazmak, değişiklikleri küçük tutmak, kabul etmeden önce açıklayabilmek ve doğrulama kendi anlayışımı aştığında durmak.

Kod Kalitesinin Göstermediği Borç

Teknik borç genellikle tasarım ve uygulama tercihlerinde yaşar. Anlama borcu ise sistemin bakımını yapan kişiden bekledikleriyle o kişinin gerçekten bildikleri arasındaki farkta oluşur. İkisi aynı yerde bulunabilir, ama aynı şey değildir.

Karmaşık bir modülü yeterince iyi tanıyorsanız güvenle değiştirebilirsiniz. Buna karşılık, uzun bir ajan çalışması sonunda ortaya çıkan düzenli bir modül bütün kontrollerden geçse bile varsayımlarını kimse açıklayamıyor olabilir. Ölçüm panelleri bu farkı göstermez. Bedel, bir sonraki değişiklik hiç kurulmamış veya kayda geçmemiş bir muhakeme gerektirdiğinde ortaya çıkar.

Şu işaretler anlama borcuna yaklaştığımı gösteriyor:

• Yakın zamanda yapılan bir değişikliğe devam edebilmek için önce ajana ne yaptığını sormam gerekiyor.
• Testler geçiyor, fakat hangi davranışı koruduklarını veya hangi hata ihtimallerini kapsamadıklarını açıklayamıyorum.
• Etki alanını bilmediğim için küçük bir değişiklik bile riskli geliyor.
• Bir kararın elimdeki tek açıklaması yine yapay zekanın ürettiği bir özet.
• Çıktının ne yaptığını söyleyebiliyorum, fakat bu çözümün neden sistemin bu bölümünde bulunması gerektiğini açıklayamıyorum.

Bunların hiçbiri kodun mutlaka yanlış olduğu anlamına gelmez. Yalnızca kod miktarıyla ona gerçekten sahip çıkma düzeyimin aynı hızda ilerlemediğini gösterir.

Araştırmalar Neyi Gösteriyor, Neyi Göstermiyor?

Mevcut çalışmalar bu riski ciddiye almak için yeterli gerekçe sunuyor. Fakat yapay zeka destekli yazılım geliştirme hakkında herkese uyan tek bir hüküm vermiyor.

Güvenlik. Veracode'un 2025 GenAI Code Security raporu, 80'den fazla kodlama görevinde 100'ün üzerinde modeli değerlendirdi ve testlerin yüzde 45'inde bilinen bir güvenlik açığı buldu.

Bu oran, belirli bir değerlendirmede üretilen çözümleri anlatıyor. Yapay zekayla hazırlanan ve canlıya alınan değişikliklerin yüzde 45'inin açık içerdiği anlamına gelmiyor. Kritik kodda doğrulama gerektiğini gösteriyor, her kod tamamlamasından korkmamız gerektiğini değil.

Bakım kolaylığına ilişkin sinyaller. GitClear, 2020 ile 2024 arasında değişen 211 milyon kod satırını inceledi. Kopyalanıp yapıştırılan satırların oranı yüzde 8,3'ten yüzde 12,3'e çıkarken yeniden düzenlemeyle ilişkilendirilen değişikliklerin yüzde 25'ten yüzde 10'un altına indiğini bildirdi.

Bu, farklı depoları ve yılları kapsayan geniş bir gözlem. Her değişikliğin nedeninin yapay zeka olduğunu göstermiyor ve tek bir kod tabanında ne olacağını söylemiyor.

Öğrenme ve kısa vadeli anlama. Anthropic'in kontrollü deneyinde, çoğu junior seviyede olan 52 geliştirici bilmedikleri bir Python kütüphanesiyle çalıştı. Yapay zeka kullanan grubun hemen ardından yapılan testteki ortalaması yüzde 50, kodu kendisi yazan grubunki yüzde 67 oldu. Yapay zekaya kavramsal sorular soran veya açıklama isteyen katılımcılar, işi bütünüyle devredenlere göre daha iyi sonuç alma eğilimindeydi.

Araştırmacılar sınırı açıkça belirtiyor: Kullanım biçimleriyle sonuçlar arasındaki bu ilişki nitel bir gözlem, nedensellik kanıtı değil. Çalışma uzun vadeli öğrenme veya bugünkü ajan tabanlı iş akışları hakkında kesin bir sonuç vermiyor.

Üretkenlik, bağlama ve zamana göre değişiyor. METR'ın 2025 başında yaptığı kontrollü deneyde, iyi bildikleri açık kaynak depolarında çalışan 16 deneyimli geliştirici, o dönemin yapay zeka araçlarıyla görevlerini yüzde 19 daha yavaş tamamladı. Buna rağmen daha hızlı olduklarını düşündüler.

METR bu sonucu yazılım geliştirme hakkındaki son hüküm olarak değil, belirli bir dönemin fotoğrafı olarak tanımlıyor. Kurumun Şubat 2026 güncellemesi, daha yeni verilerdeki katılımcı ve görev seçimi sorunları nedeniyle güvenilir bir güncel oran verilemediğini, yeni araçların ilk çalışmaya göre muhtemelen daha fazla hız kazandırdığını söylüyor.

Copilot kullanımını inceleyen ayrı bir ön çalışma, ele aldığı açık kaynak projelerinde üretkenlik artışının daha çok az deneyimli katkıcılarda toplandığını buldu. Çekirdek geliştiriciler yüzde 6,5 daha fazla kod incelerken kendi yazdıkları kod miktarı yüzde 19 azaldı.

Bu bulgu araştırılan projelere ve yönteme ait. Her kıdemli geliştiricinin aynı kaybı yaşayacağını kanıtlamıyor.

Bu çalışmaların birlikte desteklediği daha dar bir sonuç var: Kod üretme hızı, kod kalitesi, öğrenme ve inceleme kapasitesi kendiliğinden aynı yönde ilerlemiyor. Bedelin nerede çıkacağını çalışma biçimi belirliyor.

Tek Başına Çalışınca Risk Nasıl Değişiyor?

Bir ekip, tasarım tartışmaları, kod incelemesi, birlikte çalışma ve olay müdahalesi sayesinde anlayışı insanlar arasında dağıtabilir. Bu düzen ortak bir kavrayışı garanti etmez, fakat bir varsayımı sorgulayacak veya bağlamı bağımsız olarak taşıyacak başka birinin bulunma ihtimalini artırır.

Tek başıma çalışırken öneriyi kabul eden kişiyle onu sorgulaması gereken kişi aynı. Bir ajanla hızlı ilerlediğim bir saatin ardından, sonucu taze ve kuşkucu bir gözle yine benim incelemem gerekiyor. Kestirme yolu kullanmamış ve bu nedenle onu daha net görebilecek ikinci biri yok.

Bu durum solo geliştiricilerin her ekipten daha fazla anlama borcu taşıdığını kanıtlamıyor. Sorunun biçimini değiştiriyor. Ekipte eksik anlayış farklı insanlara dağılabilir veya aralarında gizlenebilir. Tek başına çalışırken tek bir yerde birikiyor. Canlıda sorun çıktığında sistemi açıklayamıyorsam odada başvurabileceğim başka bir zihinsel model bulunmuyor.

Bu mesele, Yapay Zeka Kod Yazmayı Ucuzlattı, Doğrulamayı Değil yazısında ele aldığım ekip kapasitesi sorunundan farklı. Oradaki soru, ekibin artan çıktı miktarını doğrulayıp doğrulayamadığı. Buradaki soru ise sorumluluğu taşıyan kişinin doğruladığı sistemi gerçekten anlayıp anlamadığı.

Bu Araçları Kullanmaya Devam Ederken Ne Yapıyorum?

Yapay zekayı daha az kullanmaya çalışmıyorum. Ürettiğim işi gerçekten sahiplenebileceğim sınırlar içinde kalmaya çalışıyorum.

Önce Niyeti ve Kabul Ölçütlerini Yazıyorum

Ajan koda dokunmadan önce problemi, sınırları ve değişmemesi gereken davranışları sade bir dille ifade etmek istiyorum. Kod yine asıl uygulama ve okunabilir olmak zorunda. Fakat bir kararın neden var olduğuna dair elimizde kalan tek kayıt kod olmamalı.

Kod üretilmeye başlamadan başarının ne demek olduğunu açıklayamıyorsam, sonradan geçen testler bu eksikliği benim yerime gideremez.

Değişikliği Anlayabileceğim Büyüklükte Tutuyorum

Uzun bir otonom çalışma verimli olabilir, fakat ben ilk yanlış varsayımı fark edene kadar birden fazla mimari sınırı aşmış olabilir. Küçük değişikliklerde gerekçeyi incelemek, davranışı sınamak ve gerektiğinde geri dönmek daha kolay.

Durma kuralım basit: Üzerinde çalıştığım değişikliği ajan yeniden anlatsın diye ona dönmeden açıklayamıyorsam kapsam fazla büyümüş veya ben fazla hızlanmışım demektir.

Yapay Zekayı Sadece İş Devretmek İçin Kullanmıyorum

Ajanın seçenekleri karşılaştırmasını, varsayımları bulmasını, bilmediğim yolları açıklamasını ve benim yorumuma itiraz etmesini istiyorum. Sonucu kabul etmeden önce kararı kendi cümlelerimle yeniden kuruyorum. Yapay zekanın ürettiği açıklama zihinsel model oluşturmaya yardımcı olabilir, ama o modele gerçekten sahip olduğumu kanıtlamaz.

Kritik Değişiklikleri Doğrulanana Kadar Güvenilmez Kabul Ediyorum

Kimlik doğrulama, yetkilendirme, ödeme, kullanıcı verisi ve sistem sınırları daha kuşkucu bir süreç gerektiriyor. Uygulamayı inceliyor, testleri üretilen koddan değil gereksinimden çıkarıyor, uygun yerlerde statik analiz ve güvenlik kontrolleri çalıştırıyor, değişikliğin izlenebilir ve geri alınabilir olmasını sağlıyorum.

İlk modelin çıktısını ikinci bir modele inceletmek ek bir kontrol sağlar. Bağımsız sorumluluk yaratmaz. İki model de aynı kör noktayı paylaşabilir ve yayımlama kararı yine bana aittir.

Tip Sistemini Koruyucu Katman Olarak Kullanıyorum

Tip kurallarını kod üretimi sırasında uygulayan bir yöntem üzerine yapılan çalışma, kendi TypeScript testlerinde üretilen kodun derleme hatalarının yüzde 94'ünün tip kontrolünde yakalanan sorunlardan kaynaklandığını buldu. Araştırmacıların önerdiği yöntem derleme hatalarını yarıdan fazla azalttı. Bu, belirli test ortamında elde edilen yararlı bir sonuç. Tip sistemlerinin yapay zekanın bütün hatalarının yüzde 94'ünü yakaladığı anlamına gelmiyor.

Tipler, mekanik olarak geçersiz pek çok durumu kod çalışmadan önce reddedebilir. Gereksinimin doğru olduğunu, yetki kuralının uygun kurulduğunu veya iş davranışının hedeflenen sonuçla eşleştiğini kanıtlayamaz. Koruyucu bir katmandır, incelemeci değildir.

Doğrulamayı Katmanlandırıyor ve Nerede Duracağımı Biliyorum

Testler, tip kontrolleri, linter'lar, bağımlılık denetimleri, güvenlik analizleri, loglar ve geri alma yolları farklı hata sınıflarını yakalar. Tek bir kontrole veya yorgun muhakememe güvenmek yerine bunları birlikte kullanıyorum.

Son kapı yine anlamak. Bütün kontroller geçse bile değişikliği, varsayımlarını ve muhtemel hata biçimlerini açıklayamıyorsam iş hazır değildir. Otomasyon kuşkuyu tekrar edilebilir hale getirmeli, sorumluluğu ortadan kaldırmamalı.

Proje Kuralları Herkes İçin AI Yasağı Anlamına Gelmiyor

Bazı açık kaynak projeler yapay zekayla üretilen katkılara katı sınırlar koyuyor. Zig, yönettiği topluluk alanlarında büyük dil modeliyle üretilen içeriği yasaklıyor. NetBSD, LLM tarafından üretilen kodu çekirdek ekipten önceden yazılı izin alınmadıkça "tainted" kabul ediyor. QEMU ise kodun kaynağı, telif, lisans ve katkı sahibinin sorumluluk beyanı nedeniyle yapay zeka üretimi katkıları şimdilik reddediyor.

Bu politikalar gerçek, fakat her ürün ekibinin yapay zekayı reddetmesi gerektiğini veya tek gerekçenin anlama borcu olduğunu kanıtlamıyor. Sorumlu yazılım geliştirmenin kodun nereden geldiğini, hangi kurallara tabi olduğunu ve arkasında kimin durabildiğini bilmeyi de içerdiğini gösteriyor.

Fatura Sistem Değişmek Zorunda Kaldığında Çıkıyor

Daha güçlü bir model, bilmediğimiz kodu bugünün araçlarından daha iyi açıklayabilir veya yeniden düzenleyebilir. Fakat ne bir model ne de bir insan, yalnızca uygulamaya bakarak kayda geçmemiş niyeti güvenilir biçimde geri getirebilir. Bir sınırın neden önemli olduğu, hangi seçeneğin neden elendiği, müşteri davranışının kararı nasıl etkilediği veya sistemin hangi ödünü koruması gerektiği kodda yazmıyorsa bu bilgi eksik kalır.

Bu gerekçeler geçici bir konuşmanın dışında hiç var olmadıysa başka bir modelden kodu temizlemesini istemek, incelenmemiş eski varsayımların üzerine yenilerini koyabilir.

Artık kıt olan beceri her satırı elle yazmak değil. Yayımlanan işin arkasında durabilmek: neden var olduğunu, neyi koruduğunu, nasıl doğrulandığını ve ne zaman yanlış olduğunu bilmek.

Solo bir kurucu için bu sonradan eklenecek bir kalite katmanı değil, işin kendisi. Anlamadan kazanılan hız bedelsiz bir üretkenlik değil. Borçtur ve faturayı devralacak başka kimse yoktur.