Sıfırdan hızlı, mevcut sistemde yavaş: agent çağında brownfield'in gerçek maliyeti

Geçen hafta iki iş yaptım. Birincisi sıfırdan bir işti: bir agent’a ne istediğimi tarif ettim, çıkardığı planı okuyup düzelttim, adım adım yazdırdım. Birkaç gün sonra elimde çalışan, testleri olan, deploy edilmiş bir uygulama vardı. Aynı işi birkaç yıl önce yapsaydım haftalarımı alırdı; bundan şüphem yok.

İkincisi, yıllardır production’da olan bir sistemde tek bir modülü — bir CRM modülünü — eski uygulamadan yeni panele taşımaktı. Kod olarak küçük bir işti: birkaç ekran, birkaç tablo, bir avuç rapor. Bir hafta sürdü.

Bu iki süreyi yan yana koyduğumda çıkan gözlem, yazının konusu: hızın nereden geldiğini yanlış yerde arıyoruz. Agent’ın hızlandırdığı şey kod üretmek. Yıllardır çalışan bir sistemde kod üretmek işin küçük parçası; büyük parçası, üretilenin doğru olduğunu bilmek. O parça hızlanmadı.

İki iş, iki farklı darboğaz

İki terimi net tanımlayarak başlayayım, çünkü yazının geri kalanı bu ayrımın üstünde duruyor.

Greenfield, hiçbir mevcut davranışa uymak zorunda olmayan iştir: doğrunun ne olduğuna siz karar verirsiniz. Veri modeli boş bir sayfadır, kullanıcı henüz yoktur, verdiğiniz her karar birkaç saat içinde geri alınabilir.

Brownfield, çalışan bir sistemin davranışını bozmadan değişiklik yapma işidir. Burada doğru zaten vardır; sizin tanımladığınız değil, sistemin yıllar içinde edindiği bir doğrudur. Üstelik bu doğrunun büyük kısmı hiçbir dökümanda yazmaz.

Fark, zorluk seviyesi farkı değil; bilginin nerede durduğu farkı:

	Greenfield	Brownfield
”Doğru” nedir?	Siz tanımlarsınız	Sistem çoktan tanımlamış
Bilgi nerede?	Sizde ve talebi verende	Kodda, veride, insanların kafasında
Hatanın bedeli	Geri alınabilir	Canlı veriye ve kullanıcıya değer
Baskın maliyet	Üretim	Doğrulama

Agent bilginin sizde olduğu işte çarpan, bilginin sistemde olduğu işte asistan. Aynı araç, iki farklı verim. Aynı aracın farklı ellerde farklı sonuç ürettiğini daha önce yazmıştım; bu yazı aynı gözlemin araç ya da kişi yerine işin türü tarafı.

Brownfield’de asıl taşınan şey kod değil, kuraldır

Yıllardır çalışan bir sistemde bir parçayı yerinden oynattığınızda taşıdığınız şey satırlar değil, o satırların içine sinmiş iş kuralları oluyor. Bu kurallar üç yerde saklanır ve üçü de farklı bir kazı yöntemi ister.

Kodun içindeki yazılmamış istisnalar

Katmansız yazılmış eski kodda kural, akışın ortasında bir if olarak durur. Kabaca şuna benzer:

public function updateStatus(int $id, int $status): void
{
    $customer = $this->find($id);

    // sözleşmesi bitmiş kayıtta durum değiştirilemez, bayi hesapları hariç
    if ($customer->contract_end < date('Y-m-d') && $customer->type != 3) {
        throw new DomainException('İşlem yapılamaz');
    }

    // 7 = arşiv; arşive düşen kayıt temsilcisiz bırakılır
    if ($status === 7) {
        $this->clearOwner($id);
    }

    $this->save($id, $status);
    $this->log($id, $status);
}

Bu on beş satırda en az üç iş kuralı var: sözleşmesi biten kayıtta işlem yapılamaz, bir hesap tipi bu kuralın dışındadır, arşive düşen kaydın sahibi silinir. Üçü de gerçek. Üçü de yalnızca burada yazıyor.

İşi uzatan şey bu kuralların sayısı değil; her birinin önünde durup “bu hâlâ isteniyor mu, yoksa yıllar önce yaşanmış bir olayın izi mi?” diye sormak zorunda olmanız. Benim örneğimde bunlardan biri bir sözleşme maddesiydi, biri eski bir hatanın üstünü kapatmak için konmuştu, biri de artık kimsenin kullanmadığı bir sürecin kalıntısıydı. Kod üçünü de aynı tonda, aynı kararlılıkla yazıyor.

Verinin içindeki örtük kurallar

İkinci saklanma yeri veritabanı. Şemada görünmeyen ama davranışı belirleyen kurallar: bir status kolonundaki sayıların ne anlama geldiği, NULL bir alanın “bilinmiyor” mu yoksa “uygulanmaz” mı demek olduğu, adı artık taşıdığı veriyi yansıtmayan kolonlar.

Şemaya bakarak hiçbirini bilemezsiniz; yıllara yayılmış veriye bakarak çoğunu çıkarabilirsiniz. Pratikte yaptığım şey basit: belirsiz her kolon için üretim verisinde dağılım alıyorum. Bir kolonun gerçekte aldığı değerlerin listesi, o kolonun etki alanını her dökümandan daha dürüst anlatır — ve yeni tarafa koyacağım kısıtları (enum, nullable, foreign key) bu liste belirler.

İnsanların kafasındaki gerekçe

Üçüncüsü hiçbir yerde aranamaz. Kod bir kuralın ne olduğunu söyler; neden konduğunu çoğu zaman yalnızca insanlar bilir. Bu yüzden soruları tek tek değil toplu olarak biriktiriyorum ve birkaç kısa görüşmede soruyorum: “şu davranış bilerek mi böyle?” Aldığım cevaplardan biri “evet, sözleşmede var” olurken bir diğeri “hayır, o zaten yanlıştı” olabiliyor. İkinci cevap, taşıma sırasında düzeltilecek tek meşru kalemdir; gerisi korunur.

Agent nerede çarpan, nerede asistan

Bu bir “AI işe yaramıyor” yazısı değil; tam tersi. Brownfield işinde de ciddi biçimde işe yaradı — ama belirli üç kalemde.

Hızlandırdıkları:

• Mekanik dönüşüm. Bir kalıbı başka bir kalıba çevirmek — iskeletler, yönlendirmeler, doğrulama sınıfları, sorguların yeni karşılığı — neredeyse tamamen mekanik iş. Saatler değil dakikalar sürüyor.
• Kod okuma ve kural çıkarma. Eski kodu dosya dosya taratıp “burada hangi kurallar var, hangi koşullar hangi alanlara bağlı” özeti çıkarmak. Elle bir gün sürecek okuma birkaç turda bitiyor. Sonuç bir cevap değil, bir soru listesi — ama doğru soruları toplu hâlde önünüze koyması tek başına değerli.
• Doğrulama araçları. Eski ve yeni tarafın aynı girdiye aynı çıktıyı verdiğini karşılaştıran tek kullanımlık script’ler, kritik akışlar için karakterizasyon testleri, rapor toplamlarını iki taraftan çekip diff’leyen küçük araçlar. Kendi diff’imi denetleyen düzenin neyi hızlandırıp nerede yetmediğini anlatırken de aynı yere varmıştım: fayda üretimde değil, denetimde.

Hızlandırmadıkları:

• Kuralın geçerliliğine karar vermek. Agent bir kuralı bulabiliyor; o kuralın hâlâ istenip istenmediğini söyleyemiyor. Bu bilgi kodda değil, insanlarda. Kodda olan tek şey, birinin bir gün öyle yazmış olması.
• Doğrulamak. Yeni tarafın “çalışıyor” görünmesi beş dakikalık iş; eskisiyle aynı sonucu ürettiğini göstermek günlük iş. Bir sapmanın “hata” mı yoksa “eskisi zaten yanlıştı” mı olduğuna karar vermek de işin en yavaş kısmı.
• Geçiş ve koordinasyon. Hangi akşam geçileceği, o sırada kimin veri girmeyeceği, geri dönüş yolunun ne olacağı, kullanıcıya ne söyleneceği. Teknik zorluk değil; ama takvimde yer kaplıyor.

Kalıcı ders şu: agent yaygın olanı çok iyi yazıyor, ama problemin kendine özgü tarafını görmüyor. Yıllardır çalışan bir sistemde iş, tam olarak o kendine özgü taraftan ibaret.

Bir haftanın dürüst dökümü

Baştaki örneğin yaklaşık dağılımı, beş iş günü üzerinden:

İş kalemi	Süre	Agent’ın payı
Keşif, kural çıkarma, soruların cevaplanması	~1,5 gün	Yüksek — taramayı o yaptı, kararı ben verdim
Asıl kod yazımı	~1 gün	Çok yüksek
Parite doğrulama	~1,5 gün	Orta — araçları üretti, yorumu bende
Kenar durumlar, raporlar, entegrasyonlar	~0,5 gün	Düşük
Geçiş, izleme, düzeltmeler	~0,5 gün	Yok

Tek cümleye indirirsem: kod yazmak beş günün bir günü. Kalan dört gün, kodun ne yapması gerektiğini öğrenmek ve yaptığını kanıtlamakla geçti. Agent’ın en güçlü olduğu kalem, toplamın beşte biri kadar.

Sıfırdan yaptığım işte oran neredeyse tersineydi: orada zamanın çoğu üretime gidiyordu, çünkü uyulacak bir geçmiş yoktu. İki işin sürelerinin birbirine yaklaşmasının sebebi bu.

Brownfield işini nasıl tahmin ediyorum

Bu gözlemin pratik karşılığı, tahmin yöntemimi değiştirmesi oldu.

1. Satır değil, bilinmeyen kural sayın. “Kaç satır kod” bir brownfield işinin büyüklüğünü ölçmez. Ölçen soru şu: kaç tane, gerekçesi bilinmeyen davranış var? Sayı belli değilse tahmin de belli değildir.
2. İlk yarım günü keşfe ayırın, tahmini ondan sonra verin. Keşif çıktısı bir kural envanteri olur: her satırda davranış, nerede yazılı, kim doğrulayacak. Tahmini bu envanterin uzunluğu belirler.
3. Doğrulamaya en az üretim kadar bütçe ayırın. Pratikte oran genelde 1:1,5 civarında çıkıyor. Bu bütçeyi ayırmayan plan, farkı production’da öder.
4. Geçişi ayrı bir kalem yazın. Kod bittiğinde iş bitmiyor; geçiş, izleme ve ilk gün düzeltmeleri takvimin görünür bir parçası olmalı. Hangi işte hangi metodolojiyi seçtiğimi anlatırken de aynı yere gelmiştim: belirsizliği yüksek işte plan, adım sayısını değil, öğrenme sırasını kurar.

Ne çıkarıyorum

Greenfield hızını brownfield tahminine taşımayın. “Agent’la üç günde bitirdik” cümlesi, mevcut bir sistemdeki iş için bir ölçü değil. İki işin darboğazı farklı yerde: birinde üretim, diğerinde doğrulama.

“AI ile iki günde bitmez mi?” sorusunun dürüst cevabı: kod yazımı zaten iki gün değil, bir gün. Ama işin adı kod yazmak değil; yıllarca birikmiş davranışı bozmadan yerini değiştirmek. Hızlanan kısım işin beşte biri, kalanı hâlâ insan işi.

Son olarak tersinden bir not: bugün agent’la üç günde çıkardığımız sistemler, birkaç yıl sonra birinin bir hafta uğraşacağı sistemler olacak. Bu yüzden o hızlı işte de kuralı kodun ortasına gömmemeye, en azından gerekçesini commit mesajına ve teste yazmaya çalışıyorum. Yarının brownfield’ini bugün üretiyoruz.

Kod yazmak hızlandı. Yılların ne anlama geldiğini anlamak hızlanmadı.