Yazılım Fabrikaları Neden Başarısız Oluyor

Bir ajan bir saatte günlerce yazılacak kadar kod üretebiliyor. Peki işıkları tamamen söndürüp fabrikayı ajanlara bırakmak neden hâlâ çökmeyle sonuçlanıyor?

Bu yazıya ilham veren konuşmada, HumanLayer’dan Dex Horthy kendi ekibinin denediği bir hayali anlatıyor: insan kod incelemesini tamamen aradan çıkaran, üretimi baştan sona ajanlara devreden bir “yazılım fabrikası”. Test ve izleme sistemleri güvenliği sağlayacak, insanlar yalnızca hedefi verecekti. Deney 2025’in ortasında başladı ve birkaç ay sonra terk edildi. Sebep model gücünün yetersizliği değildi; ajanlar çalışıyordu, kod da üretiliyordu. Sorun üretilen kodun taşıdığı mimari borcun görünmeden ve hızla birikmesi, sonunda bazı bölümlerin baştan yazılmak zorunda kalmasıydı.

Bu deneyimin ilginç yanı, başarısızlığın “daha iyi bir promptla” veya “daha akıllı bir modelle” çözülebilecek bir şey olmamasıydı. Asıl mesele, otonom üretimi çevreleyen bütün mühendisliğin —promptlar, araç döngüleri, orkestrasyon, testler, izleme— yanlış yere yatırım olmasıydı.

Yazılım fabrikası modeli, üretimi otomatikleştirmenin yeterli olduğunu varsayar. Oysa asıl kıt kaynak üretim değil, üretilenin uzun vadede sağlam kalmasını sağlayan yargıdır.

Ben bu konuşmadan, tamamen otonom kod üretimine geçmeden önce herkesin düşünmesi gereken birkaç temel fikir çıkardım. Bunları bir araç reçetesi olarak değil, kendi ekibinizin çalışma biçimine uyarlayabileceğiniz ilkeler hâlinde anlatacağım.

1. “Yazılım fabrikası” neden bu kadar cazip?

Fikir basit ve güçlü: Eğer bir ajan kod yazabiliyor, testi çalıştırabiliyor, hatayı görüp düzeltebiliyorsa, bu döngüyü yeterince sağlamlaştırıp insanı aradan çıkarabiliriz. İnsan yalnızca ne istediğini söyler; fabrika üretir, test eder, dağıtır. Üretim ucuzladıkça daha çok özellik, daha çok paralel iş, daha az bekleme.

Bu tabloda insan kod incelemesi bir darboğaz gibi görünür. Yavaştır, ölçeklenmez, yorulur. Onu kaldırıp yerine otomatik kontroller koymak doğal bir sonraki adım gibi durur. Konuşmanın çıkış noktası da tam olarak bu cazibeyi ciddiye alıp sonuna kadar denemekti.

2. Koşum mühendisliği neyi çözer, neyi çözemez

Modelin etrafına kurduğumuz her şeye burada “koşum” diyelim: promptlar, sistem talimatları, araç çağrıları, ajan döngüleri, orkestrasyon katmanı, testler ve izleme. Koşum mühendisliği bu katmanı iyileştirme işidir ve gerçekten değerlidir. İyi bir koşum, modelin daha isabetli araç kullanmasını, döngüden düşmemesini, hatadan toparlanmasını sağlar.

Fakat koşum, modelin göremediği bir şeyi ona gösteremez. Döngüyü ne kadar sağlamlaştırırsanız sağlamlaştırın, modelin “iyi mimari” ile “kötü mimari” arasındaki farkı içselleştirmesini üretemezsiniz. Koşum, doğru sinyal varsa onu güçlendirir; sinyal yoksa yokluğu daha verimli hâle getirir.

Koşum mühendisliği bir çarpandır. Elinizde doğru bir yargı sinyali varsa onu büyütür; yoksa sıfırı daha hızlı büyütür.

3. Asıl sınır modelin ödüllendirildiği yerde

Konuşmanın en can alıcı iddiası şu: Bugünkü kod modelleri pekiştirmeli öğrenmeyle eğitiliyor ve eğitim döngüsü onları çoğunlukla ikili bir sinyalle ödüllendiriyor — test geçti mi, geçmedi mi? Model, kendisine ne ödül veriliyorsa onu optimize eder. Testi geçmek saniyeler içinde ölçülebilen bir sinyaldir; mimarinin bozulması ise haftalar, aylar sonra ortaya çıkar.

Bu gecikme çok önemli. Pekiştirmeli öğrenme, sonucu hemen görülebilen davranışları güçlendirir. “Bu değişiklik altı ay sonra kod tabanını değiştirilemez hâle getirecek” türünden gecikmeli bir maliyeti eğitim döngüsü yakalayamaz. Dolayısıyla model, testi geçiren en kısa yolu bulmakta ustalaşırken tasarımı koruma konusunda kayıtsız kalır.

Buradan çıkan rahatsız edici sonuç: Bir modelin kod tabanı kalitesini uzun vadede koruma becerisini ölçen sağlam bir benchmark yok. Mevcut değerlendirmeler ayrık görevlerde başarı/başarısızlık oranını ölçer; her değişiklikle biraz daha büyüyen ve gelecekteki her işi zorlaştıran sessiz mimari erozyonu ölçmez.

4. Test geçmek ile iyi tasarım aynı şey değil

Bir modelin ürettiği kod bütün testleri geçebilir ve aynı anda tasarımı biraz daha kötüleştirebilir. Kopyalanmış bir mantık, gereksiz bir bağımlılık, yanlış katmana konmuş bir sorumluluk, tek bir dosyada şişen bir sorumluluk yığını — bunların hiçbiri testi kırmaz. Yeşil test, “çalışıyor” demektir; “doğru yerde ve sürdürülebilir biçimde çalışıyor” demek değildir.

Modelin gördüğü sinyal:      test yeşil  → ödül
Modelin görmediği maliyet:   +1 kopya mantık
                             +1 sızdıran soyutlama
                             +1 yanlış yere konmuş sorumluluk
                             → aylar sonra: değiştirilemez modül

Tek tek bakıldığında hepsi küçük. Biriktikçe kod tabanı, her yeni özelliğin daha pahalı olduğu bir yapıya dönüşür. İnsan gözü aradan çıktığında bu birikimi fark edecek kimse kalmaz; testler yeşil yandığı sürece fabrika mutlulukla üretmeye devam eder.

5. Işıkları söndürmek neden erken bir hamle

İnsan incelemesini kaldırmanın cazibesi, onu yalnızca bir hız engeli olarak görmekten gelir. Oysa kod incelemesi aynı zamanda tasarım borcunun biriktiği tek yerdir. İnceleme, “bu test geçiyor mu” sorusundan farklı bir soru sorar: “Bunu altı ay sonra da rahatça değiştirebilir miyiz?”

Bu soruyu bugün güvenilir biçimde soran otomatik bir sistem yok. Testler ve izleme, davranışsal doğruluğu yakalar; mimari sağlamlığı değil. Dolayısıyla insanı aradan çıkardığınızda hatayı değil, hatanın gecikmeli ve pahalı türünü davet etmiş olursunuz. Borç sessizce birikir ve fatura, en kötü zamanda, toplu hâlde gelir.

6. Çözüm tam otomasyon değil, erken hizalama

Konuşmanın önerdiği yol otomasyondan vazgeçmek değil, eforun ağırlığını farklı bir yere kaydırmaktır: kod üretilmeden önceki hizalamaya. Modeller üretimde hızlıdır; asıl kazanç, ne üretileceğine dair ortak anlayışı önden netleştirmekten gelir.

• Ürün incelemesi: Ne için, kim için yapıyoruz? Kabul ölçütü nedir?
• Mimari: Bu iş sistemin neresine oturuyor, hangi sınırları koruması gerekiyor?
• Program/teknik tasarım: Çözümü uygulamaya dökmeden önce yaklaşımı yazıya geçirin.
• Dikey dilimler: İşi baştan sona çalışan, küçük ve incelenebilir dilimlere bölün.

Modelle geçirilen otuz dakikalık bir tasarım tartışması, sonradan yapılacak günlerce yeniden yazımı önleyebilir. Yapay zekâyı burada üretimi otomatikleştirmek için değil, hizalanmayı hızlandırmak için kullanırsınız: seçenekleri çıkarması, ödünleşimleri özetlemesi, taslağı eleştirmesi için.

Yapay zekâyı üretimin yerine değil, hizalanmanın hızlandırıcısı olarak kullanın. Otomatikleştirilmesi gereken şey karar değil, karara giden yoldaki tekrardır.

7. İnsanı nereye koymalı

Kısıtlar Teorisi’nin basit bir uyarlaması burada işe yarar: Sistemi en zayıf halkası belirler. Yapay zekâ çağında bu halka artık kod üretimi değil, üretilenin doğru ve sürdürülebilir olduğunun kanıtıdır. O hâlde insanı üretim hattına değil, bu darboğazın olduğu yere koyun.

Pratikte bu şu ayrımı getirir: Modele, sınırları belli ve doğrulanabilir işleri güvenle verin — izole bir hatayı bulmak, belirli bir modülü yeniden düzenlemek, iyi tanımlı bir dönüşümü uygulamak. Sistem düzeyindeki mimari kararları, katmanlar arası sınırları ve uzun vadeli sürdürülebilirlik tercihlerini ise insan yargısına bırakın. İnsan kod okumayı bırakmamalıdır; okumayı bıraktığı an, borcun biriktiğini görecek son göz de kapanır.

Pratik bir başlangıç

Bütün akışı bir günde değiştirmeniz gerekmiyor. Otonom üretime doğru ilerlerken şu sırayı deneyin:

1. Kod yazılmadan önce kısa bir tasarım notu isteyin; yaklaşımı modelle birlikte netleştirin.
2. İşi baştan sona çalışan, incelenebilir küçük dilimlere bölün.
3. Testin yeşil olmasını “bitti” değil, “davranış doğru” olarak okuyun.
4. Her dilimde bir insan, “bunu altı ay sonra rahatça değiştirebilir miyiz?” sorusunu sorsun.
5. Modele izole ve doğrulanabilir işleri verin; sistem düzeyindeki kararları insanda tutun.
6. Tekrarlayan bir mimari hatayı gördüğünüzde onu kalıcı bir kurala, teste ya da tasarım rehberine çevirin.

Son söz

Otonom kod üretiminin hayali yanlış değil; erken. Bugünkü modeller testi geçmekte ustalaşıyor, ama testin ölçmediği şeyi —tasarımın uzun vadeli sağlığını— korumak için güvenilir bir sinyalleri yok. Koşum mühendisliği bu eksikliği kapatamaz; yalnızca var olanı büyütür.

Benim bu konuşmadan çıkardığım asıl sonuç şu: Rekabet avantajı, insanı hattan tamamen çıkaran ekipten değil, insanı doğru yere —tasarıma ve incelemeye— koyan ekipten gelecek. Üretimi hızlandırmak kolaylaştı; asıl beceri, hızlanan üretimin sağlam kalmasını sağlamak olacak.

Geleceğin farkı fabrikayı kurabilmek değil, fabrikanın ürettiğinin aylar sonra da ayakta kaldığından emin olabilmek olacak.

Kaynak

• YouTube — Harness Engineering is not Enough: Why Software Factories Fail (Dex Horthy, HumanLayer · AI Engineer)