Kod Tek Kullanımlık Hale Geldiğinde: Niyet, Test, Domain Modeli ve Mimari Kararlar

Disposable code fikri son bir yılda slogandan araca dönüştü. GitHub Spec Kit, Kiro ve Tessl gibi spec-driven development araçları yaygınlaştı; Spec Kit'in GitHub deposu Ekim 2026'da 140 binden fazla yıldıza sahip. Thoughtworks Technology Radar bu yaklaşımı Kasım 2025'te 'Assess' halkasına koydu ve iş akışlarının ağır ve fazla kuralcı olabileceği uyarısını ekledi.

Agent talimat dosyaları standartlaştı. Aralık 2025'te kurulan Agentic AI Foundation'a OpenAI AGENTS.md'yi, Anthropic MCP'yi devretti; AGENTS.md bugün 60 binden fazla açık kaynak projede kullanılıyor.

Riskin adı da kondu: Radar'ın Nisan 2026 sayısı 'codebase cognitive debt' kavramını 'Caution' halkasına aldı. Bu kavram, sistemin gerçekte ne yaptığı ile ekibin onu ne kadar anladığı arasında büyüyen açığı anlatıyor ve öneri net: architectural fitness function ve Agent'lar için geri bildirim sensörleri. Güven verisi de değişmedi: Stack Overflow 2026 anketinde geliştiricilerin yüzde 48'i AI çıktısına yalnızca doğrulayabildiğinde güveniyor. DORA'nın 2026 başındaki ROI raporu da kazancın kod yazma hızında değil, review ve teslim akışının geri kalanında belirlendiğini vurguluyor.

Disposable code (tek kullanımlık kod), atılıp yeniden üretilmesi ucuz olan koddur. Bir ajana net bir tanım ve testler verip bir modülü 20 dakikada sıfırdan yazdırabiliyorsanız, o modülün koduna duygusal bağlılığınızın ekonomik bir karşılığı kalmaz.

Bu, kodun özensiz olabileceği anlamına gelmiyor. Prod'da çalışan kod hâlâ okunur, güvenli ve gözlemlenebilir olmalı. Değişen şey, kodun kaynak değil çıktı gibi ele alınması. Derleyicinin ürettiği binary'yi kimse elle düzeltmez; kaynağı düzeltip yeniden derler. Disposable code fikri, kaynak kavramını bir kat yukarı, niyet ve spesifikasyon seviyesine taşır.

Anti-pattern: 'nasılsa yeniden yazarız' diyerek hiçbir şey yazmadan prototipi prod'a almak. Kodu atabilmek için, onu yeniden üretecek bilgiye sahip olmanız gerekir. O bilgi yoksa elinizdeki kod disposable değil, sadece bakımsızdır.

Kod ne yapıldığını söyler, neden yapıldığını söylemez. Bir indirim fonksiyonunda neden yüzde 15 sınırı olduğu, neden belirli kullanıcıların hariç tutulduğu, koddan çıkarılamaz. Ajan bu kodu yeniden yazarken sınırı kaldırırsa, testler de yoksa, kimse fark etmez.

Niyeti kalıcı kılmanın yolları: kabul kriterleri (acceptance criteria), örneklerle tanımlanmış davranış (specification by example), karar notları ve ajan talimat dosyaları (CLAUDE.md, AGENTS.md gibi). Birgitta Böckeler'in Ekim 2025'te martinfowler.com'da yayımlanan spec-driven development incelemesi bu yaklaşımları üç seviyede ayırıyor: spec-first, spec-anchored ve spec-as-source. Kod disposable olacaksa en az spec-anchored seviyesine, yani spesifikasyonun görev bittikten sonra da yaşatıldığı seviyeye ihtiyacınız var.

Pratik eşik: bir modülün niyetini bir sayfada anlatamıyorsanız, o modülü güvenle yeniden ürettiremezsiniz. O sayfada en az üç şey bulunmalı: modülün çözdüğü iş problemi, uyması gereken kurallar ve bilinçli olarak yapmadığı şeyler.

Kod atılabiliyorsa testler, davranışın neyin korunması gerektiğini söyleyen tek mekanik garantidir. Ama her test bu rolü oynayamaz. Implementasyon detayına bağlı testler, örneğin bir private metodun kaç kez çağrıldığını doğrulayan mock'lu testler, kod yeniden yazıldığında toplu halde kırılır ve hiçbir şey anlatmaz.

Kalıcı test, dışarıdan görünen davranışı doğrular: bu girdiye bu çıktı, bu API çağrısına bu cevap, bu olaya bu yan etki. Contract test (sözleşme testi) ve property-based test (özellik tabanlı test) burada değerlidir. Property-based test, 'sıralı bir listeyi tekrar sıralamak sonucu değiştirmez' gibi bir kuralı yüzlerce rastgele girdiyle sınar.

Sık görülen tuzak: aynı ajana hem kodu hem testi yazdırıp ikisini birlikte onaylamak. Ajan yanlış anladıysa, test de aynı yanlışı kilitler. Testleri niyetten, kodu testlerden türetin ve testleri bir insan gözden geçirsin.

Bir lojistik ürününde 'gönderi', 'araç', 'rota' ve 'kapasite limiti' kavramları, hangi framework'le yazılırsa yazılsın değişmez. Domain-driven design (alan odaklı tasarım) bu kavramları ubiquitous language (ortak dil) ile isimlendirir ve kod, dokümantasyon ve konuşma aynı kelimeleri kullanır.

Kod disposable olduğunda domain modeli, yeniden üretilen her versiyonun uyması gereken iskelet haline gelir. Bir ajan 'kargo' ile 'gönderi'yi farklı anlamlarda kullanırsa, iki modül birbiriyle konuşamaz. Bu yüzden terimler sözlüğü, invariant'lar (her zaman doğru olması gereken kurallar, örneğin 'bir aracın toplam yükü maksimum kapasiteyi aşamaz') ve bounded context sınırları yazılı olmalı.

Örnek senaryo: invariant'lar domain katmanında kodlanmış ve test edilmişse, UI ve API katmanlarını ajanla yeniden yazdırmak düşük risklidir. Domain katmanını yeniden yazdırmak ise insan gözetimi gerektiren bir karardır.

Her kod parçası aynı ölçüde atılabilir değil. Bir React bileşenini yeniden yazmak saatler alır; veritabanı şemasını, event formatını ya da public API sözleşmesini değiştirmek ise müşterileri, veriyi ve diğer ekipleri etkiler. Amazon'un 'tek yönlü kapı ve çift yönlü kapı' ayrımı burada işe yarar: geri alınabilen kararlar hızlı verilir, geri alınamayanlar yavaş ve yazılı verilir.

Architecture Decision Record (ADR, mimari karar kaydı) bu yavaş kararların hafızasıdır: bağlam, değerlendirilen seçenekler, seçilen yol ve sonuçları. Kod yeniden üretildiğinde ADR'lar, ajanın hangi sınırların içinde kalması gerektiğini söyler.

Pratik kural: veri şemaları, dış API'ler, event sözleşmeleri ve güvenlik sınırları disposable değildir. Bunları değiştiren her ajan çıktısı, migration planı ve insan onayı ister. Geri kalan katmanlar ise yeniden üretmeye açıktır.

Kodu atabilmek için onu çevresinden koparabilmeniz gerekir. Michael Feathers'ın seam (dikiş) kavramı, bir parçayı diğerlerine dokunmadan değiştirebileceğiniz yerleri anlatır. Net arayüzleri olan küçük modüller disposable code için idealdir; her şeyin her şeye bağlı olduğu bir monolit dosyası ise değildir.

İyi bir ölçüt: bir modülün dışarıya açtığı yüzey küçük, içi büyük olsun. Örneğin bir fiyatlandırma modülü dışarıya tek bir 'fiyat hesapla' fonksiyonu ve onun sözleşme testlerini açıyorsa, içini istediğiniz kadar yeniden yazdırabilirsiniz.

Anti-pattern: ajanın her seferinde tüm repoyu bağlam olarak alıp birden fazla modüle aynı anda dokunması. Bu, değişiklik sınırını bulanıklaştırır ve review'u imkânsız hale getirir. Değişiklikleri modül sınırına hapsetmek, hem ajanın hata yüzeyini hem de review yükünü küçültür. Basit bir ölçü olarak, tek bir ajan görevinin değiştirdiği dosyaların tek bir modül klasöründe kalmasını hedefleyin.

Kod ucuzladığında review pahalılaşır. Bir ajan günde onlarca PR açabilir, ama her PR'ı bir insanın anlaması hâlâ dakikalar ister. DORA'nın Eylül 2025 raporu, yazılım profesyonellerinin yüzde 90'ının AI kullandığını ama yalnızca yüzde 24'ünün AI çıktısına yüksek güven duyduğunu bildirdi. Ekim 2026'da yayımlanan Stack Overflow anketinde tablo benzer: geliştiricilerin yüzde 48'i AI çıktısına ancak kolayca doğrulayabildiğinde güveniyor, önemli kararlarda güvenenlerin oranı yaklaşık yüzde 7. DORA'nın 2026 başındaki ROI raporu da AI kodunu doğrulamanın getirdiği yükü 'verification tax' olarak adlandırıyor. Bu açık, review'un neden darboğaz olduğunu açıklıyor.

Disposable code yaklaşımı review'u değiştirir: satır satır kod okumak yerine, niyetin, testlerin ve sınırların korunduğunu doğrularsınız. Diff'te bir test silindi mi? Bir invariant gevşetildi mi? Şema değişti mi? Bu sorular otomatik kontrollere de dönüştürülebilir.

Sahiplik de yeniden tanımlanmalı. Kodu kimin yazdığı değil, o davranıştan kimin sorumlu olduğu önemli. Her modülün bir insan sahibi, bir niyet dokümanı ve bir test seti olmalı; bu üçlü yoksa kodu atmak bilgi kaybetmek demektir.