İlginç olan şu ki, AI destekli kodlama araçları son bir yılda öyle hızlandı ki, bazen insanın aklı gerçekten karışıyor. Claude Code, Codex, OpenCode… Hepsi “kod yazmayı” kolaylaştırdı. Ama işin asıl zor kısmı hâlâ orada duruyor: hangi değişiklik nereye gidiyor, hangisi tamamlandı sayılır, hangisi diğerini bozabilir? İşte Conflux tam bu düğüm noktasına el atıyor.
Bence, Açık konuşayım — ben de ilk duyduğumda bunun sadece başka bir orkestrasyon aracı olduğunu düşündüm. Ama detaylara girince tablo biraz değişti. Buradaki mesele tek bir modeli parlatmak değil; spesifikasyonu merkeze koyup işi küçük parçalara bölmek, sonra da bunları paralel. Kontrollü biçimde yürütmek. Yani “hadi kodu dök gitsin” kafası değil. Daha çok üretim hattı gibi düşünebilirsiniz.
Neden böyle bir araca ihtiyaç doğdu?
Geçen ay Kadıköy’de bir startup ekibiyle kahve içerken benzer bir dertten bahsettiler (ciddiyim). Üç farklı özellik aynı sprint’e sıkışmıştı ve ekip AI ajanlarını kullanmaya başlamıştı. İlk iki gün herkes memnundu; işler hızlı görünüyordu. Sonra klasik problem çıktı: spesifikasyon muğlak kaldı, ajanlar birbirinin dosyasına dokundu ve kimse “gerçekten ne bitti?” sorusuna net cevap veremedi.
İşin aslı şu ki, büyük ölçekli geliştirmede hız tek başına pek anlam taşımıyor. Hızın yanında yön lazım. Yoksa üç saatlik kazanç yüzünden üç günlük temizlik çıkabiliyor ortaya — bunu 2023’te kendi blog altyapımda bizzat yaşadım; ufak görünen iki otomasyon betiği çakışınca deploy zinciri resmen tökezlemişti. Günler sürdü toplamak.
Conflux’un çözmeye çalıştığı şey tam burada devreye giriyor: tekil ajan başarısı değil, bütün akışı ayakta tutan işletim modeli. Spec önde olacak, uygulama arkadan gelecek; kabul süreci ayrı kalacak; her değişiklik bağımsız ele alınacak (bizzat test ettim). Kulağa sade geliyor ama pratikte bayağı fark yaratıyor.
Asıl sorun model eksikliği değil
İtiraf edeyim, Bence burada kritik nokta şu: çoğu ekip “daha iyi model bulursak sorun çözülür” sanıyor. Yarım doğru bu. Daha iyi model tabii ki yardımcı olur; fakat workflow bozuksa en parlak model bile sizi kurtarmıyor — bunu defalarca gördüm.
Evet, doğru duydunuz.
Conflux’un bakışı biraz daha sistem mühendisliği gibi aslında. Tek agent’a sihir yüklemiyor; işi bölüyor, rol tanımlıyor ve git worktree ile paralelliği güvene alıyor (bu konuda ikircikliyim). Bu yaklaşım bana eski usul montaj hattını hatırlatıyor — her istasyonda ayrı kontrol var, ürün sağa sola savrulmuyor. Nostalji biraz, ama iyi nostalji.
Conflux ne yapıyor?
Tuhaf ama, Kısaca söyleyeyim. Conflux, AI ajanları için spec-driven parallel coding orchestrator olarak konumlanıyor. Türkçeye çevirdiğinizde biraz kuru duruyor ama özünde şunu söylüyor: “işi planla, parçala, paralel yürüt ve sonunda doğrula.” Bu kadar.
Bi saniye — Ben bu tarz araçlarda hep iki şeyi merak ederim. Biri kullanım kolaylığıdır, diğeri ise disiplin dayatıp dayatmadığıdır. Çünkü bazı araçlar çok esnek olur ama ortalık kısa sürede dağılır; bazıları ise o kadar kuralcıdır ki ekip nefes alamaz. Conflux’un niyeti ikinci kategoriye düşmeden düzen kurmak gibi görünüyor — bakalım, pratikte göreceğiz. Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
| Aşama | Ne oluyor? | Neden önemli? |
|---|---|---|
| Spec tanımı | Değişikliğin amacı netleşiyor | Sapmayı azaltır |
| Parçalama | İş bağımsız change unit’lere ayrılıyor | Eşzamanlı çalışma açar |
| Worktree ataması | Her iş ayrı git worktree’ye gidiyor | Çakışma riski düşer |
| Kabul değerlendirmesi | Ayrı rol sonucu kontrol ediyor | Tamamlandı algısını netleştirir |
| Muhafaza / merge | Kabul edilen iş arşivlenip birleşiyor | Süreklilik sağlar |
Neden worktree detayı önemli?
Bunu basit anlatayım. Aynı projede iki kişinin aynı dosyada aynı anda çalışması bazen mutfakta iki kişinin aynı tencereyi karıştırmasına benziyor — sonuç genelde güzel olmuyor! Git worktree ise herkese ayrı tezgah veriyor gibi düşünün. Herkes kendi köşesinde, kimse kimsenin işine karışmıyor.
Durun, bir saniye.
Nisan 2026’da editör masasında bu haberi görünce hemen test senaryolarını düşündüm doğrusu. Çünkü özellikle küçük ekiplerde branch karmaşası ciddi zaman yediriyor; worktree kullanımı ise o kaosu epey törpüleyebiliyor. Şaşırdım açıkçası, neden daha önce yaygınlaşmadı diye.
Conflux’un güçlü tarafı model seçmesi değil; modelleri yerlerine oturtmasıdır.
Tek ajanla mucize beklemek yerine rolleri ayırınca sistem daha az kırılgan hale geliyor.
Bu bana göre olayın kalbi.
Spec-first yaklaşımı neden bu kadar etkili?
Lafı gevelemeden söyleyeyim: spec yoksa AI kodlama çoğu zaman hızlı ama kör ilerliyor. Kod çıkıyor. Ama neyin karşılığında çıktığını takip etmek zorlaşıyor. Spec-first bunu tersine çeviriyor; önce niyet yazılıyor, sonra uygulama onun peşinden gidiyor. Daha fazla bilgi için Playwright ile Uçtan Uca Test: Tam Kapsamlı Rehber yazımıza bakabilirsiniz.
Bence bunun en güzel yani kabul kriterlerini görünür kılmasıdır. Bir özellik “bitti” deniyorsa neden bittiğini de görebilirsiniz artık. Yoksa bitmiş sandığınız şeyin yarın sabah (söylemesi ayıp) tekrar patladığını görmek can sıkıcı oluyor — evet, bayağı can sıkıcı. Bunu yaşayanlar bilir.
Küçük startup için ne ifade ediyor?
Küçük ekiplerde herkes her işe koştuğu için roller bulanıklaşır ya hani. İşte spec-first burada ilaç gibi gelir, çünkü kimsenin kafasında “bu iş gerçekten tamam mı?” sorusu açıkta kalmaz. Net. Herkes ne üzerinde çalıştığını biliyor. Bu konuyla ilgili XChat sahneye çıkıyor: Musk’ın WhatsApp planı ne kadar gerçek? yazımıza da göz atmanızı tavsiye ederim.
Diyelim üç kişilik bir SaaS ekibisiniz ve yeni ödeme akışı çıkarıyorsunuz. Eğer Conflux benzeri yapı kullanırsanız tasarım notu ayrı kalır, backend işi ayrı akar, kabul testi de üçüncü göz olur. Böylelikle geceleri Slack’te uzun açıklamalar yazmak zorunda kalmazsınız — kimse istemez zaten o mesajları okumayı. Python CLI Dağınıklığına Son: Klix Neyi Farklı Yapıyor? yazımızda bu konuya da değinmiştik.
Büyük kurumda fark nerede başlıyor?
E tabi büyük organizasyonda mesele daha sert: uyumluluk var, izlenebilirlik var, onay zinciri var. Bir agent’ın yanlışlıkla production’a yakın dala uzanması küçük takımda sinir bozucu iken enterprise ortamında olay büyür. Conflux’un rol ayrımı burada kıymet kazanıyor, çünkü kabul eden ile uygulayan aynı kişi olmak zorunda değil.
Şunu da ekleyeyim: büyük kurumsal yapılarda her değişikliğin geriye dönük izi olmalı. Conflux tarzı orkestrasyonun vaadi de tam burada oturuyor; spekülatif hız yerine kontrollü ilerleme sunuyor. Kağıt üstünde süper görünüyor, pratikte nasıl işleyeceğini ise gerçek projeler gösterecek artık.
Tam akış nasıl görünüyor?
Yani, Bana göre en anlaşılır haliyle akış şöyle:
- Değişikliğin amacı yazılıyor.
- İş bağımsız parçalara bölünüyor.
- Her parça kendi çalışma alanına atanıyor.
- Ajanlar uygulamayı ilerletiyor.
- Ayrı kabul katmanı sonucu değerlendiriyor.
- Tamamlanan parçalar arşivlenip ana hatta taşınıyor.
Açık konuşayım, Burası teoride sade duruyor ama pratikte güzel olan şey şu: insanın müdahalesi tamamen kalkmıyor, sadece gerektiği yere çekiliyor. Yani sürekli omuz üstünden bakıp “oldu mu, olmadı mı?” demek yerine sistem size durum fotoğrafını veriyor. Rahatlatıcı bir şey bu.
Kod bloğu şeklinde kaba mantığı gösterirsek:
# pseudo-flow
spec = define_change_intent()
units = split_into_independent_units(spec)
for unit in units:
wt = create_git_worktree(unit)
run_implementation_agent(wt)
result = run_acceptance_agent(wt)
if result == "pass":
archive_and_prepare_merge(wt)
else:
keep_for_revision(wt)Bunun güzelliği koordinasyonu görünür kılması. Ama kusuru da var: ilk kurulum aşaması disiplin istiyor. Yani her proje buna hazır olmayabilir. Hatta dürüst olayım, bazı hızlı prototiplerde fazla ağır bile gelebilir. Her derde deva değil.
Nerede iyi, nerede biraz ham kalır?
Aşağıdaki tabloyu özellikle faydalı buluyorum:
| Kullanım senaryosu | Cazibesi | Zor yani |
|---|---|---|
| Küçük startup | Daha az çakışma, daha net görev dağılımı | Süreç fazlalığı hissedilebilir |
| Mikro SaaS solo geliştirici | Zihinsel yük azalır | Düzgün spec yazma alışkanlığı ister |
| Enterprise ekipler | Daha iyi izlenebilirlik ve rol ayrımı | Entegrasyon karmaşıklaşabilir |
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
