Kısa özet
- Beş hafta boyunca kodlama ajanımı ikiye böldüm: ana model, yani Opus ve sonra Fable, okur, karar verir ve inceler; bir işçi ajan ise kodu yazılı bir brifingden yazar. Buna mimar deseni diyorum ve artık herkese açık bir beceri: GitHub’da architect-skill , MIT lisanslı.
- Ana model yazmayı bıraktı. 49 mimar oturumunda, 1.467 prompt boyunca bir kaynak dosyayı 6 kez düzenledi. Aynı haftalardaki 275 düz oturumda ise 3.081 promptta 244 dosya düzenledi. Yani 100 prompt başına 0,4’e karşı 7,9.
- Prompt başına toplam token düşmedi. İki hafta boyunca kötü biçimde yükseldi, sonra düz oturumların bulunduğu yere geri döndü. Değişen şey bunları kimin harcadığıydı: işçi token’larındaki Opus payı %100’den yaklaşık %4’e indi ve 14 Eylül’den bu yana bir mimar oturumundaki bir prompt ana modelde 364k, Sonnet işçilerinde 205k ve Opus işçilerinde 80k ağırlıklı token’a mal oluyor.
- Bir aboneliğin önemsediği şey tam olarak bu dağılım. Claude Max, tüm modelleri kapsayan haftalık limitini her modelin tarifesinden ölçüyor; yani bir Sonnet token’ı bu limitten bir Opus token’ının %40’ı kadar düşüyor ve Fable’ın hiçbir işçinin dokunmadığı, kendine ait daha dar bir haftalık limiti var.
- İşçileri başsız (headless) bir Claude Code üzerinden DeepSeek’e yönlendirmeyi de denedim. Liste fiyatlarıyla aynı trafik Sonnet’te 202 dolar veya Opus’ta 505 dolar yerine 10 dolardı. Bir abonelikte bu tasarruf yok, çünkü abonelik zaten ödenmişti. Bundan vazgeçtim. Token başına ödüyorsanız yine de o bölümü okuyun, çünkü asıl mesele rakamlar.
Bu, bir dizinin üçüncü yazısı. İlki tek bir ayarın bir bağlam penceresine ne yaptığını ölçtü, %17 daha az token , ikincisi ise bir bağlam penceresinin ne kadara mal olduğunu ve nedenini açıklıyor. Bu yazı diğer kaldıraçla ilgili: bağlamın ne kadar büyük olduğu değil, onu hangi modelin tuttuğu.
Desen nedir
Bir kodlama ajanı oturumu iki tür iş yapar. Düşünür: kod tabanını okur, neyin değişeceğini çözer, isimlere, imzalara ve uç durumlara karar verir, diff’i kontrol eder. Ve yazar: kodu yazar, test dosyasını çalıştırır, lint’i düzeltir. Düşünmek, sınır modelinin fiyatını hak ettiği yerdir. Yazmak değil. Yazmanın çoğu, ondan önce gelen kararla belirlenir ve küçük bir model, kararlaştırılmış bir planı büyük bir model kadar iyi uygular.
Bu yüzden beceri oturumu ikiye bölüyor. Ana model mimardır. Bir kaynak dosyayı düzenlemek dışında ana döngüdeki her şeyi yapar:
- Gereksinimi sorgular ve kod tabanını keşfeder.
- Tasarım kararlarını verir: yaklaşım, veri akışı, isimler, imzalar, uç durumlar. Yansıtılacak en yakın mevcut desen. Kök nedeni çözen en küçük değişiklik.
- Ayrık dosya kümelerine sahip dilimlere böler.
- Her dilim için bir uygulama brifingi yazar.
- Geri dönen diff’i inceler, kapıları çalıştırır, commit eder.
İşçi, taze bir bağlam penceresine sahip bir alt ajandır. Brifingi alır ve başka hiçbir şey; kodu yazar, brifingin adını verdiği test dosyalarını çalıştırır ve kısa, yapılandırılmış bir rapor döndürür. Sonra bağlamı atılır. Ana oturumun geçmişinin parçası olmaz; bu kulağa geldiğinden daha önemlidir: ana oturumun okuduğu her şey sonraki her çağrıda yeniden gönderilir, yani kendi bağlamında on iki dosya ve bir test günlüğü okuyan bir işçi, tüm bunları mimarın faturasından uzak tutar.
Brifing sözleşmenin tamamıdır. Benimkinde yedi alan var ve beceri çoğunlukla bunları iyi doldurmakla ilgili:
## Implementation brief: <slice>
Goal: one sentence, observable outcome
Context: what exploration found: excerpts, the pattern to mirror, line anchors, gotchas
Files: paths to create/modify, exclusive ownership for this slice
Design: the decided approach: data flow, names, signatures, edge cases
Constraints: project rules that apply: style, layers, security
Out of scope: what not to touch, including files owned by other slices
Verify: exact commands and expected outcome
Bir brifing seçenekler değil kararlar içerir. Hâlâ iki yaklaşımı tartıyorsam devretmeye hazır değilim.
Bir istisna var. Devretmenin sabit bir ek yükü vardır: brifingi yazmak, işçinin başlaması, raporu okumak, diff’i incelemek. Bir yazım hatası düzeltmesi, bir yapılandırma değeri, bir sürüm artırımı, ölü bir anahtarın silinmesi, tek satırlık bir düzeltme ve onun regresyon testi: bunlar için mimar doğrudan düzenler, çünkü brifing düzenlemeden daha pahalıya gelir. Ölçüt satır sayısı değil maliyettir. Düzenleme bir tasarım yargısı gerektirdiği ya da deponun kritik olarak işaretlediği bir yola dokunduğu anda iş bir işçiye gider.
İşinizi büyütmeye hazır mısınız?
Bugün ücretsiz denemenizi başlatın ve günler içinde sonuçları görün.
Bir abonelik aritmetiği neden değiştirir
Token başına ödüyorsanız durum basit. Opus 5, milyon girdi token’ı için 5 dolar ve milyon çıktı token’ı için 25 dolar; Sonnet 5 ise 2 ve 10 dolar. Opus’tan Sonnet’e taşınan her uygulama token’ı, eskisinin %40’ına mal olur.
Ben abonelik ödüyorum ve orada durum farklı ve bence daha güçlü. Claude Max’in bir değil iki haftalık limiti var: tüm modelleri kapsayan ve her token’ın o modelin tarifesinden çektiği bir limit, ve yalnızca Fable’ın çektiği ayrı, daha dar bir limit. Opus’un kendine ait bir limiti yok. Bu da bölünmeye iki etki veriyor. Bir Sonnet işçisinin yaptığı iş, ortak limiti bir Opus işçisinin çekeceği tarifenin %40’ından çeker; yani bir oturumun token’larının üçte ikisini Sonnet’e taşımak, toplam token sayısı değişmese bile haftanın daha uzun süre dayanmasını sağlar. Ve mimar Fable olduğunda, yazmaya harcamadığı her token, ilk tükenen limitte kalan bir tokendır. Yani mimar deseni bir düz oturumla tam olarak aynı sayıda token harcasa bile, bunları kimin harcadığı haftanın ne zaman biteceğini yine belirlerdi.
O “bile"nin çok iş yaptığı ortaya çıktı.
Transkriptler ne söylüyor
Claude Code her oturumu bir JSONL transkriptine, her işçi koşusunu da oturumun dizini altındaki kardeş bir dosyaya yazar. 19 Ağustos’tan beri hepsi bende: üç veya daha fazla prompt içeren 324 etkileşimli oturum; bunların 49’u deseni kullandı, yani bir uygulayıcı ajan başlattı ya da ona bir brifing gönderdi. Token’lar faturaya göre ağırlıklandırıldı: taze girdi 1, önbellek yazmaları 1,25 veya 2, önbellek okumaları 0,1. CI koşuları hariç tutuldu.
Soldan sağa okunduğunda ilk iki hafta için bu bir başarı hikâyesi değil.
24 Ağustos haftasında bir mimar oturumu prompt başına 1,40M ağırlıklı token’a mal oldu. Aynı hafta düz oturumlar 0,42M’de kaldı. Üç buçuk kat daha fazla ve fazlalığın neredeyse tamamı turuncuydu: Opus işçileri. İşçilere iyi bir model ve hiç kural vermemiştim; onlar da kuralsız iyi bir model gibi davrandılar. O hafta medyan Opus işçi koşusu 176 turdu. Birkaçı tam backend test paketini çalıştırdı; bu, kendisinden sonraki her turda yeniden gönderilen bir bağlama yaklaşık 100 KB çıktı koyar. 14 Eylül’de, işleri çoktan sıkılaştırmaya başlamışken altı işçilik bir oturum, yaklaşık altı bin satır diff üretmek için 1.585 turda hâlâ 245M girdi token’ı yaktı. Prompt önbellekleme tüm bu süre boyunca %91,6 isabet oranıyla çalışıyordu. Fatura hacimdi, fiyatlandırma değil.
İşçi şeridi kuralların nereye oturduğunu gösteriyor. İşin çoğunu üçü yaptı ve bunları brifinge değil ajan tanımlarına yazdım, böylece hatırlasam da hatırlamasam da geçerli oluyorlar:
- Bir işçi asla tam test paketi çalıştırmaz. Brifinginin adını verdiği test dosyalarını çalıştırır. Kapıları mimar çalıştırır.
maxTurns, ajan tanımında sınırlandırılmıştır: Sonnet için 140, Opus için 160. 250 tur gerektiren bir dilim yanlış brifinglenmiştir.- Bir dilim yaklaşık on iki dosyanın altında, brifing ise yaklaşık 8 KB’ın altında kalır. Brifing de her turda yeniden gönderilir.
31 Ağustos haftasına gelindiğinde medyan işçi koşusu 57 tur ve 0,8M ağırlıklı token’dı. 14 Eylül’den, yani varsayılan rotayı Sonnet’e taşıdığımdan itibaren 40 tur ve 0,6M oldu ve o günden beri hiçbir işçi tam paket çalıştırmadı.
Prompt başına toplam da bunu izledi: son dört hafta boyunca 711k, 425k, 684k, 483k; düz oturumlar ise 505k, 425k, 318k, 431k. Mimar oturumları artık yaklaşık olarak düz oturumlar kadar tutuyor. Dört haftanın ikisinde biraz daha fazla, birinde biraz daha az. Bunun karşılığında kazandıkları şey sonraki iki grafik.
Bültenimize katılın
En son ipuçlarını, trendleri ve teklifleri ücretsiz alın.
Ana model yazmayı bıraktı
Değiştirmek için yola çıktığım sayı buydu ve değişti. Düz oturumlarda ana model 3.081 prompt boyunca kaynak dosyalar üzerinde 244 Edit veya Write çağrısı yaptı. Mimar oturumlarında 1.467 prompt boyunca 6 tane yaptı. Bu 6’nın hepsi hesabını verebildiğim küçük düzenleme istisnaları.
Bu arada işçiler üretkendi. 85 işçi koşusu 2.510 kaynak dosya düzenlemesi yaptı. Ana döngü ve işçiler birlikte sayıldığında, bir mimar oturumu 1.467 prompttan 2.516 kod düzenlemesi üretti; düz oturumlar ise 3.081 prompttan 943 üretti. Kod düzenlemesi başına bir mimar oturumu toplamda 403k, Opus ailesi modelde ise 330k ağırlıklı token harcadı. Bir düz oturum 1.410k ve 1.324k harcadı. Bu karşılaştırmada dikkatli olmak istiyorum, çünkü iki kitle aynı iş değil: bir oturum kod devrettiği için mimar olarak sınıflandırılır, yani mimar oturumları yapı itibarıyla kod ağırlıklıdır; düz oturumlar ise hiçbir şey düzenlemeyen araştırma, inceleme ve hata ayıklamayı içerir. Bunu “desen token başına çok kod yazdırıyor” diye okuyun, “dört kat verimlilik” iddiası olarak değil.
Daha temiz iddia model dağılımı. 14 Eylül’den bu yana bir mimar oturumundaki bir prompt ana döngüde 364k, Sonnet işçilerinde 205k ve Opus işçilerinde 80k ağırlıklı token’a mal oluyor. Opus işçilerinin tüm işçi token’larındaki payı Ağustos’ta %100’ken 21 Eylül haftasında yaklaşık %4 oldu. Bir Max planında bu, uygulama işinin neredeyse tamamı için ortak haftalık limitin Opus’un değil Sonnet’in tarifesinden çekilmesi ve hiçbirinin Fable limitine dokunmaması demek.
İyileşmeyen iki şey var ve grafiklerin aksini ima etmesine izin vermektense bunu söylemeyi tercih ederim. Ana oturumun kendi bağlamı küçülmedi: mimar oturumları 100 prompt başına 8,7 kez sıkıştırma yaptı, düz oturumlarda bu 4,7; çünkü mimar brifing vermeden önce çok şey okuyor. Ve desen küçük görevlerde duvar saati açısından daha yavaş, çünkü bir işçinin başlaması ve raporu, sadece düzenlemeyi yaptığınızda ödemediğiniz dakikalardır. Küçük düzenleme istisnası var, çünkü becerinin ilk sürümünde böyle bir istisna yoktu ve iki satırlık bir değişiklik için 3 KB’lık bir brifing yazdığımı kendi gözlerimle gördüm.
DeepSeek sapması
İşçiler Sonnet olduğunda, bariz sonraki soru bunların illa bir Claude modeli olması gerekip gerekmediğiydi. 13-18 Eylül arasında işçiyi, ANTHROPIC_BASE_URL uyumlu bir uç noktaya ayarlanmış başsız bir Claude Code üzerinden DeepSeek V4.1 Flash’a yönlendirdim; önce OpenRouter üzerinden, sonra doğrudan. Aynı brifing biçimi, aynı rapor biçimi, aynı mimar. 2.732 çağrı, %88’i önbellek okuması olan 431M girdi token’ı, 1,7M çıktı token’ı.
22 Eylül’deki liste fiyatlarıyla bu trafik DeepSeek’te yoğun olmayan saatte yaklaşık 10 dolar, yoğun saatte 21 dolar, Sonnet API’sinde 202 dolar ve Opus API’sinde 505 dolar tutuyor. Token başına ödeseydim bu yazının manşeti bu olurdu ve bunu sürdürürdüm.
Ben token başına ödemiyorum ve bütün tartışma da bu. Bir Max aboneliği, haftalık limitin %30’unu da kullansam %100’ünü de kullansam ayda 100 dolar. İşçi trafiğini DeepSeek’e taşımak bu faturayı bir kuruş bile düşürmedi. Kapasitesi için zaten ödeme yaptığım bir planda kapasite kazanmak için üstüne haftada 10 ila 21 dolar arası ikinci bir fatura ekledi. “API’den ucuz” ile “ödediğimden ucuz"u karıştırmıştım ve ödediğiniz şey sabitse bunlar aynı şey değil. Bir abone için doğru karşılaştırma DeepSeek’i ikinci bir abonelikle kıyaslamaktır; orada ikinci bir Claude planı ya da Codex’li bir ChatGPT planı, orta düzeyde bir DeepSeek kullanımının bir ayıyla yaklaşık aynı tutara gelir ve kendi haftalık limiti, kendi modeli ve izlenecek ölçümü olmadan gelir.
Diğer yarısı da kaliteydi. Beş backend dilimi temiz döndü ve olduğu gibi commit edildi. Bir frontend dilimi dışa aktarılan bir sembolü kaldırdı ve onu tüketen her şeye dokunmadı, dolayısıyla ağaç derlenmedi ve sonraki bir dilimin bunu temizlemesi gerekti. Bu tam olarak bir şartnameyi uygulayan modelin yaptığı ve bir bileşenin şeklini kardeşlerinden çıkarsayan modelin yapmadığı hatadır; beceri artık bunu söylüyor: paylaşılan API yüzeyi değişiklikleri Sonnet’e gider ve işçi kuralı şöyle okunur: “aynı koşuda her tüketiciyi taşımadan dışa aktarılan bir sembolü asla kaldırma veya yeniden adlandırma”. DeepSeek Flash iyi bir uygulayıcıdır. Mimar deseni, brifingin tüketicileri eksik saydığını fark eden bir işçiye ihtiyaç duyar ve bir brifingin sağlayamayacağı tek şey budur.
Dolayısıyla bugünkü yönlendirme tablosunda iki satır var. Ezber işi, testleri karşılaması gereken ayrıntılı bir brifingle backend işi, mevcut bir tasarım dilbilgisini izleyen frontend işi ve paylaşılan bir API yüzeyindeki her değişiklik sonnet-implementer‘a gider. Zorluğu muhakemede olan işler opus-implementer‘a gider: bir async yarış durumu, doğruluğu brifingin sayamayacağı noktalara bağlı çok noktalı bir refaktör, tek bir testin kanıtlayamadığı bir backfill migrasyonu. Şekle göre yönlendirin, asla riske göre değil. Risk, diff’in ne kadar sert inceleneceğini ve bir insanın imzalayıp imzalamayacağını değiştirir. Kimin yazacağını asla değiştirmez.
İnceleme döngüsü; desenin kazandığı ya da kaybettiği yer burasıdır
Bir işçinin raporu bir iddiadır. Becerinin inceleme döngüsü kısadır ve her satırı yanmış olmaktan gelir:
- Raporu ve gerçek
git diff‘i okuyun. İşçinin alıntıladığı diffstat’ı gördüğünüzle çapraz kontrol edin. - İddia önemli olduğunda ana doğrulamayı kendiniz yeniden çalıştırın.
- Bir sorun mu buldunuz? Düzeltmeyi aynı işçiye gönderin. Bağlamı hâlâ onda ve kaldığı yerden devam eder. Elle düzeltmeyin, yeniden doğurmayın.
- İki başarısız düzeltme, modelin çok küçük olduğu değil brifingin eksik kaldığı anlamına gelir. Dilimleyin, eksik alıntıyı Context’e koyun, yeniden çalıştırın. Daha büyük bir modele tırmanmayın, çünkü o aynı yanlış anlamayı daha akıcı biçimde uygular.
- Hiçbir şeyi kabul etmeden önce kapsamı belirlenmiş kapıları çalıştırın: dokunulan testler, dokunulan dosyalardaki linter, deponun taşıdığı her ne sözleşme betiği varsa.
Transkriptlerde işçi koşusu başına yaklaşık bir düzeltme gönderdim, 85 koşuda 52, ve 7 Opus koşusu 160 turluk sınırına dayandı; hepsi artık böleceğim bir dilimdeydi. İzlediğim iki sayı bunlar. Koşu başına düzeltmeler artarsa brifinglerim tembelleşiyor demektir. İşçiler sınıra dayanırsa dilimlerim çok büyük demektir.
Bundan çıkarılacak ders
Token başına ödüyorsanız: pahalı modeli kararlara ve incelemeye koyun, ucuzunu uygulamaya koyun ve hangi ucuzunu seçeceğinize karar vermeden önce işçi trafiğinizi liste fiyatından hesaplayın. Dört çubuklu grafik tartışmanın kendisi.
Bir abonelik ödüyorsanız: desen token sayınızı azaltmaz. Uygulama token’larını ortak haftalık limiti en yavaş çeken modele taşır, Fable limitini yalnızca Fable’ın yapması gereken işe saklar ve en pahalı modelinizin turlarını yazmaya harcamasını durdurur. Zaten satın aldığınız kapasiteyi “kurtarmak” için yanına ölçümlü bir API eklemeyin. İşçi kapasiteniz tükenirse ikinci bir abonelik alın.
Her iki durumda da işe yaramasını sağlayan kurallar sıkıcı olanlardı. İşçide tam test paketi yok. Turları sınırlayın. Küçük dilimler, kısa brifingler. Aynı işçiyi bir kez düzeltin, sonra brifingi düzeltin.
Beceri, üç ajan tanımı ve koruma kancası MIT lisansıyla github.com/LivinTribunal/architect-skill adresinde. İşçiye, indiği depoya uyan kod yazmayı söyleyen eşlik eden beceri grain-skill ve onunla ilgili yazı damar boyunca kod .
Yöntem
Yazının anlattığı her şey github.com/LivinTribunal/architect-skill adresinde: becerinin kendisi, brifing şablonu, yönlendirme tablosu, tur sınırları ve bağlam kurallarıyla üç uygulayıcı ajan tanımı ve koruma kancası. Kurun ve aşağıdaki rakamların çıktığı kuruluma sahip olun.
Oturumlar, 19 Ağustos - 22 Eylül 2026 tarihleri arasındaki Claude Code JSONL transkriptleridir; entrypoint cli, üç veya daha fazla kullanıcı promptu. Bir oturum, opus-implementer, opus-implementer-xhigh veya sonnet-implementer başlattıysa, bir ds-slice işçisi çalıştırdıysa, mimar becerisini çağırdıysa ya da genel amaçlı bir ajana uygulama brifingi içeren bir mesaj gönderdiyse mimar olarak sınıflandırılır; adlandırılmış ajanlar ortaya çıkmadan önce ilk haftalar böyle işliyordu. İşçi koşuları, her oturumun dizini altındaki alt ajan transkriptleridir. Kullanım, istek kimliğine göre tekilleştirilir ve şöyle ağırlıklandırılır: taze girdi 1, beş dakikalık önbellek yazması 1,25, bir saatlik önbellek yazması 2, önbellek okuması 0,1. “Kod düzenlemesi”, markdown ve ~/.claude altındaki her şey hariç, bir .py, .ts, .tsx, .js, .sql veya benzeri kaynak dosya üzerinde yapılan bir Edit ya da Write çağrısıdır. DeepSeek fiyatlandırması, 22 Eylül 2026 tarihli yerel liste fiyatıdır; yoğun olmayan ve yoğun saatler, önbellek okumaları önbellek isabet oranından, önbellek yazmaları taze girdi olarak fiyatlandırılır; Claude API fiyatları, önbellek okumaları girdinin onda biri olacak şekilde yayımlanmış Opus 5 ve Sonnet 5 liste fiyatlarıdır. 21 Eylül haftası iki günlük veridir.
