Arhitectul nu pune cărămizi: Împărțirea codării AI între modele scumpe și ieftine

Publicat la Jul 20, 2026 de Štefan Moravík.
AI Agents AI Development Claude Code Cost Optimization
Pe această pagină 15 min citire
  1. 1Partea 1 — Capcana și principiul
  2. 2Cum funcționează pattern-ul fable-architect
  3. 3Ce am măsurat
  4. 4Partea 2 — Chitanțele
  5. 5Al doilea canal: tracker-ul de probleme ca magistrală de delegare
  6. 6Ce ne-au învățat datele mai largi
  7. 7Actualizare — scara s-a mișcat sub noi
  8. 8Partea 3 — Încotro mergem, deliberat
  9. 9Ce poți face de luni

Acum câteva zile, Anthropic a făcut din Fable o parte permanentă a planurilor Max. Momentul spune totul: s-a întâmplat imediat după ce OpenAI a lansat GPT-5.6 Sol și — mai important — imediat după ce Kimi K3 și-a deschis greutățile. A fost nevoie de un model open-source pentru a forța cel mai mare laborator AI să își facă un reality check și să pună capăt zgomotului de marketing din jurul flagship-ului său. Numai asta merită un toast din partea oricui plătește aceste facturi.

Dar „inclus în abonamentul tău" nu este același lucru cu „ieftin" și cu siguranță nu este același lucru cu „ieftin pentru totdeauna". De aceea, cât timp Fable era încă taxat la consum, ne-am reconstruit fluxul de lucru astfel încât modelul scump este blocat mecanic de la a scrie cod. Gândește, planifică și verifică. Modelele mai ieftine tastează. Acest articol arată cum funcționează și ce a rezultat efectiv din fiecare transcript pe care îl avem — 606 sesiuni reale care acoperă un monorepo SaaS de producție, o aplicație de operare a dronelor, un site de marketing și agenții CI care le deservesc.

Partea 1 — Capcana și principiul

Iată poziția noastră de pornire, onestă: nu mai putem opera fără modele de frontieră. Nimeni din echipă nu ar putea susține rezultatul actual fără ele — iar această dependență este exact pârghia pe care o dețin marile laboratoare. În lectura noastră, abonamentele AI de astăzi oferă mult mai mult calcul decât costă; sunt prețuri de cucerire de piață, iar prețurile de cucerire de piață se termină. Când se vor termina, cine și-a construit cultura de inginerie în jurul ideii de „tokeni de frontieră nelimitați" va plăti oricât i se cere.

Există două apărări. Prima este menținerea unei ieșiri credibile: modele deschise precum DeepSeek și Kimi sunt cele care au forțat corecția de preț din această săptămână și rămân o pârghie doar dacă ne păstrăm efectiv fluxurile de lucru portabile către ele. A doua este disciplina de flux de lucru: cheltuiește tokeni de frontieră doar acolo unde nimic mai ieftin nu funcționează. Acest articol este despre a doua — pentru că este cea cu care poți începe de luni.

Principiul este suficient de vechi încât să aibă o clădire numită după el: arhitectul nu pune cărămizi. Avantajul unui model de frontieră față de unul de gamă medie este enorm în design, descompunere și verificare — și aproape zero când trebuie să tastezi o redenumire în patruzeci de fișiere. Așa că împarte rolurile. Scara de prețuri spune același lucru în dolari:

Prețuri de listă pe milion de tokeni de output: Fable 50 de dolari, Opus 25, Sonnet 15, Haiku 5

Cum funcționează pattern-ul fable-architect

Abilitatea fable-architect este un fișier markdown de ~100 de linii plus un hook de shell, încărcat ori de câte ori o sesiune Claude Code rulează pe modelul de frontieră. Ea impune o împărțire a muncii:

  • Arhitectul face: interoghează cerința, explorează baza de cod, ia fiecare decizie de design — abordare, flux de date, denumiri, semnături, cazuri limită — descompune munca în felii independente, verifică diff-urile returnate, rulează validarea și scrie tot textul narativ (planuri, brief-uri, descrieri de PR, mesaje de commit).
  • Arhitectul nu face niciodată: să scrie sau să editeze un fișier sursă. Fără cod în chat dincolo de semnături scurte în interiorul unui brief.
Diagramă a buclei fable-architect: arhitectul explorează și decide, scrie un brief pe felie, subagenții implementatori returnează diff-uri, arhitectul verifică; un hook de pază blochează arhitectul să editeze cod direct

Trei lucruri fac asta să funcționeze în practică, nu doar pe un slide.

1. Brief-ul este interfața

Fiecare felie primește un singur brief de implementare. Implementatorul pornește cu o fereastră de context nouă — orice nu se află în brief trebuie redescoperit sau ghicit. Această constrângere este un avantaj: îl obligă pe arhitect să termine de decis înainte de a delega. Un brief conține decizii, nu opțiuni.

## 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

Două dintre acele linii sunt mai noi decât restul și există pentru că nivelul implementatorului s-a schimbat sub noi — vezi actualizarea de mai jos.

2. Aplicare, nu impresii

Un hook de pază PreToolUse supraveghează sesiunea: dacă arhitectul încearcă să editeze un fișier care nu este text narativ, se declanșează o solicitare de permisiune. Aprobarea solicitării este excepția documentată pentru editările triviale (o greșeală de tipar, o actualizare de versiune — cazuri în care costul delegării depășește cel al tastării). Fricțiunea este politica. Fără hook, „modelul scump nu ar trebui să scrie cod" rezistă exact până la primul termen limită.

3. Bucla de verificare închide decalajul de calitate

Arhitectul citește raportul agentului și diff-ul real — neîncrezându-se în niciunul singur — și rulează din nou comenzile cheie de verificare atunci când afirmația contează. A găsit o problemă? Corecția se întoarce la același agent, care își păstrează încă întregul context de lucru. Fără reparat manual, fără repornire de la zero.

Reține că aceasta este verificarea arhitectului și rămâne. Ce am început să eliminăm este verificarea pe care o scriam în brief-uri — instrucțiuni care îi spuneau implementatorului să se verifice singur. Modelele mai noi de implementare fac asta fără să fie rugate, iar dacă le spui din nou să o facă, cumperi o a doua trecere pe care ai plătit-o deja.

Logo FlowHunt

Pregătit să îți dezvolți afacerea?

Începe perioada de probă gratuită astăzi și vezi rezultate în câteva zile.

Ce am măsurat

Pentru a verifica dacă acesta este un mecanism economic real sau doar un ritual plăcut, am extras datele din fiecare transcript Claude Code din proiectele noastre, eliminând duplicatele de cereri API și prețuind fiecare token la tarifele de listă actuale. Trei ipoteze, înregistrate înainte de a ne uita la numerele pe sesiune:

  • H1 — Implementatorii fac tastarea. Dacă este adevărat, subagenții implementatori ar trebui să producă mai mulți tokeni de output decât bucla principală a arhitectului în sesiunile delegate.
  • H2 — Delegarea este mai ieftină. Dacă este adevărat, reprețuirea muncii implementatorilor la tarifele modelului arhitect ar trebui să iasă semnificativ mai scumpă decât ce am plătit efectiv.
  • H3 — Calitatea se menține. Cea grea: codul delegat nu ar trebui să necesite mai multă reluare a muncii decât codul tastat de arhitect.

Reguli de bază. O cerere API se întinde pe multe linii de transcript care repetă același obiect de utilizare — am grupat după ID-ul cererii, am numărat tokenii de input și de cache o dată pe cerere și am luat instantaneul maxim de output (însumarea naivă pe linii supraestimează de 2–3×). Costurile folosesc prețurile de listă actuale Anthropic — Fable $10/$50, Opus $5/$25, Sonnet $3/$15 pe milion de tokeni de input/output — cu citirile din cache la 10% din prețul input-ului și scrierile în cache la tarifele lor pe TTL. 31 din 354 de sesiuni interactive-store se califică drept sesiuni fable-architect sub un clasificator conservator; cifrele arată cele mai scumpe opt. Raportăm rapoarte și procente, nu cheltuiala noastră absolută.

Partea 2 — Chitanțele

Grafic cu bare grupate ale tokenilor de output pe sesiune: subagenții implementatori produc mai mult decât bucla principală a arhitectului în majoritatea sesiunilor de top

H1 — Mixt… a spus prima contabilitate. În cele mai mari sesiuni de delegare, ipoteza se confirmă decisiv — până la 2,3× mai mult output de la implementatori decât de la arhitect. Dar în toate cele 31 de sesiuni fable-architect, arhitectul a produs totuși mai mult decât implementatorii, 3,59M față de 3,15M tokeni. Parțial este corect — output-ul arhitectului include toate planurile, brief-urile și textul de verificare, ceea ce este exact treaba lui — iar parțial părea vorba de sesiuni care delegau o singură felie și păstrau restul. Apoi ne-am amintit că redesign-ul site-ului nostru nu păruse deloc încărcat spre arhitect și am plecat în căutarea tokenilor pe care contabilitatea subagenților nu îi vedea.

Al doilea canal: tracker-ul de probleme ca magistrală de delegare

Contabilitatea subagenților are un punct orb: vede doar delegarea care se întâmplă în interiorul unei sesiuni. Sesiunea de redesign al site-ului — cea mai mare linie din graficul de mai sus — s-a dovedit a fi cu totul altceva: o singură sesiune de buclă a arhitectului care a rulat 107 ore continuu (292 de treziri programate), a împărțit redesign-ul în issue-uri GitHub, le-a etichetat pentru pipeline-ul nostru CI și apoi a supervizat: interogând rulările, verificând pull request-urile pipeline-ului, deschizând issue-uri de continuare pe măsură ce QA scotea la iveală bug-uri.

Tastarea s-a întâmplat într-un loc în care analiza noastră pe sesiuni nici nu se uitase: o flotă separată de runneri self-hosted, unde etapele pipeline-ului — plan → implementare → evaluarea decalajelor → verificare — au rulat ca 252 de sesiuni Opus independente pe parcursul a 4,5 zile, atingând 48 de issue-uri și PR-uri distincte.

Cronologie: o singură sesiune de buclă a arhitectului se întinde pe patru zile și jumătate; dedesubt, barele zilnice arată sesiunile pipeline-ului de issue-uri Opus pe care le-a expediat

H1, revizuit — Confirmat la scara proiectului. Numără ambele canale și imaginea se inversează: pipeline-ul a tastat de 10× mai mulți tokeni de output decât bucla arhitectului care l-a expediat (9,07M față de 877k), toți la tarife Opus. Rularea acelui val de implementare pe modelul arhitectului ar fi costat de 2,1× mai mult — pe un singur redesign, într-o singură săptămână, înainte de a număra subagenții din sesiune. Un issue este doar un brief cu granulație mai grosieră: aceeași interfață, aceeași economie, un nivel mai sus.

Grafic cu bare al primei de cost pe sesiune dacă modelul arhitect ar fi tastat tokenii implementatorilor: de la 2 la 54 la sută

H2 — Confirmat, cu o nuanță. Reprețuirea volumelor exacte de tokeni ale implementatorilor la tarifele modelului arhitect face fiecare sesiune mai scumpă — de la +2% la +54%, 17% în medie la primele opt. Bani reali, dar mai puțin decât sugerează decalajul de 2× al prețului de output. Nuanța: output-ul nu este locul unde se duc banii. În cea mai mare sesiune, citirile din cache ale arhitectului au costat de aproximativ 13× mai mult decât tot ce a tastat — cheltuiala dominantă este modelul scump care ține și recitește un context mare de orchestrare, nu tastarea. Delegarea plafonează factura de output; următoarea pârghie este menținerea contextului arhitectului suplu.

H3 — Nu a fost măsurat aici. Contabilitatea tokenilor nu poate vedea calitatea codului. Ce putem spune observațional: bucla de verificare este esențială — rapoartele și diff-urile se contrazic destul de des încât citirea ambelor este obligatorie — iar corecțiile trimise înapoi către un agent cu context cald converg repede. Dacă replici asta și măsori corect reluarea muncii, vrem să vedem rezultatul, mai ales dacă ne contrazice.

Ce ne-au învățat datele mai largi

  • Adoptarea este un gradient, nu un întrerupător. Pe aplicația de operare a dronelor — mai mică, cu mișcare mai rapidă — 18% din sesiuni rulează pattern-ul fable-architect; pe monorepo-ul SaaS mai vechi este 9%. Proiectul care a delegat cel mai agresiv a făcut-o la ambele granularități simultan: brief-uri de implementare în sesiune și 252 de sesiuni de pipeline expediate prin tracker-ul de issue-uri.
  • Flota CI nu rulează abilitatea — pentru că ea este implementatorul. Sesiunile noastre de runner automatizat nu creează niciodată un subagent implementator, iar la început asta părea neadoptare. Prompturile spun altfel: fiecare este o etapă de pipeline — verificare, revizuire, evaluarea decalajelor — și aproximativ șase din zece lucrează pe un issue sau PR specific. La scara proiectului, runnerii pipeline-ului sunt nivelul implementator.
  • Cel mai ieftin nivel nu a avut încă prima zi de muncă. Toate cele 78+ de rulări de implementare au fost de clasă Opus; nivelul de editare mecanică Sonnet a fost adăugat doar recent și nu a fost invocat. Orice economii ar măsura acest lucru, ele sunt un prag minim.

Interfața este esența: brief la intrare, diff la ieșire — issue la intrare, PR la ieșire. În ziua în care sosește scumpirea, schimbi zidarul, nu procesul.

Dezvăluire completă. Modelele au fost verificate din șiruri de transcript, nu presupuse. Ne-am corectat de două ori (o supraestimare a tokenilor pe linie, apoi un tabel de prețuri provizoriu). Contrafactualul presupune că arhitectul ar fi cheltuit aceleași volume de tokeni ca implementatorii — marjele de eroare merg în ambele direcții. Sesiunile de pipeline se află într-un depozit de transcripturi pe care primele noastre două treceri de extragere a datelor nu l-au inclus; o graniță contabilă ne-a ascuns un canal de delegare de 9M tokeni, iar al tău probabil are unul la fel. Proiectele unui singur inginer, în mare parte muncă de revizuire și corectare și dezvoltare de funcționalități — nu un benchmark controlat. Corpusul se închide, de asemenea, înainte de lansarea Opus 5: fiecare cifră de mai sus este Fable-ca-arhitect peste implementatori de clasă Opus 4. Prețurile treptelor nu s-au mișcat când a apărut Opus 5, așa că rapoartele măsurate rămân valabile — dar vezi secțiunea următoare pentru ce s-a mișcat.

Actualizare — scara s-a mișcat sub noi

Opus 5 a apărut după ce aceste măsurători s-au încheiat și nimic din scara de prețuri nu s-a schimbat: Opus este încă $5/$25 pe milion de tokeni de input/output, Fable este încă $10/$50, iar graficul de mai sus este încă corect. Ce s-a schimbat este capacitatea la fiecare treaptă. Anthropic poziționează Opus 5 ca un salt pe raționament profund și muncă agentică pe orizont lung — adică exact pe munca din care este făcut rolul de arhitect, la jumătate din prețul nivelului de arhitect.

Asta indică direct spre propria noastră nuanță de la H2. Dacă costul dominant al arhitectului sunt citirile din cache, iar citirile din cache se facturează la 10% din prețul input-ului, atunci un arhitect care rulează pe Opus 5 își recitește contextul de orchestrare la $0,50 pe milion de tokeni în loc de $1,00 cât costă Fable. Elementul de cost care costa de 13× tot ce a tastat arhitectul se înjumătățește. Nu am măsurat acest lucru — este aritmetică sub aceeași presupunere de volume egale de tokeni pe care am semnalat-o pentru contrafactualul de 2,1× și este următorul lucru pe care intenționăm să îl testăm. Dacă se confirmă, întrebarea interesantă încetează să mai fie ce tipuri de model și devine dacă arhitectul are nevoie de treapta de top.

Trei lucruri legate de noul nivel de implementare schimbă pattern-ul în sine, nu doar prețul lui:

  • Se întinde cu ușurință spre subagenți — invers față de predecesorul său, care trebuia convins să delege. Un implementator care creează în tăcere propriii implementatori multiplică factura fără ca nimeni să observe. De aici linia Delegation: din brief: o felie declară acum dacă poate ramifica și cât de larg.
  • Își verifică singur munca fără să fie rugat. Instrucțiunile de verificare scrise pentru modele mai vechi cumpără acum o a doua trecere redundantă, așa că ies din brief-uri. Bucla de verificare a arhitectului rămâne neatinsă.
  • Extinde scopul. Out of scope: încetează să mai fie un text standard și devine linia care menține o felie o felie.

Iar treapta pe care nu am folosit-o niciodată a devenit mai ascuțită cât timp nu ne uitam: Sonnet 5 ajunge aproape de calitatea Opus la munca de codare, la $3/$15, cu preț introductiv sub asta până la sfârșitul lunii august. „Orice economii ar măsura acest lucru, ele sunt un prag minim" era o precauție când am scris-o. Acum sună ca o subestimare.

Partea 3 — Încotro mergem, deliberat

Ne îndreptăm, intenționat, spre o împărțire în care credem că fiecare echipă de inginerie va fi în cele din urmă forțată: modele de frontieră scumpe doar pentru brainstorming, arhitectură și verificare; modele tot mai ieftine pentru programarea în sine. Astăzi implementatorii noștri sunt de clasă Opus. Nimic din fluxul de lucru nu se schimbă când devin de clasă Sonnet, DeepSeek sau Kimi — interfața este agnostică față de model prin construcție. Aceasta este întreaga valoare strategică: în ziua în care subvenția se termină și factura se dublează, echipele cu această disciplină schimbă o linie de configurare. Echipele fără ea își renegociază întreaga structură de costuri sub presiune.

Fable-architect este un pas mic — adoptarea este parțială și cel mai ieftin nivel nu a văzut încă prima rulare. Dar este pasul care construiește mușchiul: scrierea de brief-uri care specifică complet o felie, verificarea unor diff-uri pe care nu le-ai tastat, tratarea atenției modelului scump ca pe un buget. Iar valul de redesign arată unde duce mușchiul: odată ce brief-urile funcționează, funcționează și issue-urile, iar modelul scump nu mai participă deloc la implementare.

Ce poți face de luni

  1. Împarte rolurile în scheletul tău de agenți. O regulă la nivel de sesiune: modelul de frontieră planifică și verifică; delegă toate editările de fișiere unui agent implementator mai ieftin. În Claude Code, asta înseamnă o abilitate plus definiții de subagenți — o după-amiază de configurare.
  2. Fă granița mecanică. Adaugă un hook înainte de editare care contestă scrierile de fișiere ale modelului scump. O regulă care nu costă nimic dacă o încalci va fi încălcată până vineri.
  3. Scrie brief-uri cu un șablon fix. Obiectiv, context, fișiere, design, constrângeri, în afara scopului, buget de delegare, verificare. Șablonul este disciplina — iar bugetul de delegare este cel care împiedică un implementator să angajeze în tăcere propriii lui implementatori.
  4. Verifică atât raportul, cât și diff-ul. Nu te încrede niciodată în niciunul singur; rulează din nou comenzile de verificare care contează.
  5. Măsoară-ți propria împărțire. Transcripturile tale conțin deja datele — grupează după cerere, pune prețuri după model și vezi cine tastează de fapt. Ale noastre ne-au arătat un nivel ieftin nefolosit și un canal de delegare de 9M tokeni despre care nu știam.
  6. Lărgește interfața de la brief-uri la issue-uri. Un brief delegă o oră de muncă; un issue delegă o zi din ea. Odată ce issue-urile tale poartă criterii de acceptare pe care un pipeline le poate folosi, modelul scump poate depune munca în tracker și superviza, în loc să stea în buclă pentru fiecare felie.
  7. Ține o ieșire caldă. Rulează un model ieftin sau deschis ca implementator pentru o felie cu risc scăzut pe săptămână. Portabilitatea pe care nu o exersezi niciodată este portabilitate pe care nu o ai.
  8. Reprețuiește arhitectul, nu doar zidarul. Fiecare lansare de model mișcă treptele fără să miște scara. Dacă cea mai mare parte a cheltuielii tale de arhitect este context, nu tastare, un nivel de arhitect mai ieftin valorează mai mult decât un nivel de implementator mai ieftin — verifică pe care dintre ele spun transcripturile tale că îl cumperi.

Laboratoarele ne vor spune în continuare că modelele lor de top merită orice preț și — exasperant — pentru munca de judecată au în mare parte dreptate. Mișcarea nu este să te abții. Este să nu mai plătești prețuri de frontieră pentru bucle for.

Întrebări frecvente

Ștefan este un inginer AI și software care construiește FlowHunt. Dincolo de produs, el proiectează fluxuri de lucru agentic de inginerie software pentru dezvoltatori care reduc costurile de dezvoltare și ridică calitatea codului.

Štefan Moravík
Štefan Moravík
Inginer AI și Software

Orchestrați echipe AI multi-model cu FlowHunt

Construiți fluxuri de lucru cu agenți AI care rutează fiecare sarcină către modelul potrivit — raționament de frontieră acolo unde contează, modele eficiente pentru munca de volum.