- LLM destekli yazılım geliştirmede mimar-geliştirici-incelemeci çoklu ajan iş akışıyla on binlerce satırlık projeleri düşük hata oranıyla sürdürmenin somut yöntemi paylaşılıyor
- Programlamanın kendisinden çok bir şeyler üretmeye ilgi duyuyordu; LLM’ler kod yazmada iyi hale geldikçe üretmeye odaklanmak mümkün oldu
- Kod yazma becerisinden çok sistem mimarisi tasarlama ve doğru seçimleri yapma gibi mühendislik becerileri çok daha önemli hale geldi
- Farklı modeller birlikte kullanılarak kod inceleme kalitesi yükseltiliyor ve her modelin güçlü ve zayıf yönleri role göre ayrıştırılarak değerlendiriliyor
- Gerçek bir e-posta özelliği ekleme oturumunun tamamı paylaşılırken, mimari kararlardan QA’ya kadar insanın yönettiği LLM iş birliği süreci ayrıntılı biçimde kaydediliyor
LLM ile üretmenin avantajları
- Programlamayı sevdiğini düşünüyordu ama aslında sevdiği şey bir şeyler üretmekti; LLM’ler programlamada iyi hale geldikçe durmaksızın bir şeyler üretmeye başladı
- Codex 5.2’nin çıktığı dönemden itibaren ve yakın zamanda Opus 4.6 ile birlikte, çok düşük hata oranıyla yazılım yazmak mümkün hale geldi. Bu oran, kodu elle yazdığı zamana kıyasla anlamlı ölçüde daha düşük olabiliyor
- Eskiden 2-3 günlük çalışmanın ardından kod bakım yapılamaz hale gelirken, şimdi haftalar boyunca aralıksız çalışıp on binlerce satır faydalı kodu istikrarlı biçimde büyütebiliyor
- Mühendislik becerileri değersizleşmedi, sadece yer değiştirdi: kodu doğru yazma yeteneği yerine, sistemi doğru biçimde mimarileştirme ve kullanılabilir kılma muhakemesi kritik hale geldi
- Temel teknolojisini iyi bildiği projelerde (ör. backend) on binlerce SLoC’de de sorun yaşamıyor; ama iyi bilmediği teknolojilerde (ör. mobil uygulamalar) hâlâ yanlış seçimlerin birikmesiyle kod karmakarışık hale gelebiliyor
- LLM’lerin ilk döneminde (
davinci sonrası) her kod satırını gözden geçirmek gerekiyordu; sonraki nesillerde bu fonksiyon düzeyine, bugün ise yalnızca genel mimari düzeyine indi. Gelecek yıl buna bile gerek kalmayabilir
Bu yöntemle yapılan projeler
- Stavrobot: güvenliğe odaklı bir LLM kişisel asistanı. Takvim yönetimi, uygunluk değerlendirmesi, araştırma, kod yazarak kendini genişletme, hatırlatıcılar, ev işlerini otonom yönetme gibi görevler yapıyor. Asıl değer tek bir öldürücü özellikte değil, binlerce küçük sürtünmeyi ortadan kaldırmasında yatıyor
- Middle: sesli notları kaydedip metne dönüştürerek webhook ile ileten küçük bir kolye tipi cihaz. Her zaman taşınabilir olması ve neredeyse sıfır sürtünmeyle kullanılabilmesi temel nokta
- Sleight of Hand: saniye düzeyinde düzensiz tik-tak yapan ama dakika düzeyinde her zaman doğru kalan bir duvar saati sanat projesi. 500ms~1500ms arası değişken tik, algılanması zor hız değişimleri sonrası rastgele durma, çift hızda ilerleyip 30 saniye bekleme gibi çeşitli modlar sunuyor
- Pine Town: herkesin küçük bir arazi parçası alıp çizim yaptığı sonsuz çok oyunculu bir tuval; etkileşimli bir çayır projesi
- Bu projelerin hepsi LLM ile yapıldı; kodun çoğunu doğrudan hiç okumamış olsa da her projenin mimarisini ve iç işleyişini iyi biliyor
Harness aracı
- Harness olarak OpenCode kullanıyor; Pi ile de iyi deneyimler yaşamış
- Bir harness için iki temel gereksinim var:
- Birden fazla şirketten çeşitli modelleri kullanabilmek: çoğu birinci taraf harness (Claude Code, Codex CLI, Gemini CLI) yalnızca kendi modellerini desteklediği için bu gereksinimi karşılamıyor
- Özel ajanların birbirini otonom biçimde çağırabilmesi
Birden fazla model kullanma ihtiyacı
- Belirli bir model tek bir insan gibi düşünülebilir; bağlam sıfırlansa bile aynı görüşleri/güçlü ve zayıf yönleri koruma eğilimi gösterir
- Bir modele kendi yazdığı kodu inceletmek, kendi kararlarını onaylama eğilimi yüzünden neredeyse anlamsızdır; ancak incelemeyi başka bir modele yaptırınca kalite ciddi biçimde artar
- Şu anda Codex 5.4 titiz ve seçici olduğu için inceleme işine uygun; Opus 4.6 ise yazarın kendisinin alacağı kararlara çok iyi uyuyor; Gemini 3 Flash da bazen diğer modellerin kaçırdığı çözümleri önerebiliyor
- En iyi sonuçlar için tüm modelleri karma biçimde kullanmak gerekiyor
İş akışı: Mimar → Geliştirici → İncelemeci
- İş akışı mimar, geliştirici ve 1-3 incelemeciden oluşuyor. Bunlar OpenCode ajanları (skill dosyaları) olarak yapılandırılmış
- Birden fazla ajan kullanmanın üç nedeni var:
- Pahalı modelleri (Opus) planlama için, daha ucuz modelleri (Sonnet) kod yazma için kullanarak token tasarrufu sağlamak
- Farklı modellerle inceleme yapıldığında farklı türden sorunları yakalamak
- Rol bazlı yetki ayrımı yapabilmek (ör. salt okunur vs yazma yetkili)
- Aynı model ve aynı yetkilerle iki ajan kullanmak, tek bir kişinin farklı şapkalar takmasına benzer; çok anlamlı değildir
- Skill dosyalarını bizzat elle yazıyor. Skill yazma işini LLM’ye vermek, birine “harika bir mühendis nasıl olunur” yazdırıp sonra o talimatı geri vererek “şimdi harika ol” demeye benziyor
Mimar rolü
- Mimar (şu anda Claude Opus 4.6), doğrudan konuşulan tek ajan ve en güçlü model olmak zorunda
- Çok spesifik bir özellik ya da hata düzeltme hedefi veriliyor; hedefler, kısıtlar ve trade-off’lar netleşene kadar 30 dakikaya kadar süren konuşmalar yapılıyor
- Çıktı, tek tek dosya ve fonksiyon seviyesine kadar inen oldukça düşük seviyeli bir plan oluyor
- Bu, basit bir promptlama değil; LLM’nin yardımıyla planın birlikte şekillendirilmesi süreci. LLM yanlış olduğunda ya da kendi yaklaşımından saptığında sık sık düzeltiliyor ve projeyi “kendi projesi” haline getiren asıl katkı da bu
- Açıkça
approved kelimesi söylenene kadar uygulamaya başlamaması için yapılandırılmış. Bazı modeller, anladığını düşündüğü anda aceleyle implementasyona geçme eğiliminde
- Onaydan sonra mimar işi görevlere bölüyor, bunları plan dosyasına ayrıntılı biçimde yazıyor ve geliştiriciyi çağırıyor
Geliştirici rolü
- Geliştirici için daha zayıf ama token açısından verimli bir model (Sonnet 4.6) kullanılabiliyor
- Plan takdir alanını en aza indirdiği için rol, katı biçimde planda belirtilen değişiklikleri uygulamakla sınırlı
- Uygulama tamamlandıktan sonra incelemeciler çağrılıyor
İncelemeci rolü
- Her incelemeci, planı ve diff’i bağımsız olarak gözden geçirip eleştiriyor
- En az Codex her zaman kullanılıyor; bazen Gemini ekleniyor; önemli projelerde Opus da ekleniyor
- Geri bildirim geliştiriciye dönüyor; incelemeciler arasında görüş ayrılığı olursa mimara eskale ediliyor
- Opus, doğru geri bildirimi seçmekte çok başarılı; aşırı titiz olup uygulamaya kıyasla pratikte düşük risk taşıyan geri bildirimler ise bazen göz ardı ediliyor
Genel yaklaşım ve başarısızlık biçimleri
- Bu yöntemle fonksiyon düzeyinin üzerindeki tüm seçimleri kavrayıp bu bilgiyi sonraki işlerde kullanabiliyor
- LLM’nin kod tabanında belirli unsurları kaçırdığı kör noktalar olduğunda, “Y kullanılmalı” diye yönlendirmek LLM’nin Y’nin varlığını fark etmesini ve daha iyi bir çözüme geçmesini sağlayabiliyor
- Teknolojiye yeterince aşina olunmadığında, LLM’nin yanlış kararları fark edilemiyor ve bunun üzerine yanlış kararlar birikerek sonunda çözülemez bir duruma ulaşılıyor
- “Kod çalışmıyor” diye tekrar tekrar belirtildiğinde LLM’nin “Anladım! Düzeltiyorum” deyip durumu daha da bozması, tipik bir başarısızlık deseni
- Bu yüzden, belirli bir teknolojiye aşina olunmasa bile planlama aşamasında olabildiğince çok şey anlamaya çalışılıyor
Gerçek oturum: Stavrobot’a e-posta desteği eklemek
- Gerçek ve açıklamalı oturumun tam metni paylaşılıyor; araç çağrıları ve uzun kısımlar çıkarılmış olsa da konuşmalar ve karar alma süreci aynen korunmuş
- İlk konuşma: yüksek seviyeli hedef veriliyor (“bu bota e-posta desteği eklemek istiyorum”) → LLM kodu okuyup mevcut deseni (gelen webhook → enqueueMessage → LLM işleme → yanıt) anlıyor ve tasarımla ilgili sorular soruyor
- Gelen yöntem (IMAP polling, webhook, SMTP sunucusu), giden yöntem, çift yönlü olup olmayacağı, mimari (ayrı container vs in-process), HTML e-posta işleme, thread takibi, ek dosyalar vb.
- Tasarım kararları: gelen için Cloudflare Email Worker webhook’u, giden için SMTP istemcisi, tamamen çift yönlü konuşma, in-process işleme, Markdown’a dönüştürme, bağımsız e-posta ele alma, ek dosya desteği
- LLM’nin ayrıntılı tasarım önerisi: MIME parse etme (
mailparser kullanımı), webhook doğrulama (paylaşılan secret), giden konu satırı gereksinimi, yalnızca HTML e-postaların işlenmesi, From adresi kimliği, yönlendirilmiş e-postaların işlenmesi, giden ek dosyalar dahil 7 endişe noktası ve bunlara ilişkin somut tasarım önerileri
- Worker payload’unu
{ from, to, raw } olarak sadeleştirip parse işlemini sunucu tarafında yapma önerisi
- Config yapısı, gelen/giden akışları, değişecek dosyaların listesi ve açık biçimde tanımlanmış hedef dışı maddeler (YAGNI)
- Planın rafine edilmesi: README.md ve config.example.toml güncellemeleri ile e-posta allowlist sayfasında E.164 doğrulamasının kaldırılması gibi eksikleri insan işaret ediyor → LLM bunları plana entegre ediyor
- 6 göreve bölme: Config/bağımlılıklar, allowlist, allowlist UI/backend doğrulaması, gelen e-posta, giden e-posta, README/testler
- Ek iyileştirme: SMTP ayarı olmasa bile yalnızca gelen e-postanın çalışabilmesi için SMTP alanlarını opsiyonel hale getirme fikri öneriliyor → uygulanıyor
- QA’da bulunan hata: sahip e-postası kayıtlı olmadığı için mesajların düşmesi → neden
seedOwnerInterlocutor içinde e-posta kanalının eksik olması → düzeltildi
- Kod iyileştirme önerisi: kanal başına hardcode edilmiş
if blokları yerine ortak kanal listesini dönen bir refactor. Telegram’daki sayısal dönüşüm özel durumu tartışıldıktan sonra, döngünün yalnızca seedOwnerInterlocutor içinde uygulanmasına; getOwnerIdentities’nin ise tür farkı temel olduğu için korunmasına karar veriliyor
- Wildcard e-posta allowlist’i:
*@example.com biçiminde alan adı düzeyinde wildcard desteği ekleniyor. Tek kullanımlık e-posta adresleri kullanılan gerçek kullanım senaryolarında buna ihtiyaç duyuluyor
- Güvenlik değerlendirmesi:
"me@mydomain.com"@evildomain.com gibi saldırıları önlemek için *, [^@]* biçimine dönüştürülüyor ve böylece @ sınırını aşamıyor
myusername+*@gmail.com gibi kısmi wildcard desenleri de destekleniyor- Regex kullanılırken e-posta adresindeki diğer tüm karakterlerin escape edilmesi gerektiğini insan özellikle belirtiyor
- Hem sahip alanlarında hem de allowlist’te wildcard’ın çalıştığı doğrulanıyor; ikisinde de aynı
matchesEmailEntry yardımcı fonksiyonu kullanılıyor
- Tüm özellik yaklaşık 1 saatte tamamlanıyor
Epilog
- Aşırı gösterişli bir kurulum olmasa da çok iyi çalışıyor ve sürecin güvenilirliğinden memnun
- Stavrobot’u neredeyse bir aydır 7/24 çalıştırıyor ve sistem çok kararlı
10 yorum
20 yılı aşkın süre önce web editörleri ve seri üretim blogların modasıyla kimsenin görmeyeceği ana sayfalar ya da gönderiler topluca üretilmişti; yapay zeka çağında da benzer bir tablo var, ancak özel uygulamalar yapmak ve bu süreç ya da rutinleri paylaşmak kesinlikle değerli ve büyük bir birikim diye düşünüyorum. Kişisel olarak bence bu çağda mesele yapay zekayla para kazandıran uygulama ya da hizmetler yapmak değil, benim ihtiyaç duyduğum özel araçları kolayca üretip verimliliği artırmak.
Aslında insanlarda da durumun böyle olduğunu düşünüyorum. İnsanların çeşitliliği gözetmesi gerekmesinin nedenlerinden biri de bu değil mi...
Bu bir dil modeli olduğu için, planlamayı pahalı modelin yapması doğrudur.
> Pahalı model (Opus) planlama için, ucuz model (Sonnet) ise kod yazımı için kullanılarak token tasarrufu sağlanıyor
Genelde planlama için Sonnet, kodun uygulanması için Opus kullanan da çok oluyor ama burada tam tersi.
Ben de planlamayı opus ile codex'i paslaşıtırarak yaptırıyorum.
Kodlamayı opus'a yaptırıyorum; kod incelemesini ise başka bir opus ile codex'e yaptırıyorum.
Bunu yaparken fark ettiğim şey, ister yapay zeka olsun ister insan, başkasını eleştirme konusunda gerçekten çok iyi oldukları..
https://code.claude.com/docs/ko/model-config#opusplan-model-ayarlari
Ben de Claude'u
opusplanile model yapılandırmasını ayarlayıp kullanıyorumOh my opencode varsayılan ayarında planlamayı opus yapıyor, uygulamayı ise daha hafif bir model gerçekleştiriyor
Benim çevremde insanlar planlama/tasarımı Sonnet ile yapıp kodu da GLM-5 ile yazıyor..
Ben de planlamayı Sonnet ile, kod implementasyonunu ise Opus ile yapıyorum; ama yazarın yöntemi daha verimli olabilir gibi görünüyor.
Ben de planlamayı Opus ile yapıyorum; inceleme için Codex high, gerçek kodlama içinse sonet ya da codex medium kullanıyorum.