AI ile Kod Yazarken Kontrolü Nasıl Kaybetmeyiz?

AI hızlandırsın, kararı sen ver. Hedefi bölmek, önce plan istemek, her çıktıyı kanıtlamak, yetki sınırı koymak ve proje hafızasını .md dosyasında tutmak — beş kontrol noktası ve bu sitede nasıl uygulandıkları.

AI ile kod yazmak hızlı. Kontrolü kaybetmek de aynı hızda oluyor ve genelde tek bir anda olmuyor: küçük kabullerle birikiyor. "Şunu da halletsin", "nasıl yaptığına bakmadım ama çalışıyor", "hangi dosyalara dokunduğunu sonra kontrol ederim". Bir hafta sonra elinde çalışan ama neden öyle çalıştığını kimsenin bilmediği bir kod tabanı oluyor.

Bu yazıda beş kontrol noktası var. Hiçbiri AI'yı yavaşlatmak için değil; kararın sende kalması için. Temel fikir tek cümle: AI hızlandırsın, kararı sen ver.

Beşini de bu sitede uyguluyorum, o yüzden her başlığın altında teoriyi değil ne yaptığımı yazdım.

1 — İşi AI'ya değil, hedefe böl

En yaygın hata tek dev prompt: "şu özelliği ekle". Model bir şeyler üretir, çalışır bile, ama neyi neden yaptığını sen de o da net söyleyemez. Kontrol tam burada bulanıklaşıyor — çünkü bitti sayılacak nokta hiç tanımlanmadı.

İşi üç soruya böl:

• Hedef — ne olacak? Bir cümle.
• Kapsam — neye dokunulacak, neye dokunulmayacak?
• Kabul kriteri — hangi şart sağlanınca "bitti" diyeceğiz?

Kabul kriteri olmayan iş bitmez, sadece bir yerde bırakılır. "Testler geçiyor ve ana sayfa 200 dönüyor" bir kriterdir. "Düzgün çalışıyor" değildir.

Bu projede: her iş paketi hedef, kapsam ve yapılmayacaklar listesiyle başlıyor. Yapılmayacaklar kısmı en çok işe yarayan kısım: "veritabanı şemasına dokunulmayacak", "mevcut tasarıma dokunulmayacak" gibi satırlar, iyi niyetli ama istenmeyen değişiklikleri baştan kesiyor.

2 — Önce plan, sonra kod

Kod yazmadan önce AI'nın şunu söylemesini isteyin: hangi dosyalara dokunacak, neden, ne riski var, nasıl doğrulanacak. Bu üç dakika, sonradan saatlerce süren geri alma işini engelliyor.

Planın dört satırı yeter:

1. Kapsam — bu adımda ne yapılıyor
2. Dokunulacak dosyalar — isim isim
3. Riskler — ne bozulabilir
4. Kabul ölçütü — nasıl doğrulanacak

Plan aynı zamanda bir erken uyarı sistemi. Dosya listesi beklediğinizden uzunsa, iş sizin sandığınızdan büyük. O anda küçültebilirsiniz — kod yazıldıktan sonra küçültmek çok daha pahalı.

Bu projede: büyük değişiklikler küçük, geri alınabilir adımlara bölünüyor. Her adım kendi başına çalışır durumda bırakılıyor, böylece bir adım yanlış çıkarsa öncesine dönmek tek komut. Yarım kalmış bir dönüşümün üstüne ikinci dönüşüm bindirilmiyor.

3 — Her çıktıyı kanıtla

Bu, listedeki en önemli madde. "Çalışıyor" demek kanıt değildir — ne AI söylediğinde, ne siz söylediğinizde.

Dört tür kanıt var ve dördü farklı soruya cevap verir:

• Test — geçti mi? Sayıyla.
• Kod farkı (diff) — kodun eski hâli ile yeni hâli arasındaki fark. Beklemediğiniz bir dosya listede varsa orada durun.
• Log — çalışırken ne oldu, hata düştü mü?
• Ekran — sonuç gerçekten nasıl görünüyor?

Son madde küçük duruyor ama en çok yakalayan o. Görsel bir işi kod okuyarak doğrulamak mümkün değil; sayfayı açıp bakmak gerekiyor.

Bu projede iki örnek:

Yedek klasöründe iki dosya vardı: biri 121 KB, diğeri 20 bayt. İkisi de .sql.gz, ikisi de yerinde. 20 bayt boş bir gzip dosyasının büyüklüğü — yedekleme başarısız olmamış, bir dosya bırakmış. Boyuta bakmayan bir kontrol bunu aylarca fark etmezdi. "Yedek alınıyor" bir varsayımdı; boyutu okumak kanıt oldu.

İkincisi: bir sosyal medya gönderimi zaman aşımına düştü ve yanıt okunamadı. Sistem "başarısız" varsayıp tekrar denemedi — çünkü tekrar denemek ikinci bir gerçek gönderi oluşturabilirdi. Bunun yerine durumu "belirsiz" işaretledi; salt-okunur bir sorgu gönderinin uzakta gerçekten oluştuğunu gösterdi ve kayıt ancak o zaman doğrulanmış kimlikle kapatıldı. Kanıt beklemek, kör tekrar denemekten daha yavaş ama tek doğru olan.

4 — Yetki sınırı koy

Geri dönüşü zor işlemler insan onayı olmadan çalışmamalı. Liste kısa ve neredeyse her projede aynı:

• Canlı ortam — deploy, servis yeniden başlatma, yapılandırma değişikliği
• Veritabanı — şema değişikliği, veri silen ya da ezen komutlar
• Silme ve ödeme — dosya silme, para hareketi, dışa gönderim

Buradaki kritik ayrım şu: izin bir kez verildiğinde süresiz değildir. Bir işlem için verilen onay, benzeyen bir sonraki işlemi kapsamaz. "Geçen sefer olur demiştin" bir yetki kaynağı değil.

Hız, sınır koyunca azalmaz; güvenilir hâle gelir. Onay beklemek dakikalar alır, yanlış bir silmeyi geri almak günler.

Bu projede: yıkıcı veritabanı komutları hiç çalıştırılmıyor; ortam dosyası elle bile düzenlenmiyor; şema değişikliği yalnız ekleyici olabiliyor. Ve sosyal medya tarafında tek bir kural her şeyin önünde: bir gönderi yalnızca panelde ilgili platformun "Onayla" butonuna basıldığında onaylanmış sayılıyor. Sohbette "tamam paylaş" demek, zamanlama koymak ya da içeriğin hazır olması yayın izni değil. Bu kural kodun içinde: onay kaydı yoksa gönderim reddediliyor, üstelik "hata" olarak değil — böylece sessizce tekrar denenmiyor. Metin, görsel ya da sıra değişirse önceki onay otomatik düşüyor, çünkü onaylanan şey artık gönderilecek şey değil.

5 — Proje hafızasını .md dosyasında tut

Sohbet bağlamı biter. Model penceresi dolar, oturum kapanır, yeni bir konuşma sıfırdan başlar. Projede kalıcı olan tek şey dosyalar.

Markdown (.md) sade metinle kalıcı proje kaydı tutar: sürüm kontrolüne girer, diff'i okunur, hiçbir araca bağımlı değildir. Üç dosya çoğu proje için yeter:

• PROJECT-STATE.md — şimdi neredeyiz? Tamamlananlar ve açık işler.
• DECISIONS.md — neden böyle yaptık? Karar, gerekçe, elenen alternatif.
• NEXT-STEPS.md — sırada ne var? Öncelik, sorumlu, kabul ölçütü.

İkincisi en çok değer üreteni. Kod ne yaptığını söyler; neden öyle yapıldığını söylemez. Altı ay sonra "burası neden böyle" sorusunu soran kişi büyük olasılıkla sizsiniz.

Bu projede: her oturum bu dosyaları okuyarak başlıyor — güncel durum, bağlayıcı kararlar, sonra iş. Yeni bir oturum "biz neredeydik" diye sormuyor, dosyadan okuyor. Kararlar da ayrı tutuluyor ve bir karar değiştiğinde eskisi silinmiyor: neyin neden değiştiği yazılıyor. Bu, geriye dönüp "o zaman bunu neden seçmişiz" sorusuna cevap verebilmenin tek yolu.

Kısa kontrol listesi

Bir sonraki AI kodlama oturumunda beş kelime yeter:

• HEDEF — ne olacak, ne zaman bitti sayılacak?
• PLAN — hangi dosyalar, hangi risk, nasıl doğrulanacak?
• KANIT — test, diff, log, ekran. "Çalışıyor" değil.
• SINIR — canlı, veritabanı, silme: onaysız asla.
• KAYIT — durum, karar ve sıradaki iş dosyada.

AI'nın ne kadar iyi olduğu bu listeyi gereksiz kılmıyor. Tam tersi: model iyileştikçe çıktı daha ikna edici görünüyor, dolayısıyla kanıt istemek daha da önemli hâle geliyor. Kontrolü AI'ya bırakmayın — gücünü yanınızda tutun.