Claude Code'u En İyi Tasarım Ortağına Dönüştürmek
(betweentheprompts.com)- Claude Code ilk kullanılmaya başlandığında yaklaşım basitçe prompt talimatları verip düzeltmeleri yinelemek şeklindeydi; ancak karmaşık işlerde sohbet geçmişine bağımlılık ve bağlam sınırları sorunları yaşandı
- Bunu çözmek için, özellik geliştirmeden önce bir plan belgesi (plan document) yazdırılıyor ve bu belge yeni oturumun tek gerçeklik kaynağı (SSOT) olarak kullanılıyor
- Plan belgesi; gereksinimlerin yeniden ifade edilmesini, uygulama ayrıntılarının açıklanmasını, kod kalitesi kontrol komutlarını vb. içeriyor ve uygulama sırasında da bir yaşayan belge (living document) olarak sürekli güncelleniyor
- Bu sayede bağlam kaybı sorunu çözülüyor ve yeni bir oturumda da yalnızca tek bir belgeyle projeye devam edilebiliyor
- Sonuç olarak yapay zeka, basit bir yürütme aracından ziyade, geliştiriciyi tasarımı daha derin düşünmeye ve kayda geçirmeye yönelten işbirlikçi bir tasarım ortağı rolünü üstleniyor
Sorun farkındalığı: Basit sohbet yaklaşımının sınırları
- Claude Code ile sohbet tabanlı çalışırken, bu yöntem basit işler için uygun olsa da iş karmaşıklaştıkça çeşitli ciddi sınırlamalar ortaya çıkıyor
- Sohbet tek gerçeklik kaynağı haline geliyor; yeni mesajlar önceki talimatların üzerine kolayca yazabiliyor ve bunun tam olarak ne zaman olduğunu fark etmek zor olabiliyor
- Yapay zekanın bağlam boyutu sınırı nedeniyle, sohbet uzadıkça önceki bilgiler kaybolabiliyor
- Claude Code sohbet sıkıştırma özelliğine sahip olsa da bu sınırı tamamen ortadan kaldırmıyor
Plan belgesi merkezli yaklaşım deneyi
- Bu sorunları çözmek için plan belgesi tabanlı bir yaklaşım deneniyor
- Başlangıçta, Claude Code'a geliştirilecek özellik ya da düzeltilecek hata hakkında olabildiğince ayrıntılı açıklama yapılıyor
- Başvurulabilecek mevcut kaynak dosyalarına veya daha önce yazılmış plan belgelerine de atıfta bulunuluyor
- Aşırı derecede spesifik uygulama talimatlarından kaçınılıyor; bunun yerine yapay zekanın tasarım önerisi rolü teşvik ediliyor
- Plan belgesi yeterince tatmin edici olduğunda, sohbet geçmişi temizleniyor ve yalnızca bu plan bağlam olarak kullanılarak yeniden başlanıyor
- Planda özellik özeti, uygulama planı, kod ve sözde kod, type/lint/test komutları vb. yer alıyor
İşbirlikçi tasarım süreci
- Yapay zekanın önerdiği tasarım beğenilmediğinde, somut geri bildirim verilerek gözden geçirilmiş bir yaklaşım yönlendiriliyor
- Tartışma sürecinde bazen yapay zekanın ilk önerisinin daha uygun olduğu fark ediliyor; bu da yalnızca kendi tasarımıyla kod yazmaya kıyasla daha verimli oluyor
- Sistematik diyalog, planı bir ekip arkadaşı geliştiriciyle tartışmaya benzer bir deneyim sunuyor
- Yapay zeka tek başına tamamen farklı bir yaklaşım önermese de, sorulduğunda başka alternatifler de sunabiliyor
Yaşayan belge (Living Document) yöntemi
- Plan belgesi bir kez yazılıp bırakılmıyor; özellik geliştirme sırasında da sürekli güncelleniyor
- Uygulama sürecinde, type check, lint ve test aşamalarında ortaya çıkan değişiklikler anlık olarak yansıtılıyor
- Her kod commit'inde planın en güncel durumunun gözden geçirilmesini isteme alışkanlığı oluşuyor
- Her zaman güncel bir plan korunduğu için, yeni bir sohbet oturumunda yalnızca plan eklenerek bağlam kaybı olmadan kaldığı yerden devam edilebiliyor
Kod incelemesi ve geliştirme alışkanlıklarındaki değişim
- Uygulama başladıktan sonra değişiklikler düzenli olarak kontrol ediliyor ve sonuç tatmin ediciyse yapay zekanın çalışmasına daha fazla güven duyulabiliyor
- Nihai kod incelemesinde güncellenmiş plan belgesi, teknik kararların gerekçesini anlamaya yardımcı oluyor
- Önceden titiz bir plan hazırlayıp bunu belgelendirerek daha iyi bir geliştirici olarak gelişme deneyimi kazanılıyor
- Yapay zekaya açıklama yapmak gerektiği için kendi karar verme süreci daha açık biçimde düzenleniyor
Kaostan düzene
- Bu yöntem, plan belgesini tek gerçeklik kaynağı haline getiriyor, bağlam kaybı sorununu gideriyor ve mimari düşünceyi teşvik ediyor
- Plan belgesi hem şartnameyi hem de uygulama günlüğünü içeriyor; yalnızca "ne"yi değil, "neden" ve "nasıl"ı da kaydediyor
- Nihai sonuç; planlı, iyi belgelenmiş ve güvenilir bir geliştirme süreci oluyor
- Yapay zeka, basit bir uygulayıcı değil, işbirlikçi bir tasarım ortağı olarak konumlanıyor
2 yorum
Geliştiricinin iş akışında PM ve mimar rollerinin ağırlığı artıyor gibi görünüyor.
Hacker News yorumu
Son 2 haftadır akşamları
claude codekullanarak bir projeyi tek seferde tamamlatabilecek "mükemmel prompt"u oluşturmak için inanılmaz derecede odaklandım. Sonunda, tek birCLAUDE.mddosyasının proje mimarisi, model spesifikasyonu, build sırası, test katmanları, senaryolar vb. içeren 8 farklı Markdown dosyasına referans verdiği bir yapı kurdum. Bu proje Databricks Unity Catalog’un model tabanlı yönetişimi için; bu alanda çok deneyimim var ama mevcut araçların yeterince esnek olmadığını hissediyorum. Sonunda Databricks uzmanı, Pydantic uzmanı, prompt uzmanı gibi 3 alt ajandan gerçek planlama dosyaları üzerinde destek aldım. Bu sayede Markdown dosyalarının kalitesi, eski Pydantic sürüm sorunlarından Unity Catalog hakkındaki yanlış anlamalarıma kadar birçok noktada ciddi biçimde iyileşti. Dün bunu gerçekten çalıştırdım; benim birkaç kez araç kullanımını onaylamam dışında, 2 saat içinde araçların ve testlerin büyük kısmı tamamlandı. Bu yaklaşım önceki dönemden o kadar farklı ki çok etkileyiciydi; teknik dokümantasyonu dikkatle hazırlayıp herkesin aynı yöne bakmasını sağlamada gerçekten bir gelecek olduğunu düşünüyorum. Doğrudan kod kazmaktan daha üretken olduğunu da düşünüyorum. Yine de kod yazarken odak düzeyim daha yüksekti; çok sayıda Markdown belgesiyle uğraşınca dikkat daha kolay dağılıyor. Gerçekten ilginç bir çağdayızTest-Driven Development gibi, sistemi önceden tasarlamaya zorlayan örüntülerin yeniden yükselişe geçtiğini hissediyorum. Eskiden sistemi kodu yazarken kademeli olarak şekillendirirdik; ama bu tür yapay zeka tabanlı geliştirmede alanı önceden tasarlayıp haritalıyorsun ve gerçek kod sadece tasarımı hayata geçiren bir boilerplate işi gibi kalıyor. Yapay zeka bu tür boilerplate işlerde gerçekten çok güçlü
Bende de aynı durum var: daha üretkenim ama dikkat çok daha dağınık. Tuhaf bir his ama şu an etkili. Uzun vadede bir çözüm bulmak gerekecek gibi. Şu an bana en uygun yöntem, birden fazla ajanın projenin farklı repository’lerinde farklı görevler yapmasını sağlamak ve sürekli onay vermek. Bir anlamda büyük bir ekibi yöneten proje yöneticisi gibi hissediyorum. Yine de gerçekten ilginç bir çağdayız
Gerçekten çok taze bir yaklaşım. Pratikte deneyde ajanların çalıştığı framework’ün ne olduğunu merak ediyorum
Ben de son zamanlarda ürün detaylarını, kullanıcı yolculuklarını vb. sesli olarak kaydedip bununla teknik dokümantasyon sürecini başlatıyorum. Minimum bir
CLAUDE.md, yazılım geliştirmede Github workflow kullanımı, ama iyi bir CI workflow kurmak zor. Benim playbook’um https://nocodo.com/playbook/“Önce plan yaparsan sonuç daha iyi olur” iddiası bana çok da çarpıcı gelmiyor. Zaten eskiden beri büyük özellikler veya projeler için ister kafamda, ister kağıtta, ister Confluence’da, ister beyaz tahtada olsun; yapıyı, nedeni ve yöntemi önceden düşünürdüm. Yazılım mühendisliğinin %80’i neyi, neden ve nasıl yapacağını düşünme ve netleştirme sürecidir. Paydaşlarla fikirleri ve amacı doğrularsın, araştırma da yaparsın. Son %20 ise gerçek kodlamadır. Bu zaten hep böyleydi ve düzgün planlama ya da hedef tanımı için yapay zekanın mutlaka gerekli olup olmadığından emin değilim
Büyük ekiplerde veya oturmuş kültüre sahip ortamlarda bu doğru olabilir, ama geliştirmenin önemli bir kısmı bireysel projeler, küçük ekipler, yan projeler, hızlı POC’ler, tek seferlik otomasyon araçları gibi alanlarda yoğunlaşıyor. Bu tür işlerde başlangıç noktası genelde doküman/spesifikasyon/test değil; kodu düşünme ve uygulamayla karıştırarak ilerliyorsun. TDD’nin uygun olduğu yerler var ama bazı durumlarda hiç şart değil. Ama AI kodlama ajanları geldikten sonra, fikri açıkça tanımlayıp spesifikasyona dökme süreci çok daha önemli hale geldi. Kafamın içindeki her şeyi dile dökebilmek artık o kadar gerekli. Bugünün en sıcak programlama dili İngilizce
Ben geliştirmeyi ve tasarımı iç içe yürütüyorum. Önce kodlamaya başlıyor, sonra sürekli rafine edip geliştiriyorum. Çoğu durumda kabaca çözüm yolu zaten belli olduğu için derin planlamaya zaman harcamaya gerek duymuyorum
Eskiden prompt engineering dalga konusuydu ama artık bunun gerçek olduğunu hissediyorum.
claude code’u sistemli biçimde kullanmak için bazen 10~20 dakikayı çok dikkatli prompt ve ilk planlamaya harcıyorum. Ben de OP gibi planları dosyalara kaydedip yeni bir context içinde çalıştırıyorum. Gerçekten istediğim şey iyi bir CLI (charm,cckullanıyorum). Uygulama, planlama ve alt ajanlar için ayrı ayrı model kullanabilmek harika olurdu. Uygulamayı local modelle yapıp planı cloud modelle hazırlamak ya da gerektiğinde aralarında geçiş yaparak para tasarrufu sağlamak gibi. Charm, şimdiye kadar kullandıklarım arasında context kaybetmeden ileri geri geçişe en iyi izin veren araç oldu. Paralel alt ajan özelliği declaudecode’un en iyi özelliklerinden biri. (CCRdenedim ama temel modelin ötesine geçemediği için hayal kırıklığıydı)Prompt engineering’in şimdi gündem olması, Twitter’daki hot take’ler ya da içerik üretimi eksenli tartışmalardan kaynaklanıyor. Ama gerçekte prompt engineering çok eskiden beri önemliydi. GIGO (“Garbage In, Garbage Out”) bütün makine öğrenimi projelerinde geçerli bir ilkedir. Bu yüzden iş arkadaşlarıma ve arkadaşlarıma sürekli “gidip kendin denemen lazım” diyorum. 6 ay önce çalışmayan bir şey bugün çalışıyor olabilir. Gerçekte elini kirletmeden neyin değiştiğini, neyin mümkün olduğunu anlayamazsın. Negatif yorumlardan ziyade gerçek başarı hikayeleri, blog yazıları, gist’ler ve örneklerin çok daha değerli olduğunu düşünüyorum. İhtiyaç duyulan şey, basit hesap ya da yazım hatası bulma değil; benim workflow’umu iyileştirip bana yardımcı olabilmesi. Prompt engineering, 10~15 yıl önce Google’da ustalaşmaya çalışmak gibi; sürekli çıkan değişiklikleri ve etkili kalıpları öğreniyorsun
Yapay zeka ile işbirliği yapmak istiyorsan prompt engineering gerçekten kilit nokta
Yapay zeka kullandığım projeler, en iyi dokümante edilmiş ve en iyi test edilmiş projelerimdi. LLM’den performans almak için bağlam şart olduğu için dokümantasyon daha iyi oluyor; test üretim maliyeti düştüğü için de test sayısı artıyor. Hatta kod kalitesinin düşeceği yönündeki tahminlerin aksine, bence kalite daha da yükselecek
Açıkçası "prompt engineering" denen şey, yeni bir medya üzerinden mimari tasarım yapmaktır. Geçmişte "diagram design" gibi beceriler öne çıkmıştı; şimdi de bu yeni bir mimarileştirme biçimi
Kısa süre önce Claude Code’u biraz denedim ve tavsiye edilen workflow’u uygulamayı planlıyorum. Oldukça iyi bir yaklaşım gibi görünüyor. Ama CC’nin kullanım ücreti düşündüğümden pahalı. Basit bir refactoring için 5 dakika çalışma + 15 dakika review yaptım ve 4 dolar tuttu. Ben kendim yapsam 15~20 dakikada biterdi. İnsanların genelde bir özellik başına CC’ye ne kadar harcadığını merak ediyorum. Kimse fiyat konuşmuyor
Abone olursan günlük/haftalık token kullanım sınırı olan $20~$200 sabit ücret var. https://support.anthropic.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
AI yatırımcılarının istediği yön, işgücü piyasasının %15 marjla yapay zeka tarafından ikame edilmesi. Geliştirici bütçesi ile AI bütçesinin 1:1 olduğu bir döneme gireceğiz. Örneğin yıllık 100 bin dolarlık bir senior geliştirici yerine 100 bin dolarlık AI bütçesi konacak. AI bütçesi geliştirme bütçesinden çıkacak; senior maaşları düşebilir ve ekipler ciddi biçimde küçülebilir. Şu anda VC’lerin tamamen sübvanse ettiği bir “territory capture” aşamasındayız ama Twitter’daki VC havasına bakılırsa bu dönem yakında bitecek gibi. 9 aylık işletme gideri için 500 milyon doları tekrar tekrar toplamanın da bir sınırı var
Cursor’dan kısmen Claude Code’a geçtikten sonra maliyet çok arttı. İş yerinde çoğunlukla kullanıyorum, o yüzden yöneticiyi ikna etmek kolaydı ama yan projelerde düşündürücü. Eğlencesine bir uygulama bootstrap ederken her seferinde 20 dolar ödemek istemiyorum
Sonnet (20 euro/ay) ve Opus (100 euro/ay) olmak üzere iki modeli seçip abone olabiliyorsun. Ben Sonnet kullandım, sonra Opus’a geçtim. Sonnet de yeterince kullanılabilir. Token limitleri içinde benim kullanımım için yetersiz kalmıyor. Ama gelecekte de böyle olur mu emin değilim
“Ben kendim de 15~20 dakikada yapardım” demişsin ama o 15~20 dakikayı başka bir işe ayıramaz mısın diye düşünmek lazım
Visual Studio Code/ChatGPT5 preview kombinasyonunu kullanıyorum; workflow’um buna benziyor {muhtemelen Github Copilot aboneliğiyle ödeme yapıyorum ama bugünlerde emin değilim}. Ajan olmayan LLM’lerin kodu çok hızlı bozma eğilimi olduğunu hissediyorum. Agent modunu kullanınca kod inşası tamamen farklılaşıyor. Python geliştiricisi değilim ama LLM’nin yeni kod yığınları üretmesini görmek gerçekten etkileyiciydi. Bitirdikten sonra BitGrid üzerinde küçük bir LLM çalıştırıp sonradan kodu tamamen anlamayı hedefliyorum. Küçük keşif adımlarını tekrar ediyor, genel tasarımı istediğim gibi tutmak için sadece bazı yerleri düzeltiyorum. LLM’nin bir programlama partneri olacağı geleceğe ikna oldum. Visual Studio Code/ChatGPT5 kombinasyonunu kullanan başka biri var mı merak ediyorum
AI araçlarını optimize etmeye çalışırken geliştiricilerin ‘iyi iletişim’ ve ‘beklenti belirleme’nin değerini yeniden keşfetmesi ilginç. Şimdiye kadarki 10x geliştirici imajı, yani dışa kapalı ya da eksantrik dahi tipi, yeniden düşünülmeli
Replit’te de benzer bir deneyim yaşadım. Uygulamanın boyutu büyüdükçe, eğer tasarım belgeleri görevlerin ve gerçekliğin kaynağı olmazsa her şey hızla dağılıyor. OpenAI’da sohbet yavaşlıyor ve çabuk tıkanıyor; bu yüzden belgeleri ayrı hazırlayıp yeni sohbete içe aktarmak yardımcı oluyor. İnsan düzeyinde de aslında bizim de böyle yapmamız gerektiğini hissettim. Kendi kendine geri dönüp dokümante ederek ve “hafıza”yı tasarım belgelerine yazarak, hem kendimizi hem LLM’leri özgürleştirebiliriz
Ben de yakın zamanda bu workflow’u keşfettim ve çok şaşırdım. Önemli olan,
claude’a minimum gereksinimi verip plan modunu serbestçe çalıştırmak. Eğer konu satış metrikleri raporuysa, sadece "Ultrathink relevant sales metrics" demek bile çeşitli metrikler önermesine ve bunları sıralayıp elemesine yetiyor. Her yeni özellik için ayrı bir dizin oluşturup o özelliğin planını dosya olarak yazdırıyorum. Sonrasında uygulama planı, gerekli veri sorguları, gerçek implementasyon, testler, kullanıcı dokümantasyonu ve en sonunda QA aşamasını adım adım yaptırıyorum. Eskiden tek bir satış tahmini özelliği için büyük bir ekip ve zaman gerekirdi; şimdiclaudebunu yarım günde Docker container içinde implement ediyor. Bu değişim yazılıma bakış açımı değiştiriyor. Eskiden şirketler NDA, IP vb. nedenlerle kaynak kodunu dışarıya asla çıkarmazdı. Ama şimdi 20 yılda oluşmuş karmaşık bir ERP sistemi bileclaudetarafından hızla yeniden uygulanabiliyor, üstüne dokümantasyon ve testler de ekleniyor. Elbette pratikte kusursuz değil ama ilerleme hızı gerçekten inanılmazClaude Code’dan iyi sonuç almak için önce planı gerçekten iyi yazmak kritik. Son dönemde Cursor’da GPT-5 High ile plan yapıp bunu Claude Code’a vererek implementasyon yaptırıyorum. Kod tabanında hangi bölümlerin değişeceğini önceden dokümante ettirmek ek olarak %15~20 daha iyi sonuç veriyor. Plan modeli çalışma şeklini, mimariyi ve kalıpları dokümante edip bunun içine özellik tasarımını da işlediğinde sonuç daha iyi oluyor. Son olarak, dokümanları ve planları mutlaka kendin gözden geçirip düzenlemek de çok büyük fayda sağlıyor
Bu sürece frontend tasarımını zarif biçimde dahil etmenin iyi bir yolunu bulan var mı merak ediyorum. Çoğu yaklaşım en fazla bir frontend framework’ünden bahsetmek ya da Figma görseli seviyesinde kalıyor. Bu ise bütünlüklü bir tasarım çözümü gibi hissettirmiyor