Mimar Tuğla Örmez: Yapay Zeka Kodlamayı Pahalı ve Ucuz Modeller Arasında Bölmek

Jul 20, 2026 tarihinde Štefan Moravík tarafından yayınlandı.
AI Agents AI Development Claude Code Cost Optimization
Bu sayfada 12 dakika okuma
  1. 1Bölüm 1 — Tuzak ve ilke
  2. 2fable-architect deseni nasıl çalışır
  3. 3Ne ölçtük
  4. 4Bölüm 2 — Makbuzlar
  5. 5İkinci kanal: delegasyon veriyolu olarak issue takip sistemi
  6. 6Daha geniş verinin bize öğrettikleri
  7. 7Güncelleme — merdiven altımızdan kaydı
  8. 8Bölüm 3 — Bunun bilinçli olarak gittiği yer
  9. 9Pazartesi günü ne yapabilirsiniz

Birkaç gün önce Anthropic, Fable’ı Max planlarının kalıcı bir parçası haline getirdi. Zamanlama hikâyeyi anlatıyor: OpenAI GPT-5.6 Sol’u yayınladıktan hemen sonra ve — daha da önemlisi — Kimi K3 ağırlıklarını yayınladıktan hemen sonra geldi. En büyük yapay zeka laboratuvarını bir gerçeklik kontrolüne zorlayan ve amiral gemisi modeli etrafındaki pazarlama telaşını sona erdiren şey açık kaynak bir model oldu. Bu tek başına, bu faturaları ödeyen herkesin bir kadeh kaldırmasını hak ediyor.

Ama “aboneliğinize dahil” olması “ucuz” olmasıyla aynı şey değil ve kesinlikle “sonsuza kadar ucuz” olmasıyla da aynı şey değil. Bu yüzden, Fable hâlâ ölçümlendirilirken iş akışımızı, pahalı modelin kod yazmasının mekanik olarak engelleneceği şekilde yeniden kurguladık. O düşünür, planlar ve inceler. Daha ucuz modeller yazar. Bu yazı bunun nasıl çalıştığını ve elimizdeki her transkript üzerinden gerçekte neyi ölçtüğünü gösteriyor — üretim ortamındaki bir SaaS monorepo, bir drone operasyon uygulaması, bir pazarlama sitesi ve bunlara hizmet eden CI ajanlarına yayılan 606 gerçek oturum.

Bölüm 1 — Tuzak ve ilke

Dürüst başlangıç noktamız şu: artık sınır modelleri olmadan çalışamıyoruz. Ekipteki hiç kimse mevcut çıktıyı onlar olmadan sürdüremezdi — ve bu bağımlılık tam da büyük laboratuvarların elindeki kaldıraçtır. Bizim okumamıza göre bugünün AI abonelikleri, maliyetlerinden belirgin biçimde daha fazla hesaplama gücü sunuyor; bunlar pazar kapma fiyatları ve pazar kapma fiyatları bir gün sona erer. Sona erdiğinde, mühendislik kültürünü “sınırsız sınır token’ı” üzerine kuran kim varsa, istenen bedeli öder.

İki savunma var. Birincisi inandırıcı bir çıkış yolu tutmak: DeepSeek ve Kimi gibi açık modeller bu haftaki fiyat düzeltmesini zorlayan şeydi ve iş akışlarımızı onlara gerçekten taşınabilir tuttuğumuz sürece kaldıraç olmaya devam ederler. İkincisi iş akışı disiplini: sınır token’larını yalnızca daha ucuz hiçbir şeyin işe yaramadığı yerlerde harcamak. Bu yazı ikincisiyle ilgili — çünkü Pazartesi günü başlayabileceğiniz olan o.

İlke, kendi adına bir bina yapılacak kadar eski: mimar tuğla örmez. Bir sınır modelinin orta kademe bir modele karşı üstünlüğü tasarım, ayrıştırma ve incelemede muazzam — kırk dosyada bir yeniden adlandırmayı yazmaya gelince neredeyse sıfır. Öyleyse rolleri bölün. Fiyat merdiveni de aynı şeyi dolar cinsinden söylüyor:

Milyon token başına çıktı token liste fiyatları: Fable 50 dolar, Opus 25, Sonnet 15, Haiku 5

fable-architect deseni nasıl çalışır

fable-architect skill’i, yaklaşık 100 satırlık bir markdown dosyası artı bir shell kancasıdır ve bir Claude Code oturumu sınır modelinde çalıştığında yüklenir. Bir iş bölümünü zorunlu kılar:

  • Mimar şunları yapar: gereksinimi sorgular, kod tabanını keşfeder, her tasarım kararını verir — yaklaşım, veri akışı, isimler, imzalar, uç durumlar — işi bağımsız dilimlere ayırır, dönen diff’leri inceler, doğrulamayı çalıştırır ve tüm düzyazıyı yazar (planlar, brief’ler, PR gövdeleri, commit mesajları).
  • Mimar asla şunu yapmaz: bir kaynak dosyayı yazmak veya düzenlemek. Bir brief içindeki kısa imzalar dışında sohbette kod yok.
fable-architect döngüsünün akış diyagramı: mimar keşfeder ve karar verir, her dilim için bir brief yazar, uygulayıcı alt-ajanlar diff'leri döndürür, mimar inceler; bir koruma kancası mimarın doğrudan kod düzenlemesini engeller

Bunu bir slaytta değil pratikte işleten üç şey var.

1. Arayüz brief’tir

Her dilim bir uygulama brief’i alır. Uygulayıcı taze bir bağlam penceresiyle başlar — brief’te olmayan her şeyi ya yeniden keşfetmeli ya da tahmin etmelidir. Bu kısıt bir özelliktir: mimarı delege etmeden önce karar vermeyi bitirmeye zorlar. Bir brief kararlar içerir, seçenekler değil.

## Implementation brief: <slice>
Goal:         one sentence, observable outcome
Context:      what exploration already found — excerpts, the nearest
              pattern to mirror, line anchors, gotchas
Files:        paths to create/modify — this slice's exclusive ownership
Design:       the decided approach — data flow, names, signatures, edges
Constraints:  project rules that apply: style, layers, security
Out of scope: what not to touch, including files owned by other slices
Delegation:   may this slice spawn sub-implementers, and how many
Verify:       exact commands and expected outcome

Bu satırlardan ikisi diğerlerinden daha yeni ve bizim altımızda uygulayıcı kademesi değiştiği için var — aşağıdaki güncellemeye bakın.

2. Hisler değil, zorlama

Bir PreToolUse koruma kancası oturumu izler: mimar düzyazı olmayan bir dosyayı düzenlemeye çalışırsa bir izin istemi tetiklenir. İstemi onaylamak, önemsiz düzenlemeler için (bir yazım hatası, bir sürüm artırma — delegasyon ek yükünün yazmaktan daha pahalıya geldiği durumlar) belgelenmiş istisnadır. Sürtünme, politikanın kendisidir. Kanca olmadan “pahalı model kod yazmamalı” kuralı tam olarak ilk teslim tarihine kadar sürer.

3. İnceleme döngüsü kalite açığını kapatır

Mimar ajanın raporunu ve gerçek diff’i okur — ikisine de tek başına güvenmez — ve iddia önemli olduğunda kilit doğrulama komutlarını yeniden çalıştırır. Bir sorun mu buldu? Düzeltme, tam çalışma bağlamını hâlâ elinde tutan aynı ajana geri gider. Elle düzeltme yok, sıfırdan yeniden doğurma yok.

Bunun mimarın doğrulaması olduğunu ve öyle kaldığını not edin. Kaldırmaya başladığımız şey, eskiden brief’lere yazdığımız doğrulama — uygulayıcıya kendini iki kez kontrol etmesini söyleyen talimatlar. Yeni uygulayıcı modelleri bunu istem dışı yapıyor ve onlara tekrar yapmalarını söylemek, zaten ödediğiniz ikinci bir geçiş satın alıyor.

FlowHunt Logo

İş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.

Ne ölçtük

Bunun gerçek bir ekonomik mekanizma mı yoksa sadece hoş bir ritüel mi olduğunu kontrol etmek için projelerimizdeki her Claude Code transkriptini taradık, API isteklerini tekilleştirdik ve her token’ı güncel liste fiyatlarından fiyatlandırdık. Oturum başına sayılara bakmadan önce kaydedilmiş üç hipotez:

  • H1 — Yazma işini uygulayıcılar yapar. Bu doğruysa, delege edilmiş oturumlarda uygulayıcı alt-ajanlar mimarın ana döngüsünden daha fazla çıktı token’ı üretmelidir.
  • H2 — Delegasyon daha ucuzdur. Bu doğruysa, uygulayıcıların işini mimar modelinin fiyatlarıyla yeniden fiyatlandırmak, gerçekte ödediğimizden anlamlı biçimde daha pahalı çıkmalıdır.
  • H3 — Kalite korunur. Zor olan: delege edilen kod, mimarın yazdığı koddan daha fazla yeniden çalışma gerektirmemelidir.

Temel kurallar. Bir API isteği, aynı kullanım nesnesini tekrarlayan birçok transkript satırına yayılır — istek kimliğine göre grupladık, girdi ve cache token’larını istek başına bir kez saydık ve maksimum çıktı anlık görüntüsünü aldık (satır başına naif toplama 2–3 kat fazla sayar). Maliyetler güncel Anthropic liste fiyatlarını kullanır — Fable 10/50 $, Opus 5/25 $, Sonnet 3/15 $ (milyon girdi/çıktı token’ı başına) — cache okumaları girdi fiyatının %10’u, cache yazmaları kendi TTL oranları üzerinden. 354 etkileşimli-depo oturumundan 31’i, muhafazakâr bir sınıflandırıcı altında fable-architect oturumu olarak niteleniyor; rakamlar en pahalı sekizini gösteriyor. Mutlak harcamamızı değil, oranları ve yüzdeleri bildiriyoruz.

Bölüm 2 — Makbuzlar

Oturum başına çıktı token'larının gruplanmış çubuk grafiği: uygulayıcı alt-ajanlar en pahalı oturumların çoğunda mimarın ana döngüsünden daha fazla üretiyor

H1 — Karışık… dedi ilk muhasebe. En büyük delegasyon oturumlarında hipotez kesin biçimde tutuyor — mimar çıktısından 2,3 kata kadar daha fazla uygulayıcı çıktısı. Ama 31 fable-architect oturumunun tamamında mimar hâlâ uygulayıcılardan daha fazla üretti: 3,59M’ye karşı 3,15M token. Bu kısmen adil — mimarın çıktısı tüm planları, brief’leri ve inceleme düzyazısını içeriyor, ki bu tam olarak onun işi — kısmen de bir dilimi delege edip geri kalanını kendinde tutan oturumlar gibi görünüyordu. Sonra site yeniden tasarımımızın hiç de mimar-ağırlıklı hissettirmediğini hatırladık ve alt-ajan muhasebesinin göremediği token’ları aramaya gittik.

İkinci kanal: delegasyon veriyolu olarak issue takip sistemi

Alt-ajan muhasebesinin bir kör noktası var: yalnızca bir oturumun içinde gerçekleşen delegasyonu görür. Site yeniden tasarımı oturumu — yukarıdaki grafikteki en büyük satır — bambaşka bir şey çıktı: 107 saat boyunca kesintisiz çalışan (292 planlı uyanma) tek bir mimar döngüsü oturumu, yeniden tasarımı GitHub issue’larına böldü, onları CI hattımız için etiketledi ve sonra denetledi: çalıştırmaları yokladı, hattın pull request’lerini inceledi, QA hataları ortaya çıkardıkça takip issue’ları açtı.

Yazma işi, oturum başına madenciliğimizin hiç bakmadığı bir yerde gerçekleşti: hattın plan → uygula → boşluk değerlendirmesi → inceleme aşamalarının 4,5 gün boyunca 252 bağımsız Opus oturumu olarak yürütüldüğü, kendi kendine barındırılan ayrı bir runner filosu; 48 farklı issue ve PR’a dokunarak.

Zaman çizelgesi: tek bir mimar döngüsü oturumu dört buçuk güne yayılıyor; altında günlük çubuklar onun gönderdiği Opus issue-pipeline oturumlarını gösteriyor

H1, yeniden — Proje ölçeğinde doğrulandı. İki kanalı da sayın ve tablo tersine dönüyor: hat, onu gönderen mimar döngüsünden 10 kat daha fazla çıktı token’ı yazdı (9,07M’ye karşı 877k), hepsi Opus oranlarından. Bu uygulama dalgasını mimarın modelinde çalıştırmak 2,1 kat daha pahalıya mal olacaktı — tek bir yeniden tasarımda, tek bir haftada, oturum içi alt-ajanları saymadan önce. Bir issue yalnızca daha kaba tanecikli bir brieftir: aynı arayüz, aynı ekonomi, bir seviye yukarıda.

Mimar modeli uygulayıcı token'larını yazsaydı oluşacak oturum başına maliyet farkının çubuk grafiği: yüzde 2 ila 54

H2 — Doğrulandı, ama bir sürprizle. Uygulayıcıların tam token hacimlerini mimar modelinin oranlarından yeniden fiyatlandırmak her oturumu daha pahalı yapıyor — +%2’den +%54’e, en pahalı sekizinde %17. Gerçek para, ama 2× çıktı fiyatı farkının ima ettiğinden daha küçük. Sürpriz şu: para çıktıya gitmiyor. En büyük oturumda mimarın cache okumaları, yazdığı her şeyin yaklaşık 13 katına mal oldu — baskın harcama, pahalı modelin büyük bir orkestrasyon bağlamını tutması ve yeniden okuması, yazması değil. Delegasyon çıktı faturasını sınırlıyor; sıradaki kaldıraç mimarın bağlamını yalın tutmak.

H3 — Burada ölçülmedi. Token muhasebesi kod kalitesini göremez. Gözlemsel olarak söyleyebileceğimiz şu: inceleme döngüsü yük taşıyor — raporlar ve diff’ler yeterince sık çelişiyor ki ikisini de okumak vazgeçilmez — ve bağlamı sıcak bir ajana geri yönlendirilen düzeltmeler hızla yakınsıyor. Bunu tekrarlar ve yeniden çalışmayı düzgün ölçerseniz, görmek isteriz, özellikle de bizi çürütürse.

Daha geniş verinin bize öğrettikleri

  • Benimseme bir anahtar değil, bir gradyandır. Daha küçük ve hızlı hareket eden drone-ops uygulamasında oturumların %18’i fable-architect desenini çalıştırıyor; daha eski SaaS monorepo’sunda bu oran %9. En sert şekilde delege eden proje, bunu aynı anda iki tanecik düzeyinde yaptı: oturum içi uygulayıcı brief’leri ve issue takip sistemi üzerinden gönderilen 252 pipeline oturumu.
  • CI filosu bu skill’i çalıştırmıyor — çünkü uygulayıcının kendisi o. Otomatik runner oturumlarımız hiçbir zaman bir uygulayıcı alt-ajan doğurmuyor ve ilk bakışta bu, benimsememe gibi okundu. Prompt’lar aksini söylüyor: her biri bir pipeline aşaması — doğrula, incele, boşluk değerlendirmesi — ve kabaca on oturumun altısı belirli bir issue veya PR üzerinde çalışıyor. Proje ölçeğinde, pipeline runner’ları uygulayıcı kademesinin ta kendisi.
  • En ucuz kademe henüz işteki ilk gününü yaşamadı. 78+ uygulayıcı çalıştırmasının tamamı Opus sınıfıydı; Sonnet mekanik-düzenleme kademesi yakın zamanda eklendi ve hiç çağrılmadı. Bu ölçüm ne kadar tasarruf gösteriyorsa, o bir taban değerdir.

Önemli olan arayüz: brief girer, diff çıkar — issue girer, PR çıkar. Zam gelip oturduğu gün, süreci değil, duvar ustasını değiştirirsiniz.

Tam açıklama. Modeller varsayılmadı, transkript dizelerinden doğrulandı. Kendimizi iki kez düzelttik (satır başına bir token fazla sayımı, ardından bir yer tutucu fiyat tablosu). Karşı-olgu, mimarın uygulayıcıların harcadığı aynı token hacimlerini harcayacağını varsayıyor — hata çubukları iki yöne de uzanıyor. Pipeline oturumları, ilk iki madencilik geçişimizin kapsamına almadığı bir transkript deposunda yaşıyor; bir muhasebe sınırı bizden 9M token’lık bir delegasyon kanalını sakladı ve sizinkinde de muhtemelen bir tane var. Tek bir mühendisin projeleri, çoğunlukla incele-ve-düzelt ile özellik işleri — kontrollü bir kıyaslama değil. Korpus ayrıca Opus 5 yayınlanmadan önce kapanıyor: yukarıdaki her rakam, Opus-4 sınıfı uygulayıcılar üzerinde mimar olarak Fable’dır. Opus 5 geldiğinde kademe fiyatları değişmedi, dolayısıyla ölçülen oranlar geçerli — ama neyin değiştiği için bir sonraki bölüme bakın.

Güncelleme — merdiven altımızdan kaydı

Opus 5, bu ölçümler kapandıktan sonra yayınlandı ve fiyat merdiveninde hiçbir şey değişmedi: Opus hâlâ milyon girdi/çıktı token’ı başına 5/25 $, Fable hâlâ 10/50 $ ve yukarıdaki grafik hâlâ doğru. Değişen, her basamaktaki yetenek. Anthropic, Opus 5’i derin muhakeme ve uzun ufuklu ajanik işlerde bir sıçrama olarak konumlandırıyor — yani tam olarak mimar rolünün yapıldığı işte, mimar kademesinin yarı fiyatına.

Bu doğrudan kendi H2 sürprizimize işaret ediyor. Baskın mimar maliyeti cache okumalarıysa ve cache okumaları girdi fiyatının %10’u üzerinden faturalanıyorsa, Opus 5 üzerinde çalışan bir mimar orkestrasyon bağlamını Fable’ın milyon token başına 1,00 $‘ı yerine 0,50 $‘dan yeniden okur. Mimarın yazdığı her şeyin 13 katına mal olan kalem yarıya iner. Bunu ölçmedik — 2,1× karşı-olgu için işaret ettiğimiz aynı eşit-token-hacmi varsayımı altında bu bir aritmetiktir ve test etmeyi planladığımız sıradaki şeydir. Eğer bu geçerliyse, ilginç soru artık hangi model türleri olmaktan çıkıp mimarın en üst basamağa gerçekten ihtiyacı var mı sorusuna dönüşüyor.

Yeni uygulayıcı kademesiyle ilgili üç şey, yalnızca fiyatı değil desenin kendisini değiştiriyor:

  • Alt-ajanlara kolayca uzanıyor — delege etmeye zar zor ikna edilebilen selefinin tam tersi. Sessizce kendi uygulayıcılarını doğuran bir uygulayıcı, kimse bakmazken faturayı katlar. Brief’teki Delegation: satırı da bu yüzden var: bir dilim artık dağılıp dağılamayacağını ve ne kadar geniş dağılacağını belirtiyor.
  • Kendi işini istem dışı doğruluyor. Daha eski modeller için yazılmış doğrulama talimatları artık gereksiz bir ikinci geçiş satın alıyor, dolayısıyla brief’lerden çıkıyorlar. Mimarın inceleme döngüsü ise dokunulmadan kalıyor.
  • Kapsamı genişletiyor. Out of scope: artık basmakalıp olmaktan çıkıp bir dilimi dilim tutan satır haline geliyor.

Ve biz bakmazken hiç kullanmadığımız kademe keskinleşti: Sonnet 5, kodlama işlerinde Opus kalitesine yakın bir seviyeye 3/15 $‘dan geliyor; Ağustos sonuna kadar bunun altında bir tanıtım fiyatıyla. “Bu ölçüm ne kadar tasarruf gösteriyorsa, o bir taban” cümlesi yazdığımızda bir temkinli ifadeydi. Şimdi bir küçümseme gibi okunuyor.

Bölüm 3 — Bunun bilinçli olarak gittiği yer

Bilinçli olarak, her mühendislik ekibinin eninde sonunda zorlanacağını düşündüğümüz bir ayrışmaya doğru yöneliyoruz: pahalı sınır modelleri yalnızca beyin fırtınası, mimari ve inceleme için; giderek ucuzlayan modeller ise programlamanın kendisi için. Bugün uygulayıcılarımız Opus sınıfı. Sonnet sınıfı, DeepSeek sınıfı veya Kimi sınıfı olduklarında iş akışında hiçbir şey değişmiyor — arayüz tasarımı gereği modelden bağımsız. Bütün stratejik değer bu: sübvansiyonun bittiği ve faturanın ikiye katlandığı gün, bu disipline sahip ekipler tek bir config satırını değiştirir. Buna sahip olmayan ekipler ise tüm maliyet yapılarını baskı altında yeniden müzakere eder.

Fable-architect küçük bir adım — benimseme kısmi ve en ucuz kademe ilk çalıştırmasını görmedi. Ama kası inşa eden adım bu: bir dilimi tam olarak belirten brief’ler yazmak, kendi yazmadığınız diff’leri incelemek, pahalı modelin dikkatine bir bütçe gibi davranmak. Ve yeniden tasarım dalgası kasın nereye götürdüğünü gösteriyor: brief’ler işlediğinde issue’lar da işler ve pahalı model uygulamaya hiç katılmaz hale gelir.

Pazartesi günü ne yapabilirsiniz

  1. Ajan koşum takımınızda rolleri bölün. Tek bir oturum düzeyi kuralı: sınır model planlar ve inceler; tüm dosya düzenlemelerini daha ucuz bir uygulayıcı ajana delege edin. Claude Code’da bu, bir skill artı alt-ajan tanımlarıdır — bir öğleden sonra süren bir kurulum.
  2. Sınırı mekanik hale getirin. Pahalı modelin kendi dosya yazmalarına karşı çıkan bir düzenleme-öncesi kanca ekleyin. Bozulması hiçbir şeye mal olmayan bir kural, Cuma gününe kadar bozulur.
  3. Brief’leri sabit bir şablonla yazın. Hedef, bağlam, dosyalar, tasarım, kısıtlar, kapsam dışı, delegasyon bütçesi, doğrulama. Şablon disiplinin kendisidir — ve delegasyon bütçesi de bir uygulayıcının sessizce kendi alt-uygulayıcılarını işe almasını engelleyen şeydir.
  4. Hem raporu hem de diff’i inceleyin. Hiçbirine tek başına güvenmeyin; önemli olan doğrulama komutlarını yeniden çalıştırın.
  5. Kendi ayrışmanızı ölçün. Transkriptleriniz zaten veriyi içeriyor — isteğe göre gruplayın, modele göre fiyatlandırın ve gerçekte kimin yazdığını görün. Bizimkiler bize kullanılmayan bir ucuz kademe ve varlığından haberdar olmadığımız 9M token’lık bir delegasyon kanalı gösterdi.
  6. Arayüzü brief’lerden issue’lara doğru genişletin. Bir brief bir saatlik işi delege eder; bir issue bir günlük işi. Issue’larınız bir pipeline’ın üzerinde işlem yapabileceği kabul kriterleri taşımaya başladığında, pahalı model her dilim için döngüde oturmak yerine işi takip sistemine açıp denetleyebilir.
  7. Bir çıkışı sıcak tutun. Haftada bir düşük riskli dilim için uygulayıcı olarak ucuz veya açık bir model çalıştırın. Hiç kullanmadığınız taşınabilirlik, sahip olmadığınız taşınabilirliktir.
  8. Sadece duvar ustasını değil, mimarı da yeniden fiyatlandırın. Her model sürümü, merdiveni oynatmadan basamakları oynatır. Mimar harcamanızın çoğu yazmak yerine bağlamsa, daha ucuz bir mimar kademesi daha ucuz bir uygulayıcı kademesinden daha değerlidir — kendi transkriptlerinizin hangisini satın aldığınızı söylediğini kontrol edin.

Laboratuvarlar bize en iyi modellerinin her fiyata değer olduğunu söylemeye devam edecek ve — sinir bozucu biçimde — muhakeme işleri için çoğunlukla haklılar. Yapılacak şey vazgeçmek değil. Yapılacak şey, for döngüleri için sınır fiyatları ödemeyi bırakmak.

Sıkça sorulan sorular

Štefan, FlowHunt'ı geliştiren bir yapay zeka ve yazılım mühendisidir. Ürünün kendisinin ötesinde, geliştirme maliyetlerini düşürürken kod kalitesini artıran geliştiriciler için agentic yazılım mühendisliği iş akışları tasarlar.

Štefan Moravík
Štefan Moravík
Yapay Zeka & Yazılım Mühendisi

FlowHunt ile Çok Modelli AI Ekiplerini Orkestre Edin

Her görevi doğru modele yönlendiren AI ajan iş akışları kurun — önemli olduğu yerde sınır muhakemesi, hacim işleri için verimli modeller.