Bunu kimse istemedi
Fikir ile uygulama arasındaki kopukluğa çokça denk geldim. Temsili bir örnekle anlatayım.
Bir diş kliniği, tanıdık üzerinden bulduğu bir freelance developer’dan “online randevu sistemi” istiyor. Developer takvimi, hasta kaydını ve bir yönetim panelini yapıyor. Teslimde klinik “biz bunu istemedik” diyor. Asıl dert aslında randevuya gelmeyen hastaları tespit etmekmiş, yani gün içinde boş koltuk kalmamasını sağlamak, bir gün öncesinde bir hatırlatma mesajı gönderilse asıl problemi büyük ölçüde çözerdi.
Ürün geliştiren bir şirkette de, yine temsili bir örnekle, aynı kopukluk başka bir kılıkta geliyor. Satış ekibi “Excel’e aktar” butonu istiyor, ekip her tabloya filtreli bir export yapıyor. Satışın istediği ise her pazartesi kullanımı düşen müşterilerin listesiydi, kimi arayacaklarını bilmek için.
Kimse yanıltıcı bir şey söylemedi aslında, ama anlam yolda kayboldu.
Neden sonda patlıyor
Yanlış anlaşılma başta oluyor ama ancak sonda görünüyor, o yüzden faturayı zincirdeki son kişi ödüyor. Sözleşme olsa bile çoğu zaman istenen cümleyi yazıyor, arkasındaki ihtiyacı değil.
- 1 · Klinik “Online randevu sistemi lazım.” “Hastalar gelmiyor, koltuklar boş kalıyor.” Gelmeyen hastayı bugün nasıl fark ediyorsun?
- 2 · Developer Takvim, hasta kaydı, yönetim paneli Örnek: yarın randevusu olan herkese bugün 18:00’de mesaj
- 3 · Agent 12 ekran, 48 test, lint yeşil Örnek teste dönüştü, test geçiyor
- 4 · Teslim “Biz bunu istemedik.” “Evet, tam bu.”
Fred Brooks bunu 1986’da görmüş. Hiçbir tek aracın yazılımı on kat kolaylaştırmayacağını anlattığı No Silver Bullet yazısında, bir yazılım sisteminin en zor kısmının tam olarak neyin yapılacağına karar vermek olduğunu söylüyor. Bir paragraf sonra da şunu ekliyor: müşteriler çoğu zaman hangi soruların cevaplanması gerektiğini bilmiyor.
Yani birinin o soruları sorması lazım. Çoğumuz soruyoruz da, sadece geç, tasarım review’unda ya da teslimde.
Doğru zaman, doğru yer, doğru soru
Doğru zaman, kimse bir çözümden bahsetmeden önce. “Randevu sistemi” masaya bir kere geldi mi, bütün sorular onun etrafında dönmeye başlıyor.
Doğru yer, işi yapan kişinin masası. Klinikte sekreter bugün randevuları nasıl tutuyor, gelmeyen hastayı nasıl fark ediyor, elindeki neyse onunla, gidip izlemek.
Sorular da sade:
- Bu ekranı açınca hangi kararı vereceksin?
- O kararı bugün nasıl veriyorsun?
- Geçen haftadan gerçek bir örnek gösterebilir misin?
Karar noktalarında, işi yaparken çıkacak sorular bir yana, bir cümleye bağlı kalmaya çalışarak ilerliyorum:
you can outsource your thinking4 Şubat 2026 · X'te gör ↗
but you cannot outsource your understanding
Karpathy nisanda Sequoia’daki bir konuşmasında bu sözün aklından çıkmadığını anlattı, konuşmanın videosu çıktıktan bir gün sonra da tweet’i alıntılayıp son zamanlarda sık sık andığı söz olduğunu yazdı. Konuşmada bir de şunu ekliyor: LLM’ler anlamakta pek iyi değil, o hâlâ yalnızca senin sorumluluğunda. Düşünmeyi bir agent’a devredebilirsin, ama anlamayı devredemiyorsun. Takvimi bir agent birkaç saatte yazar. Kliniğin derdinin boş koltuklar olduğunu anlamak ise başka bir şey.
Sonra cevapları, isteyen tarafın onayladığı birkaç somut örneğe çevirmek lazım. Mesela “yarın randevusu olan her hastaya bugün 18:00’de bir mesaj gidiyor” (temsili bir örnek). Örnekler de teste dönüşüyor. Tartışma “kim ne dedi”den çıkıp “örnek geçiyor mu”ya dönüyor.
Eskiden işin, developer’dan gelecek teknik sorularla sınırlı kalmasına çaba harcardık. Ama devir değişti: feature’ı tasarlayan ve geliştiren kişi yavaş yavaş aynı kişi oluyor. Bu ayrıma hâlâ ihtiyaç var mı bilmiyorum, developer artık ayrı bir rol değil gibi. O zaman soruyu sormak da cevabı anlamak da aynı kişiye kalıyor.
Son el bir döngü olunca
Kodu yazan el de artık giderek daha sık bir agent. Önce ne istediğini anlatıp modelin yazdığı vibe coding geldi, sonra agent’ların yazıp review ettiği, bir insanın da yön verdiği düzen. Şimdi de bir hedef verip saatlerce arada kimse olmadan dönen döngülerden söz ediyoruz.
Bildiğim en temiz örnek Karpathy’nin autoresearch reposu. Fikri kendi cümlesiyle: bir agent’a küçük ama gerçek bir LLM eğitim düzeneği ver ve gece boyunca kendi kendine deney yapmasına izin ver. Agent eğitim kodunu değiştiriyor, beş dakika eğitiyor, tek bir metrik iyileşti mi diye bakıyor, değişikliği tutuyor ya da atıyor ve baştan başlıyor.1 Metrik val_bpb, yani validation bits per byte; ne kadar düşükse o kadar iyi. İnsan tek bir dosyayı, agent’a araştırmayı nasıl yürüteceğini anlatan program.md’yi düzenliyor; agent da train.py’yi. Sabah uyandığında önünde bir deney günlüğü ve, umarız, daha iyi bir model buluyorsun.
Bu işe yarıyor çünkü görev doğrulanabilir. Karpathy bunu Verifiability adlı kısa bir yazıda anlatıyor: bir işin bu şekilde otomatikleşmesi için ortamın sıfırlanabilir, çok sayıda denenebilir ve ödüllendirilebilir olması lazım, yani her denemeyi otomatik olarak puanlayan bir süreç olmalı. Bunu iki satırda özetliyor: Software 1.0 tarif edebildiğini kolayca otomatikleştiriyor, Software 2.0 doğrulayabildiğini.
Şimdi kliniğin randevu sistemini bu döngüye koy. Testler geçiyor, takvim her randevuyu gösteriyor, lint yeşil. Ama koltukların boş kalıp kalmadığı bir gecede ölçülmüyor; cevabı haftalar sonra, klinikte.
Hiç yorulmayan bir döngü kendisine sorulan sorunun peşinden gidiyor. Soru yanlışsa yanlış cevabı da aynı sabırla büyütüyor.
Anlamadığım bir yeri vibe code ettiğimde, çok insanın işine yarayacak bir ürün çıkarmak bence ziyadesiyle zor.
Soruyu agent sorabilir mi?
Kısmen. Bu yazı küçük bir örnek. Hazırlarken bir agent bana her seferinde tek bir soru sordu, çünkü birinin yazdığı bir skill dosyası ona önce sor, sonra yap diyordu. Fikrimi değiştiren bir nokta olmadı ama fikrimi pişirdi ve olgunlaştırdı. Cevapları ise, yani ne gördüğümü ve beni neyin rahatsız ettiğini, hiçbir yerde bulamazdı; benden gelmeleri gerekiyordu.
Yani agent doğru soruları sorabiliyor, yeter ki ona nasıl sorulacağını gösterelim. Biri yaşanan derdi onun bağlamına taşımadıkça kliniğe gidip sekretere doğru soruyu soramıyor şimdilik :)
İş nereye gidiyor
Karpathy’nin MenuGen hikâyesi burada güzel bir örnek. Restoranda menüdeki yemeklerin ne olduğunu bilemeyip sık sık takıldığı için, menünün fotoğrafını çekince her yemeğin bir resmini gösteren bir uygulama yazmış, kodunun tek satırını kendisi yazmadan: MenuGen. Aynı konuşmada devamını anlattı. Sonradan fotoğrafı Gemini’a verip Nano Banana’dan yemekleri menünün üstüne çizmesini istemek yetmiş; model menünün aynı fotoğrafını, yemeklerin resimleriyle birlikte geri vermiş. Kendi lafıyla bütün MenuGen gereksizmiş, o uygulamanın hiç var olmaması gerekiyormuş.
Aynı konuşmada LLM’i yeni bir bilgisayar gibi anlatıyor. Bugün sinir ağları bildiğimiz bilgisayarların üstünde sanal olarak çalışıyor; bir gün bunun tersine dönüp sinir ağının asıl süreç, CPU’nun da yardımcı işlemci olabileceğini söylüyor. MenuGen’den devam ederek, bu kodun çoğunun aslında var olmaması gerektiğini, işin çoğunu sinir ağlarının yaptığını ekliyor.
Uygulama gitti ama ihtiyaç duruyor: menüdeki yemeğin neye benzediğini görmek. Kliniğin derdi de randevu sistemi değil, boş koltuklardı.
Yaptığımız şey değişebiliyor, MenuGen gibi bir gün hiç gerekmeyebiliyor bile; değişmeyen, neye ihtiyaç olduğunu anlamak.
Kod yazmak basitleştikçe ondan önceki kısım daha değerli hale geliyor: doğru zamanda doğru yerde sormak ve cevabı bir döngünün kontrol edebileceği bir şeye çevirmek.
Kart
İş başlamadan, ister bir insan ister bir agent doldursun, beş satırlık bir checklist. Aşağıdakini kliniğin isteğiyle doldurdum; bir satıra dokunup cevabını söyleyebilirsin.
Dördüncü satır bir agent’a verebileceğin çok iyi bir talimat aslında: “bir randevu sistemi yap” isteğini doğrulayabileceği bir şeye çeviriyor.
Kliniğe dönersek, takvim çalışıyordu ve kimse onu istememişti. Senin agent’ın sana, sen onu yönlendirmeden, en son ne zaman “bunu kim, ne için kullanacak?” diye sordu?