- Birden fazla AI ajanını (claude/o3/sonnet vb.) kullanarak kod üretiminden doğrulamaya kadar otomasyonu sağlayan kişisel bir "AI fabrikası" iş akışı yürütülüyor
- Sorun çıktığında kodu (Output) doğrudan düzeltmek yerine plan, prompt ve ajan yapılandırması gibi girdileri (Input) iyileştirerek otomasyon seviyesini artırmak yaklaşımın merkezinde yer alıyor
- Bu şekilde girdiler tekrar tekrar iyileştirildiğinde, ajanlar sürekli gelişiyor ve tekrar eden işlerde verimlilik en üst düzeye çıkıyor
- Ajanlar arasında rol dağılımı yapılıyor: planlama (o3/sonnet4), yürütme (sonnet3.7/4), doğrulama (o3/sonnet4) gibi; böylece paralel işleme ve otomatik geri bildirim döngüsü kuruluyor
- Kod hataları veya stil sorunları da plan şablonlarına yansıtılarak bir sonraki üretimden itibaren iyileştirilecek şekilde tasarlanıyor; tekrarlayan girdi iyileştirmesiyle fabrikanın kendisi büyüyor
AI fabrikasına genel bakış ve temel ilkeler
- Birden fazla claude code penceresi farklı git-worktree'lerde açılarak ayrılmış çalışma ortamları korunuyor
- o3 ve sonnet 4 plan oluşturma için, sonnet 3.7 veya sonnet 4 uygulama/yürütme için, o3 ise sonuç değerlendirme için kullanılıyor
- Planlama, yürütme ve doğrulama ajanlar arasında paralel olarak paylaştırılarak verimlilik artırılıyor
Temel ilke – "Sonucu (Output) düzeltmek yerine girdinin (Input) kendisini iyileştir"**
- Bir sorun olduğunda üretilen kod doğrudan patch'lenmiyor; bunun yerine plan, prompt ve ajan karışımı ayarlanarak otomatik iyileştirme hedefleniyor
- Concept, Factorio oyunundaki gibi otomatik büyüyen fabrika tipi bir AI ajan ağı kurmak
- Bu yapıda planlama-kodlama-doğrulama-iyileştirme döngüsü sürekli dönüyor ve AI ajanlarının kodu üretip doğrulayıp iyileştirdiği bir ortam oluşuyor
Günlük iş akışı – fabrikanın yapısı
- Ana arayüz claude code; yerelde ise mcp, Goose (Azure OpenAI model bağlantısı için), o3 vb. kullanılıyor
1. aşama: Planlama (Planning)
- claude code'a yüksek seviyeli bir görev (task) giriliyor → o3 ek sorular sorduktan sonra bir plan taslağı (
<task>-plan.md) oluşturuyor
- Plan taslağı, hem özgün isteği hem de uygulama planını içeriyor
2. aşama: Yürütme (Execution)
- sonnet 4 planı gözden geçirip onu görev listesine dönüştürüyor
- claude code işi yürütüyor; görevin karmaşıklığına göre sonnet 3.7 veya 4 kullanılıyor
- claude her görev adımında commit geçmişi bıraktığı için sorun olduğunda kolay geri dönüş yapılabiliyor
3. aşama: Doğrulama ve geri bildirim (Verification → Feedback)
- sonnet 4, üretilen kodu plana göre ilk doğrulamadan geçiriyor
- Ardından o3, plan ve ilk gereksinimlerle karşılaştırarak daha sıkı bir doğrulama yapıyor
- o3 gereksiz kodları (ör. lint ignore flag'leri) veya eski yapıları sert biçimde işaret ediyor
- Doğrulamada ortaya çıkan sorunlar koda doğrudan müdahale edilerek değil, plan şablonunu iyileştirerek sisteme yansıtılıyor
- git worktree kullanılarak birden fazla claude code örneği paralel çalıştırılıyor ve eşzamanlı çoklu iş mümkün hale geliyor
Neden "girdi", "çıktı"dan daha önemli?
- Çıktı (Output) atılabilir; ama plan/prompt (girdi) sürekli biriken ve gelişen bir birikimli varlıktır
- Girdi tarafında (plan, prompt) yapılan debug, gelecekteki tüm işlere ölçeklenebilir
- Böylece ajanlar basit üreticiler olmaktan çıkıp kendi kendine öğrenen ve iş birliği yapan yapılara dönüşür
- Örneğin tüm CSV'yi belleğe yükleyen kodun stream işleme kullanacak şekilde değiştirilmesi sağlanırsa, sonrasında bu kalıp tüm CSV işler için plana eklenip gelecekte otomatik doğrulamaya dahil edilebilir
Fabrikanın genişlemesi ve ajan iş birliği
- MCP ile uzmanlaşmış ajanlar farklı işlere atanıp paralelleştiriliyor
- Örneğin tüm Clojure kodunu toplayıp yerel stil kurallarını uygulamaya adanmış bir ajan çalıştırılıyor; bu ajan, claude'un lint/test/debug döngüsünde oluşan stil sorunlarını düzeltiyor
- İç kütüphane kodlarında da eski retry ve
Thread/sleep kullanımını kurum içi retry kütüphanesiyle değiştirmek gibi adımlarla verimlilik ve tutarlılık güçlendiriliyor
- Küçük birim ajanlardan çok sayıda kurularak, belirli alt işlere göre birleştirilip karmaşık iş akışları da otomatikleştirilebiliyor
- Örneğin API spesifikasyonu ve iş senaryolarından yola çıkarak, ajan kombinasyonlarıyla entegrasyon, test ve dokümantasyon otomatik olarak yapılabiliyor
- Temel nokta şu: girdiyi sürekli değiştirip yeniden çalıştırmak; başarısızlık, tıkanma veya bağlam eksikliği olduğunda geri bildirimi bir sonraki denemeye yansıtmak
- Kodun kendisi sarf malzemesidir; asıl varlık talimatlar (girdi) ve ajan yapılandırmasıdır
- Başarısızlık, tıkanma, bağlam yetersizliği gibi tüm dersler bir sonraki girdiye işlenerek fabrika döngüsü tamamlanıyor
Sonraki adımlar ve gelecek yönelim
- Ajanlar arası genel koordinasyonu güçlendirerek tüm iş akışını izleme ve otomasyonu daha ileri taşıma hedefleniyor
- İş belgeleri ile ajan bilgisini daha iyi bağlamak ve daha yüksek seviyeli soyutlama bilgilerini yakalayıp daha etkili kullanmak için iyileştirmeler planlanıyor
- Giderek daha karmaşık iş akışları kurmak; ajanlar arası iş birliği ve karmaşık etkileşimleri büyütmek isteniyor
- Farklı sağlayıcıların token kotalarını azami kullanma ve kolay geçiş yapma yolları da araştırılıyor; özellikle bedrock sonnet 4'ün token sınırlarına karşı
Sonuç
- Şu anda AI fabrikasında otomatik kod üretimi ve doğrulama günlük rutine dönüşmüş durumda; bir fincan kahve süresinde bile kod deploy edilebiliyor
- Henüz tam otomasyon aşamasına gelinmemiş olsa da, "çıktıyı düzeltmek yerine girdiyi iyileştirme" ilkesi fabrikanın özü haline gelmiş durumda
1 yorum
Hacker News görüşü
Bence bu yazı, Claude Code ile bir 'aha' anı yaşamamış biri için neredeyse anlaşılmaz olacaktır.
claude --dangerously-skip-permissionsile izin kısıtlarını kaldırıp karmaşık bir problemi verince, Claude'un çeşitli araçları özgürce kullanarak sorunu çözdüğünü görebiliyorsunuz.Bugün de Docker içinde 486 assembly ile yazılmış bir Mandelbrot fraktal üreticisini doğrudan derletip çalıştırmasını ve debug etmesini istedim.
Gerçekten harika iş çıkardı.
gist bağlantısı
Bence bu, böyle bir IDE ya da LLM için oldukça kolay bir örnek.
Assembly eğitim veri setlerinde fazlasıyla vardır, Docker da öyle.
Cursor'un benim kod tabanımda serbestçe dolaşmasına da izin verdim.
En yeni araçların bir gün gerçekten bu seviyeye ulaşacağını umuyorum ama henüz orada değiliz gibi geliyor.
Ek olarak, Dagger'ın (ve Docker'ın kurucusunun) AI Engineer konferansında yaptığı şu videoyu da tavsiye etmek isterim.
Bu video da biraz zorlayıcı olabilir.
Belki faydası olur diye yazıyorum.
Ben Claude max'ten pro'ya düştüm ve aylık 20 dolarda kullanım limiti fazlasıyla yeterli.
Gemini CLI ile rekabet ediyor gibi görünüyor, bu yüzden artık daha az para ödediğim için memnunum.
Bu düzeyde bir örneği ya da bağlamı neredeyse tüm LLM'ler pek zorlanmadan çözebilir diye düşünüyorum.
Ben çok daha karmaşık Rust dependency yükseltmelerini 30'dan fazla yineleme ile, custom wasm kodu kullanarak yaptım.
Claude, context7 veya mcp-lsp gibi çeşitli araçları bağlayarak ayrıntıları topluyor.
Ama kullanmaya devam ettikçe sınırlara çarpıyorsunuz; daha rafine ve daha zor problemlere itince zayıf yanları ortaya çıkıyor.
“
claude --dangerously-skip-permissionsile karmaşık bir problemi verince çeşitli araçları kullanarak çözüyor” ifadesi hakkında:Claude'un bir saatten uzun süre kodu yanlış şekilde düzeltmeye çalıştığını izlediğim oldu.
Sonunda devreye girip “önce unit test yaz, test geçerse kodu yazıp tekrar haber ver” diye yönlendirdim.
Claude Code gerçekten çok etkileyici bir araç ama temel mimari haritasını tekrar tekrar vermek zorunda kalmanız da bir gerçek.
Bu tür kurulumları, ortaya çıkan kodun gerçekte nasıl kullanıldığını bilmeden değerlendirmek zor bence.
Kişisel olarak kullanılan bir vibe coding uygulamasıysa kulağa inandırıcı geliyor,
ama karmaşık production ortamlarında yüksek kaliteli kod yazdığı iddiasını sindirmek kolay değil.
Kesinlikle katılıyorum.
Ben Claude Code ile kodlama hızımı ciddi biçimde artırıyorum ama her kod değişikliğini mutlaka kendim kontrol edip en iyi sistemin oluştuğundan emin oluyorum.
Sadece kendi haline bıraktığım birkaç denemede kullanıcılara bug çıkardı.
Aslında bu yazıda anlatılan workflow'u ya da kavramı pek anlayamıyorum.
Sanırım biraz muğlak anlatılmış.
Ben günlük olarak birden fazla agent'ın birbiriyle konuştuğu yapılar, asenkron agent'lar, git work tree gibi şeylerle karmaşık production sistemleri üzerinde çalışıyorum.
Çıktıyı asla değiştirmiyorum diyemem ama istediğim sonuç çıkmadığında bunu workflow'umu iyileştirmem için bir sinyal olarak görüyorum.
Ben de benzer bir workflow deniyorum, o yüzden kendi deneyimimi paylaşmak istedim.
Üzerinde çalıştığım Go kod tabanı yüz binlerce satırdan oluşuyor ve gerçekten on binlerce ila yüz binlerce B2C kullanıcı tarafından kullanılıyor.
Performans açısından rahat bir alan ama doğruluk ve güvenilirliğin çok kritik olduğu finans alanındayız.
Ben yalnızca OpenAI anahtarı kullanan bir ortamdayım; bu yüzden repository kopyalama, agent kurma, prompt çalıştırma gibi temel kurulumlar için codex-cli ve basit script'ler kullanıyorum.
Bir codex instance'ı sistem bildirimiyle sıranın bana geldiğini haber veriyor, ben de gerektiğinde fzf ile tmux oturumuna bağlanıyorum.
Henüz MCP kullanmadım ama ilgilendiğim şeyler listesinde.
Bu yaklaşım küçük ve dağınık işleri halletmede inanılmaz yardımcı oluyor ve artık çok daha fazla küçük PR üretiyorum.
“cattle not pets” metaforu burada hâlâ geçerli; küçük işleri hızlıca prompt'layıp dikkat dağınıklığını azaltıyorum.
Daha büyük ölçekli işler için henüz çok uygun değil gibi; belki de ben yeterli context flywheel kuramadım.
Çoğu zaman çıkan kodu her zaman kendim okuyup düzenliyor, sonra code review'a gönderiyorum.
Değişiklik yönetimini de büyük ölçüde elle yapıyorum; branch/commit/push işlemlerini de kendim gerçekleştiriyorum.
Bazı otomasyon araçlarını denedim ama tamamen onlara geçmiş değilim.
“Çıktıyı değil girdiyi düzelt” düşüncesine %100 katılıyorum.
Bu, AI olmasa da çok güçlü bir ilke ve sektör de bunu giderek daha fazla benimsiyor.
LLM gibi deterministik olmayan süreçlerde uygulaması kolay değil; bilimden çok pratik gibi hissettiriyor.
Güzel yazı, teşekkürler.
Ben de "Vibe Specs" adlı yazımda benzer ama biraz daha basit bir workflow tanıtıyorum.
ilgili blog yazısı
Ben bu kuralı tüm kod tabanına uyguluyorum ve AI'ın iki şeyi farklı yapmasını sağlıyorum:
(1) Her şeyden önce soru sormasını
(2) Kodlamadan önce bir
spec.mdbelgesi oluşturmasınıTemel fikir benzer ama ben bunu tek bir LLM ile sınırlıyorum.
Sanırım çoğumuz bunu benzer şekilde deniyoruz.
Ben bireysel geliştiriciyim ve mühendislik odaklı bir bakışla çeşitli üretim otomasyonlarını deniyorum.
Benim için nihai hedef, agent'ın, implementasyondan bağımsız olarak otomatik ürettiği e2e testlerden koda güven duymak.
Henüz tamamen başarmış değilim.
Artık Claude Code da bunu “plan mode” ile native olarak destekliyor.
.md dosyalarını elle oluşturmak aslında yavaş ve can sıkıcı geliyor.
Temel fikir şu: Sistemin ne yapması gerektiğini (hem yüksek seviyede hem ayrıntı düzeyinde), bunun nasıl doğrulanacağını ve mimari ile kod stili gibi implementasyon yöntemlerini sürekli belgeleyebilirsiniz.
Birden fazla model kullanmanın nedeni önyargıyı azaltmak ve belirli işlere uygun fine-tuning seçeneklerini artırmak.
Bir gün büyük ve karmaşık sistemler bile gereksinim setleri temelinde yeniden üretilebilir ve o zaman yazılım nihayet gerçekten gereksinimlere uymuş olur.
Bu noktada geriye kalan tek ‘legacy code’, legacy gereksinim belgeleri olur.
Bakış açısı, üretilen kodu değil gereksinim tanımını düzeltmektir.
ilgili meme görseli
Gerçekte tam olarak ne inşa ettiğinizi merak ediyorum.
AI workflow'ları hakkında her konuşulduğunda, anlatılan şeyin yarı rüya gibi bir akış mı yoksa gerçekten üretken biçimde kullanılan bir sistem mi olduğunu anlamak zor oluyor.
LLM kodun tamamını yazınca ilgim kaçıyor.
Yaklaşık 50 projem var, bunlardan sadece 2'si LLM ile yapıldı ve onlarda bile benim ciddi müdahalem oldu.
Geri kalanlarda daha çok “böyle bir şey olsa güzel olurdu” düşüncesi vardı ama ortaya çıkan sonuca gerçek bir ilgim yoktu.
Sonunda farklı modeller ve implementasyon ayrıntılarıyla boğuşup, istediğim davranış çıkmayınca tasarım belgeleri, prompt'lar ve örnek verilerle bilgisayarla kavga ettiğim bir döngüye giriyorum.
Sadece kod tamamlama şeklinde yardım alırsam çok daha hızlı ve daha az stresli oluyor.
Dönüp bakınca zaman ve para harcamış oluyorum, elde kalan da zar zor çalışan yazılım oluyor.
Net gereksinimler ya da mevcut bir kod tabanı varsa ve ben süreci yönlendiriyorsam, agent'lar oldukça yardımcı olabiliyor; ama vibe coding tarzı akışlar küçük script'ler ya da niş uygulamalar dışında ne eğlenceli geliyor ne de istediğim kaliteyi veriyor.
Ayrıca aşırı pahalı ve kod hâlâ dağınık.
Sonuçta bilgisayarla bitmeyen tartışmalara zaman harcıyormuşum gibi geliyor.
Bunu yapacağıma kendim yapmak çok daha iyi.
Farklı agent'ların kendi work tree'lerinde çalışmasıyla ilgili yaşadığım sorun şu: her agent en küçük ayrıntıya kadar birbirinden tamamen farklı fikirler çıkarıyor, bu yüzden kullanıcı deneyimi hiç tutarlı olmuyor.
Örneğin Documents dashboard'u ile Design dashboard'unu oluşturan agent'lar tamamen farklı bakış açılarıyla tasarlıyor.
Tasarım tutarlılığı da yok, yapı da, DB schema'sı da, API tasarımı da ortak bir çizgi taşımıyor.
Aynı girdi olsa bile çıktılar farklı oluyor.
Sonunda tutarlılık sağlamak için instruction dosyalarını çoğalttıkça, büyük projelerde birkaç bin satır zaten taban seviye hâline geliyor ve context window da yetmiyor.
Sonuç olarak, belirli kuralları ve schema'ları öğrenmiş küçük bir LLM kullanmanın daha uygun olduğunu düşünüyorum.
Prompt üzerinden evren kadar geniş fikir alanını ele alan büyük LLM'lerdense küçük LLM'ler daha doğru seçim gibi.
Agent başına tamamen farklı sonuçlar, tasarımda tutarlılık yok.
Sonuçta bir senior yine şart.
İster AI olsun ister insan, istenen yöne gitmeleri için gerekli asgari yapı ile esnekliği sizin sağlamanız gerekiyor.
Yapı yoksa, doğrudan kendiniz kod yazmanız çok daha iyi.
Ben ilk sürümü kendim oluşturduktan sonra, sonraki işler için Claude Code'a “bunu örnek alarak yap” dediğimde tutarlılığı korumak daha kolay oldu.
ADHD tarzı kodlama, rastgele ürün üretmeye çalışıp tutana kadar tekrar etme yöntemi mi?
Gelecekte genişletilebilir kodu doğrudan kendiniz yazmak daha iyi değil mi?
En azından boş yere karbon ayak izini büyütmemiş olursunuz.
Nihai hedef, geliştiriciyi bu süreçten çıkarmak.
İş sahibi yeni bir CRUD uygulaması istesin ve bu uygulama doğrudan production'a çıksın.
Elbette sonuç bug dolu, yavaş ve kimlik doğrulaması yapılmamış bir DB'ye yazıyor olacak ama bu da benim sorunum değil mantığı.
Sonunda da sıcak çayı bir dikişte içmeye benzer sert bir ifadeyle bitiriyor.
Programlama sonsuza dek değişti ve bu değişimi hızla kabullenmek gerekiyor.
“Gidin kodu kendiniz yazın” demek, herkesin gidip kendi at arabasını tamir etmesini savunmak gibi.
Arabalar da bozuluyor diye eski yöntemde ısrar etmekten çok farklı değil.
Neden sürekli ‘gelecekte genişletilebilir kodu gidip kendin yaz’ denildiğini merak ediyorum.
Bugünün coding assistant'ları zero-shot olarak da genişletilebilir ve bakımı yapılabilir kod yazabiliyor; gerçekten bunu isteyip denediniz mi diye sormak isterim.
İnsanlar da sonuçta trial and error ile cevabı buluyor.
Fark, sadece deneyim arttıkça bunun zihinde simüle edilen kısmının büyümesi.
Karbon ayak izini sorun ediyorsanız, AI veri merkezleri yenilenebilir enerjiyle çalışırsa bu kabul edilebilir mi diye de sorulabilir.
Bence AI'ı workflow'a daha etkili biçimde entegre etmenin yolunu bulmamız gerekiyor.
AI'ı yoğun biçimde kullanmayı deneyen herkes muhtemelen benzer sorunlarla karşılaştı ama hâlâ net bir çözüm yok.
Bu aşamada en önemli şey, AI'a doğru şekilde çok sınırlı roller vermek gibi görünüyor.
Örneğin hisse araştırması için kullandığım bir agent workflow'unda ‘Bullish Guy’ ve ‘Bearish Guy’ adında iki AI var; bunlar tek bir hisse için artıları ve eksileri tartışıyor.
Bu şekilde birbirine zıt pozisyonlardan araştırma yaptırınca daha kapsamlı ve daha derin analiz çıkıyor.
Bu fikri de aslında sosyal medyada insanların tartışma şeklinden esinlenerek geliştirdim.
vibe-coding'de ortaya çıkan şeyin çoğu, kendine referans veren lafların ötesine geçmiyor gibi geliyor; sonunda da pahalı bir hobiye ve 3D printing'in ardından gelen sonsuz oyuncak yapma etkinliğine benziyor.
Bugünün vibe coding dünyasında todo uygulaması, 3D printing'deki “benchy” örneği gibi bir şey mi diye düşünmeden edemiyorum.
Kendi ürünlerini tasarlayan ya da mühendislik yapan herkes kullanıyor.
Sıradan tüketicilerin bunu kullanmamasının tek nedeni, ihtiyaç duydukları neredeyse tüm plastik eşyaları zaten Amazon'dan hemen sipariş edebilmeleri.
Online alışveriş olmasaydı ortalama insan için çok daha faydalı olurdu.
Gelecekte de ancak custom dosyaları kendisi tasarlayabilen kişiler için gerçekten gerekli bir teknoloji olabilir.