Bir önceki yazımda yapay zeka ile çalışmanın matematiğini kurmuştum. Sinyal, gürültü, filtreleme, kapı sistemi. Ama o yazıda bir katmanı atlamışım.
“Uygulamaya geçmeden önce planla” demiştim. Doğru. Ama eksik. Çünkü planlamanın kendisi de bir gürültü kaynağı.
Bir geliştiricinin günlük gerçekliğini düşünün. IDE’sini açıyor, yapay zekaya “şu özelliği planla” diyor. Model bir plan üretiyor — adımlar var, sıralama var, hatta bağımlılıklar bile belirtilmiş. Güzel görünüyor. Geliştirici “tamam, uygula” diyor.
Üçüncü adımda plan çöküyor. Çünkü model planı yaparken bir varsayımı yanlış almış — veritabanı şemasını bilmiyordu, mevcut bir servisin kısıtlarından habersizdi, ya da edge case’leri hesaba katmamıştı. Şimdi geliştirici üç adım geri gidip planı düzeltecek, sonra o üç adımın çıktılarını da düzeltecek. Token yandı, zaman yandı, motivasyon yandı.
Sorun planın kötü olması değil. Sorun plana gürültülü girdilerle başlanması.
Eksik Katman
Önceki yazımdaki denklemi hatırlayın: C(t+1) = f(Katkı(1), Katkı(2), …, Katkı(t))
Bunu uygulama zinciri için kurmuştum. Ama aynı denklem planlama zinciri için de geçerli. Plan modunun ilk adımındaki gürültü, planın her sonraki adımına sızıyor. Gürültülü plan üzerinde çalışan agent ise o gürültüyü koda dönüştürüyor. Gürültü iki kez çarpılıyor: bir kez planlama zincirinde, bir kez uygulama zincirinde.
Yani N(t)’yi sadece uygulama zincirinin başında değil, planlama zincirinin başında da düşürmen gerekiyor.
İşte Ask mod tam burada devreye giriyor.
Ask Mod: Planı Planlamak
Modern geliştirici araçlarında — Claude Code, Cursor, Copilot — genellikle üç mod var: Ask, Plan, Agent (ya da Code). Çoğu geliştirici ya direkt Agent moda atlıyor ya da en iyi ihtimalle Plan moddan başlıyor. Ask modu atlıyor.
Ask mod kod yazmaz, dosya değiştirmez, plan bile çıkarmaz. Sadece konuşur. Ve bu “sadece konuşma” aşaması, planın temelini temizlediğin yerdir.
Ask modda yaptığın şey önceki yazımdaki “geniş alanda mutabakat” aşamasının ta kendisi — ama bu sefer planlama için:
Mevcut codebase’in hangi kısıtlarını modelin bilmesi gerekiyor? Hangi servisler, hangi şemalar, hangi API kontratları var? Bu özellik mevcut mimaride nereye oturuyor? Hangi edge case’ler var? Hangi yaklaşımlar denenip elenmiş?
Bu soruları Ask modda çözdüğünde, Plan moduna verdiğin bağlam temiz oluyor. Model artık “genel olarak böyle yapılır” yerine “senin projenin kısıtları içinde böyle yapılmalı” diyor.
Üç Katmanlı Pipeline
Ask → Plan → Agent. Her katman bir sonrakinin girdisini temizliyor.
Ask modda problemi ve bağlamı netleştiriyorsun. Modelin bilmediği ama bilmesi gereken şeyleri söylüyorsun. Bilinmeyen bilinmeyenleri keşfediyorsun — model sana “şu konuyu düşündün mü” diyebiliyor çünkü senin düşünce çerçevenin dışından bakabiliyor.
Plan modda artık temiz bir zemin üzerinde adımları çıkarıyorsun. Her adımı inceliyorsun, onaylıyorsun ya da düzeltiyorsun. Önceki yazıdaki kapı sistemi burada çalışıyor.
Agent mod da dar bir alanda, tanımlı adımlarla, doğrulanmış bir plan üzerinde çalışıyor. Kısır döngüye girme ihtimali düşük çünkü ne yapacağı net.
Maliyet Denklemi
Agent moda direkt girdiğinde model geniş bir olasılık uzayında hareket ediyor. Yanlış yol deniyor, geri dönüyor, alternatif deniyor, bazen döngüye giriyor. Her deneme token. Her geri dönüş daha fazla token. Her döngü çok daha fazla token.
Ask modda 5-10 mesaj harcıyorsun — düşük token maliyeti, çünkü kısa cevaplar, kod yok. Plan modda 3-5 mesaj — orta maliyet, plan metni. Ama Agent moda girdiğinde model doğru yolda ilerliyor, gereksiz denemeler yok, geri dönüş yok. Toplam token harcaması düşüyor. Daha önemlisi, zaman harcaması düşüyor. Daha da önemlisi, “her şeyi sil baştan yap” anı gelmiyor.
Somut Bir Örnek
Diyelim ki bir ödeme sistemi entegrasyonu yapacaksın.
Direkt agent moda girsen: Model genel bir ödeme entegrasyonu kodu üretir. Senin kullandığın gateway’i bilmez, mevcut error handling yapını bilmez, retry politikasını bilmez. Çalışır gibi görünen ama üretimde patlayacak bir şey çıkar.
Ask modda başlasan: Önce mevcut repo’nu modele okutuyorsun — “make functional analysis” diyorsun, model codebase’ini tarıyor, servis katmanını, hata yönetimi pattern’lerini, mevcut entegrasyonların yapısını çıkarıyor. Sonra Iyzico’nun API dokümanını okutuyorsun. Artık model iki tarafı da biliyor: senin kodunun gerçekliğini ve Iyzico’nun beklentilerini.
Şimdi gerçek bir tartışma başlıyor. “Iyzico entegrasyonu yapacağım, 3D Secure akışı var, idempotency key zorunlu” diyorsun. Model senin codebase’ini okuduğu için genel tavsiye vermiyor, somut konuşuyor: “Mevcut PaymentService’inde strategy pattern kullanmışsın, Iyzico’yu da aynı yapıya oturtmalıyız. Ama mevcut error handler’ın Iyzico’nun döndüğü hata kodlarını karşılamıyor, burayı genişletmemiz lazım.” Dokümanı da okuduğu için Iyzico tarafını da biliyor: “Webhook doğrulamasında Iyzico HMAC imza kontrolü istiyor, mevcut middleware’inde bu yok, eklememiz gerekecek. Partial refund için iki farklı endpoint var, hangisini kullanacağız?”
Burada üç şey oluyor. Bilmediğini buluyorsun — webhook imza doğrulamasını düşünmemiştin, model dokümanla senin kodunu karşılaştırdığı için eksikliği gördü. Bildiklerini doğruluyorsun — retry politikanı anlatıyorsun, model Iyzico’nun rate limit’iyle çapraz kontrol yapıp uyumsuzluk varsa söylüyor. Ve en kritik olanı: mevcut mimarin ile yeni entegrasyonun çarpışacağı noktaları önceden görüyorsun — model senin kodunu bildiği için “bu yapıya bu şekilde eklersen şurada sorun çıkar” diyebiliyor. Bu sorunları agent modda kod yazarken değil, ask modda konuşurken keşfetmek, maliyeti onlarca kat düşürüyor.
Plan moduna geçtiğinde artık üç katmanlı bir zemin var: senin alan bilgin, dokümanın gerçekleri ve mevcut codebase’in kısıtları. Plan havada değil, projenin somut gerçekliği üzerinde kuruluyor. Agent mod bu planı uyguladığında mevcut koda uyumsuz kod üretme ihtimali minimuma iniyor — çünkü model zaten mimariyi biliyor, dokümanı biliyor, kısıtları biliyor.
Önceki Yazıdan Bu Yazıya
Önceki yazıda denklemin kontrol edilebilir tarafının biz olduğunu söyledim. Bu yazıda o kontrolün bir katman daha geriye gittiğini söylüyorum. Planı filtrelemek yetmez; planın girdisini de filtrelemen gerekir.
Ask mod o filtredir. Planlamayı planladığın, bağlamı temizlediğin, modelin olasılık uzayını uygulamaya geçmeden çok önce daralttığın yer.
Denklemdeki ilk sinyal sadece uygulamanın başında değil — planlamanın başında veriliyor. Ve o sinyalin kalitesi, tüm zinciri belirliyor.
