Açıkçası biraz izleyip daha sonra devam ederim diye baktım ama...

Açıkçası biraz izleyip daha sonra devam ederim diye baktım ama içerik o kadar akıcı ve faydalı ki bırakamadım. İkilinin eline sağlık.

Detayları bu paylaşımın devamında aktaracağım.

Artık terminal korkusu, framework seçimi ya da "ben teknik değilim" bariyerleri eskisi kadar sert değil. Çünkü agent'lar yalnızca kod yazmanın ötesine geçti. Plan çıkarıyorlar, dosyaları düzenliyorlar, görev listelerini takip ediyorlar, test yazıyorlar, hatayı bulup geri dönüyorlar vb.

Burada bir "fakat" diyeceğiz. Fakat tam da bu yüzden yeni bir problem doğdu. Hızın büyüsü çoğu insanı yanlış bir yere sürüklüyor. Birkaç prompt ile bir şeyler ayağa kalkıyor sonra aynı hızla dağılıyor. Ortaya çıkan ürün çalışıyor gibi dursa da genellikle olması gerektiği gibi değil. Kullanıcılar bunu bazen modelin yetersizliği sanıyor. Oysa temel iddia şu: Bugün kötü sonuç alıyorsan büyük ihtimalle model kötü değil; senin girdin kötü!

Konuğun anlattığı şey tam olarak bu işte. Claude Code'u ustaca kullanmanın sırrı daha iyi prompt yazmak değil; daha iyi plan yapmak, daha doğru feature'lara bölmek, her adımı test ile güvenceye almak ve ürünün hissini düşünmek.

Konuğun ilk vurgusu şu: Modeller artık fena değil seviyesinden çıktı; çoğu işte şaşırtıcı derecede iyi üretim yapıyor. Dolayısıyla bugün kötü sonuçlar için en yaygın sebep ne dersiniz? Kullanıcı, modele bulanık ve eksik bir tarif veriyor.

Bir insan mühendise "bana bir uygulama yap" dediğinde mühendis de sorular sorar. "Kim kullanacak? Hangi akış? Hangi ekran? Hangi öncelik?" Eğer bunlar cevaplanmazsa insan mühendis varsayar. Yapay zeka ajanı da aynısını yapar bir fark ile... Ajan varsaydığında bunu çok hızlı yapar, çok fazla şey üretir ve sen daha sonra o varsayımlar yüzünden büyük revizyonlara girersin. İşte tokenların yandığı, moralin düştüğü yer burasıdır.

Bu yüzden ürün hayali mühendislikte uygulanabilir parçalara dönüştürerek başlar. PLAN, FEATURE LİSTESİ, KARARLAR, TRADE-OFF'lar, TESTler.

Verdikleri örnek üzerinden anlatıyorum. İnsanlar çoğu zaman Claude Code'a şunu söyler: "TikTok için UGC üreten bir app istiyorum." Bu, kulağa net gelse de agent açısından net değildir. Çünkü UGC üreten app bir isimdir; agent'ın ihtiyaç duyduğu şey ise fiildir.

Ne yapacak? Nasıl yapacak? Nerede gösterecek? Hangi sırayla? Hangi kullanıcı için? Hangi çıktı formatıyla?

Bu noktada çok iyi bir benzetme kullanılıyor. Eğer agent'a "bana bir araba yap" dersen araba kelimesi bir konsepttir. Ama arabanın gerçekliği direksiyon, fren, tekerlek, şasi, gösterge paneli, güvenlik sistemi gibi parçaların birleşimidir. Yazılım da böyledir. Bir ürün feature'ların toplamıdır.

Bu yüzden ürün tasarımının ilk kuralı şudur: Ürünü ne olduğunu anlatarak değil, hangi özelliklerden oluştuğunu sayarak tarif et.

Bu yaklaşım yalnızca netlik sağlamaz. Bu yaklaşım geliştirme sürecini de doğal bir sıraya sokar. Çünkü feature'lar yapılacak işler listesine dönüşür. Agent artık bir hayali yorumlamaz; tek tek işleri bitirir.

Agent'larla üretimde en büyük yanılsama şudur: Bir şey inşa edildiğinde tamamlandı sanılır. Oysa yazılımın gerçek dünyada tamam olması yalnızca görünmesiyle değil doğrulanmasıyla mümkündür.

Konuk burada modern yazılım disiplinini agent iş akışının merkezine koyuyor. Feature 1'i yap. Testini yaz. Test geçiyorsa Feature 2'ye geç. Test geçmiyorsa geri dön, düzelt.

Bu mantık basit ama öldürücüdür. Çünkü agent hızla üretir fakat hız, kaliteyi otomatik getirmez. Test ise kaliteyi zorunlu kılar. Böylece iki şey kazanırsın: i) Hatalı feature üstüne bina kurmazsın (sonradan çökmez), ii) Agent'ın yaptığı iş kanıtlanmış olur (güvenilirleşir).

Videonun bir yerinde konuk, Ralph loop'ların (otonom otomasyon döngülerinin) asıl gücünün burada ortaya çıktığını söylüyor. Test yoksa otonomi risk; test varsa otonomi üretim bandıdır.

Claude Code'un plan mode'u var. Bir PRD yazdırırsın, birkaç soru sorar, sonra "başlayalım" der. Bu çoğu kişi için yeterli gibi görünür. Fakat konuğa göre bu genel planlar ürünün kaderini agent'a bıraktığı için tehlikelidir.

Çünkü plan mode genellikle şu problemi üretir: Plan kısa, genel ve varsayımlarla doludur. Agent da o varsayımları en makul şekilde tamamlar. Ama en makul olan senin istediğin olmayabilir. Bu noktada konuğun önerdiği çözüm Claude Code'daki özel bir yaklaşımı kullanmak. "Ask User Questions Tool".

Bu araç, agent'ın seni adeta bir müşteri gibi sorgulamasını sağlar. Yani sen "UGC app yap" dediğinde agent şunu sormaya başlar:
İş akışı nasıl olmalı? Lineer mi iteratif mi?
Ekran yapısı nasıl? Dashboard mu chat-first mü creative tool mu?
Script üretimi hangi modelle?
Üretim batch mi olacak tek tek mi?
Video depolama nasıl? İndirilebilir mi cloud mu?
API maliyeti ve kullanım bütçesi nasıl sınırlandırılacak?
Hosting yaklaşımı ne?
Kullanıcılar kampanya mı yönetiyor müşteri mi yönetiyor?
Avatar/voice seçenekleri basic mi custom mı?

Bu sorular ilk bakışta yorucudur. Zaten konuk bunun bilerek sinir bozucu olduğunu söylüyor. Çünkü amaç ürünün bulanık noktalarını zorla açığa çıkarmaktır. Plan ancak bir noktadan sonra eğlenceli olmaktan çıkar ve ciddi hale gelir. İşte o noktada plan gerçek plan olur.

Bunun güzelliği teknik değilsen bile sorun olmamasındadır. Konuğun pratik yöntemi şu: Soruyu kopyala, ChatGPT/Claude'a sor, cevabı al, interview ekranına dön-doldur, devam et. Böylece agent yalnızca kod yazan değil; seninle birlikte ürün kararlarını netleştiren bir partner olur.

Konuğun konuşmasındaki en kritik işaretlerden biri şu: Agent'a küçük bir detayı söylemediğinde agent boş bırakmaz; tamamlar. Ve tamamladığında senin zihnindeki tasarımla çakışma ihtimali yükselir.

Örneğin;

Bu özellik modal mı olmalı ayrı sayfa mı?
Bu akış kullanıcıyı adım adım mı taşımalı yoksa serbest mi bırakmalı?
İçerik listesi düz mü olmalı yoksa kampanya/müşteri hiyerarşisi mi?
UI minimal mi olmalı dashboard heavy mi?
Üretim ekranı chat gibi mi olmalı form gibi mi?

Bunlar küçük detaylar gibi görünür. Oysa ürünün hissi (ve kullanıcı davranışı) bu detaylarda şekillenir. Sen net söylemezsen agent seçer. Sonra ürün bittiğinde "bu benim istediğim değil" dersin. İşte orada geri sararsın. Bu da gereksiz token maliyeti ve gereksiz zaman demektir.

Net sonuç: Plan aşamasında ekstra zaman harcarsan build aşamasında kat kat tasarruf edersin.

Ralph loop'lar bugün çok konuşuluyor. Agent'ı bir görev listesiyle baş başa bırakmak, sen yokken ürünü tamamlatmak... kulağa büyü gibi geliyor. Ama konuk özellikle yeni başlayanlar için bunu önermiyor. Benzetmesi çok net: Araba kullanmayı bilmeden Tesla'nın self-driving'ine güvenmek gibi.

Önce tek tek feature geliştirme pratiği yapmalısın. Çünkü bu süreç doğru soruyu sormayı, riskli yerleri sezebilmeyi, QA bakışı geliştirmeyi, ürün kararlarının sonuçlarını görmeyi öğretir. Yani agent ile çalışmanın kasları oluşur. Bu kas olmadan Ralph'a geçmek çoğu zaman kontrolü kaybetmek demektir. Agent hızlıca bir sürü iş yapar ama sen neyin nasıl yapıldığını kavrayamazsın. Sonuç? Çalışıyor gibi bir şey ama içi karışık, yönü belirsiz bir ürün.

Konuk burada bir eşik koyuyor. Eğer daha önce gerçekten bir şey deploy etmediysen, tıklanabilir bir URL yoksa, tam otomasyona atlamak yerine önce temel akışı öğren.

Ralph loop basit bir fikir. PRD'de görev listesi var; agent ilkini yapıyor, progress dosyasına yazıyor, ikinciye geçiyor... Böyle devam ediyor.

Bu döngünün güçlü olmasının sebebi modellerin artık daha güvenilir olması. Ama konuk aynı noktaya tekrar tekrar dönüyor. Plan kötü ise Ralph, kötü planı çok hızlı uygular. Yani hız, hatayı büyütür.

Bu yüzden Ralph'ı mucize değil, çarpan olarak düşünmek gerekir. İyi planı büyütür, kötü planı da büyütür. Ralph kullanırken yapılması gereken şey bir üretim bandı kurmaktır: PRD, progress.txt, her feature sonrası test, lint/format kontrolü, test fail ise geri dön. Bu sayede agent otonom yazar değil, kalite kapılarından geçen bir işçi gibi çalışır.

Agent dünyası yeni olduğu için çevresinde bir ekosistem romantizmi var. Herkes MCP'lerden, skills'lerden, plugin'lerden, prompt. md / agent. md dosyalarından, convention'lardan bahsediyor. Konuk bunları küçümsemiyor ama şunu söylüyor: Çoğu insan ürününün kötü olmasının sebebini burada arıyor. Oysa çoğu zaman sorun çok daha basit.

Plan yetersiz, feature'lar net değil, UI/UX kararları verilmemiş, test yok, progress izlenmiyor. Dolayısıyla araçlara takılmak yerine temele dönmek gerekiyor. Çünkü sağlam plan ve sağlam feature yaklaşımı olmadan en iyi plugin bile seni kurtarmaz.

Konuğun pratik bir uyarısı daha var.

Agent oturumları büyüdükçe, context şiştikçe, modeller ilk baştaki netliklerini kaybedebiliyor. Claude Code ve benzeri araçlar genelde context kullanımını gösteriyor. Kişisel kuralı şu: Context %40-50'ye yaklaştığında yeni session aç.

Bunu bir sınıf benzetmesiyle anlatıyor. Ne kadar iyi anlatılırsa anlatılsın bir noktadan sonra bilgi yığılması kalite düşüşü olarak geri döner. Modelin deteriorate etmesi çoğu kişinin sandığı gibi modelin bozulması değil; senin ona aşırı yüklemenle ilgili olabilir.

Videonun finalinde konuşma teknik olmaktan çıkıyor artık ve ürün felsefesine bağlanıyor. Konuğun "audacity" dediği şey bugün asıl ayrıştırıcı faktör haline geliyor. Çünkü artık herkes bir şeyleri klonlayabilir. Bir chat arayüzü, bir dashboard, bir CRUD paneli... bunlar 2026'da farklılık yaratmıyor.

Duygularına göre koşu rotası üreten bir app örneğini konuşuyorlar. "Stressed" seçiyorsun, app rotayı ona göre kurguluyor. Renkler, animasyonlar, his... Bu ürün özellik olarak kopyalanabilir ama hissettirdiklerini kopyalamak zordur. Çünkü orada zevk, tasarım dili, akış, detay ve kullanıcı psikolojisi devreye girer.

İşte konuğun dediği "software development kolaylaştı, software engineering zor" cümlesi burada anlam kazanıyor. Kod üretmek kolaylaşırken, kullanılacak ve sevilecek ürün yapmak hala zordur. Ve kazananlar agent'ı yalnızca kod yazdıran bir araç olarak değil, kendi ürün zekalarını büyüten bir ortak olarak kullananlar olacak.

Konuğun tips & tricks listesini bırakarak tamamlayalım.

1) Planlama yaparken AskUserQuestionTool kullan.
2) MCP / skills / plugin gibi şeylere gereğinden fazla takılma.
3) Ralph'ı önce manuel şekilde bir şeyler inşa ettikten sonra kullan.
4) Context yönetimi kritik. %50'yi geçince yeni session aç.
5) Audacity. Sıradan klonlar değil, "scroll-stopping" ürünler kazanır.