Arkitekten murer ikke selv: slik deler vi AI-koding mellom dyre og billige modeller

For noen dager siden gjorde Anthropic Fable til en permanent del av Max-abonnementene. Tidspunktet forteller historien: det skjedde rett etter at OpenAI lanserte GPT-5.6 Sol, og — enda mer relevant — rett etter at Kimi K3 slapp vektene sine. Det skulle en åpen kildekode-modell til for å tvinge det største AI-laboratoriet til å ta en realitetsorientering og sette slutt på markedsføringsoppstyret rundt flaggskipet sitt. Det alene fortjener en skål fra alle som betaler disse fakturaene.

Men “inkludert i abonnementet” er ikke det samme som “billig”, og det er definitivt ikke det samme som “billig for alltid”. Derfor bygde vi om arbeidsflyten vår mens Fable fortsatt var målt i forbruk, slik at den dyre modellen er mekanisk blokkert fra å skrive kode. Den tenker, planlegger og vurderer. Billigere modeller taster. Dette innlegget viser hvordan det fungerer, og hva det faktisk målte ut til på tvers av alle transkripsjonene vi har — 606 reelle økter som spenner over et produksjons-monorepo for SaaS, en droneoperasjons-app, et markedsføringsnettsted og CI-agentene som betjener dem.

Del 1 — Fellen, og prinsippet

Her er vårt ærlige utgangspunkt: vi kan ikke lenger drive uten frontier-modeller. Ingen på teamet kunne opprettholdt dagens produksjon uten dem — og den avhengigheten er nettopp forhandlingskortet de store laboratoriene holder. Slik vi leser det, leverer dagens AI-abonnementer markert mer datakraft enn de koster; de er priser fra et landkappløp, og landkappløp tar slutt. Når de tar slutt, betaler den som har bygget ingeniørkulturen sin rundt “ubegrensede frontier-tokens”, akkurat det som kreves.

Det finnes to forsvar. Det første er å holde en troverdig utvei åpen: åpne modeller som DeepSeek og Kimi er det som tvang fram ukens priskorreksjon, og de forblir bare et forhandlingskort hvis vi faktisk holder arbeidsflytene våre portable til dem. Det andre er arbeidsflytdisiplin: bruk frontier-tokens bare der ingenting billigere fungerer. Dette innlegget handler om det andre — fordi det er det du kan begynne med på mandag.

Prinsippet er gammelt nok til å ha en bygning oppkalt etter seg: arkitekten murer ikke selv. En frontier-modells fortrinn over en mellomklassemodell er enormt innen design, oppdeling og gjennomgang — og nær null når man skal taste inn et navnebytte i førti filer. Så del rollene. Prisstigen sier det samme i dollar:

Hvordan fable-architect-mønsteret fungerer

fable-architect-ferdigheten er en markdown-fil på rundt 100 linjer pluss én shell-krok, som lastes hver gang en Claude Code-økt kjører på frontier-modellen. Den håndhever en arbeidsdeling:

• Arkitekten gjør: forhører kravet, utforsker kodebasen, tar alle designbeslutninger — tilnærming, dataflyt, navn, signaturer, kanttilfeller — deler arbeidet opp i uavhengige biter, går gjennom diffene som kommer tilbake, kjører verifisering og skriver all prosa (planer, briefer, PR-tekster, commit-meldinger).
• Arkitekten gjør aldri: skriver eller redigerer en kildefil. Ingen kode i chatten utover korte signaturer inne i en brief.

Tre ting gjør at dette fungerer i praksis og ikke bare på en lysbildepresentasjon.

1. Briefen er grensesnittet

Hver bit får én implementeringsbrief. Implementøren starter med et ferskt kontekstvindu — alt som ikke står i briefen, må den gjenoppdage eller gjette. Den begrensningen er en fordel: den tvinger arkitekten til å bli ferdig med å bestemme før den delegerer. En brief inneholder beslutninger, ikke valgmuligheter.

## Implementeringsbrief: <slice>
Mål:          én setning, observerbart resultat
Kontekst:     det utforskningen allerede fant — utdrag, det nærmeste
              mønsteret å speile, linjeankere, fallgruver
Filer:        stier som skal opprettes/endres — denne bitens eksklusive eierskap
Design:       den besluttede tilnærmingen — dataflyt, navn, signaturer, kanter
Begrensninger: prosjektregler som gjelder: stil, lag, sikkerhet
Utenfor omfang: hva som ikke skal røres, inkludert filer som eies av andre biter
Delegering:   kan denne biten starte under-implementører, og hvor mange
Verifiser:    eksakte kommandoer og forventet resultat

To av disse linjene er nyere enn resten, og de finnes fordi implementørtrinnet endret seg under oss — se oppdateringen nedenfor.

2. Håndheving, ikke vibber

En PreToolUse-vaktkrok overvåker økten: hvis arkitekten prøver å redigere en fil som ikke er prosa, utløses en tillatelsesforespørsel. Å godkjenne forespørselen er det dokumenterte unntaket for trivielle redigeringer (en skrivefeil, en versjonsbump — tilfeller der delegasjonskostnaden er høyere enn å taste selv). Friksjon er policyen. Uten kroken holder “den dyre modellen bør ikke kode” akkurat til første deadline.

3. Gjennomgangssløyfen tetter kvalitetsgapet

Arkitekten leser agentens rapport og selve diffen — og stoler ikke på noen av dem alene — og kjører de viktigste verifikasjonskommandoene på nytt når påstanden betyr noe. Fant den et problem? Korreksjonen går tilbake til den samme agenten, som fortsatt har hele arbeidskonteksten sin. Ingen manuell fiksing, ingen ny oppstart.

Legg merke til at dette er arkitektens verifisering, og den blir værende. Det vi har begynt å fjerne, er verifiseringen vi pleide å skrive inn i briefene — instruksjoner som ba implementøren dobbeltsjekke seg selv. Nyere implementørmodeller gjør det uten å bli bedt om det, og å be dem gjøre det igjen kjøper en ekstra runde du allerede har betalt for.

Klar til å vokse bedriften din?

Start din gratis prøveperiode i dag og se resultater i løpet av få dager.

Be om demo Logg inn

Hva vi målte

For å sjekke om dette er en reell økonomisk mekanisme eller bare et tiltalende rituale, gravde vi gjennom alle Claude Code-transkripsjoner i prosjektene våre, dedupliserte API-forespørsler og priset hvert token etter gjeldende listepriser. Tre hypoteser, registrert før vi så på tallene per økt:

• H1 — Implementørene gjør tastingen. Hvis sant, bør implementør-underagenter produsere flere output-tokens enn arkitektens hovedløkke i delegerte økter.
• H2 — Delegering er billigere. Hvis sant, bør omprising av implementørenes arbeid til arkitektmodellens satser bli merkbart dyrere enn det vi faktisk betalte.
• H3 — Kvaliteten holder. Den vanskelige: delegert kode bør ikke trenge mer omarbeid enn kode arkitekten har tastet selv.

Grunnregler. Én API-forespørsel spenner over mange transkripsjonslinjer som gjentar det samme usage-objektet — vi grupperte etter request-ID, telte input- og cache-tokens én gang per forespørsel og tok det maksimale output-øyeblikksbildet (naiv summering per linje overdriver 2–3×). Kostnadene bruker gjeldende listepriser fra Anthropic — Fable $10/$50, Opus $5/$25, Sonnet $3/$15 per million input/output-tokens — med cache-lesinger til 10 % av inputprisen og cache-skrivinger til sine respektive TTL-satser. 31 av 354 økter i den interaktive butikken kvalifiserer som fable-architect-økter under en konservativ klassifisering; tallene viser de åtte dyreste. Vi oppgir forholdstall og prosenter i stedet for vårt absolutte forbruk.

Del 2 — Kvitteringene

H1 — Blandet … sa det første regnskapet. I de største delegeringsøktene holder hypotesen med klar margin — opptil 2,3× mer output fra implementørene enn fra arkitekten. Men på tvers av alle de 31 fable-architect-øktene produserte arkitekten fortsatt mer enn implementørene, 3,59M mot 3,15M tokens. Delvis er det rimelig — arkitektens output inkluderer alle planene, briefene og gjennomgangsprosaen, som er nettopp jobben dens — og delvis så det ut som økter som delegerte én bit og beholdt resten. Så husket vi at redesignet av nettstedet ikke hadde føltes arkitekt-tungt i det hele tatt, og begynte å lete etter tokensene som underagent-regnskapet ikke kunne se.

Bli med i vårt nyhetsbrev

Få de siste tipsene, trendene og tilbudene gratis.

E-postadresse

Abonner

Den andre kanalen: issue-trackeren som delegasjonsbuss

Underagent-regnskap har en blindsone: det ser bare delegering som skjer inne i en økt. Nettstedsredesign-økten — den største linjen i diagrammet over — viste seg å være noe helt annet: en enkelt arkitektløkke-økt som kjørte i 107 timer i strekk (292 planlagte oppvåkninger), brøt redesignet ned i GitHub-issues, tagget dem for CI-pipelinen vår og deretter overvåket: pollede kjøringer, gikk gjennom pipelinens pull requests og opprettet oppfølgingsissues etter hvert som QA avdekket feil.

Tastingen skjedde et sted vår per-økt-graving ikke engang hadde sett: en separat flåte av selvhostede runners, der pipelinens faser plan → implementer → gap-vurdering → gjennomgang kjørte som 252 uavhengige Opus-økter over 4,5 dager, med berøring av 48 ulike issues og PR-er.

H1, revidert — Bekreftet i prosjektskala. Tell begge kanaler, og bildet snur: pipelinen tastet 10× flere output-tokens enn arkitektløkken som sendte den ut (9,07M mot 877k), alt til Opus-satser. Å kjøre den implementeringsbølgen på arkitektens modell ville ha kostet 2,1× så mye — på ett redesign, i én uke, før man i det hele tatt regner med underagentene inne i økten. Et issue er bare en grovere brief: samme grensesnitt, samme økonomi, ett nivå opp.

H2 — Bekreftet, med en vri. Å prise implementørenes eksakte tokenvolum til arkitektmodellens satser gjør hver økt dyrere — fra +2 % til +54 %, 17 % på tvers av de åtte øverste. Ekte penger, men mindre enn output-prisgapet på 2× skulle tilsi. Vrien: det er ikke output det går penger på. I den største økten kostet arkitektens cache-lesinger omtrent 13× så mye som alt den tastet — det dominerende forbruket er den dyre modellen som holder og leser på nytt en stor orkestreringskontekst, ikke tasting. Delegering setter tak på output-regningen; neste spak er å holde arkitektens kontekst slank.

H3 — Ikke målt her. Tokenregnskap kan ikke se kodekvalitet. Det vi kan si observasjonsmessig: gjennomgangssløyfen er bærende — rapporter og differ er uenige ofte nok til at det er ufravikelig å lese begge — og korreksjoner som sendes tilbake til en kontekstvarm agent, konvergerer raskt. Hvis du replikerer dette og måler omarbeid skikkelig, vil vi gjerne se det, spesielt hvis det motbeviser oss.

Hva de bredere dataene lærte oss

• Adopsjon er en gradient, ikke en bryter. På droneoperasjons-appen — mindre og raskere i bevegelse — kjører 18 % av øktene fable-architect-mønsteret; på det eldre SaaS-monorepoet er det 9 %. Prosjektet som delegerte hardest, gjorde det på begge nivåer samtidig: implementørbriefer inne i økten og 252 pipeline-økter sendt ut gjennom issue-trackeren.
• CI-flåten kjører ikke ferdigheten — fordi den er implementøren. Våre automatiserte runner-økter starter aldri en implementør-underagent, og først leste vi det som manglende adopsjon. Promptene sier noe annet: hver eneste er et pipeline-steg — verifiser, gå gjennom, gap-vurdering — og omtrent seks av ti jobber mot et bestemt issue eller en PR. I prosjektskala er pipeline-runnerne implementørtrinnet.
• Det billigste trinnet har ikke hatt sin første arbeidsdag ennå. Alle de 78+ implementørkjøringene var av Opus-klasse; Sonnet-trinnet for mekaniske redigeringer ble først lagt til nylig og er ikke tatt i bruk. Hvilke besparelser dette enn måler, er de et gulv.

Grensesnittet er poenget: brief inn, diff ut — issue inn, PR ut. Den dagen prishoppet kommer, bytter du ut mureren, ikke prosessen.

Full åpenhet. Modellene er verifisert fra transkripsjonsstrenger, ikke antatt. Vi korrigerte oss selv to ganger (en overdrivelse av tokens per linje, deretter en plassholder-pristabell). Kontrafaktikken forutsetter at arkitekten ville brukt samme tokenvolum som implementørene gjorde — feilmarginene går begge veier. Pipeline-øktene ligger i en transkripsjonsbutikk som våre to første graveøkter ikke dekket; en regnskapsgrense skjulte en delegasjonskanal på 9M tokens for oss, og din har sannsynligvis en tilsvarende. Én ingeniørs prosjekter, mest gjennomgang-og-fiks og feature-arbeid — ikke en kontrollert benchmark. Korpuset lukkes også før Opus 5 ble lansert: hvert tall over er Fable-som-arkitekt over implementører av Opus-4-klasse. Trinnprisene flyttet seg ikke da Opus 5 kom, så de målte forholdstallene står — men se neste avsnitt for hva som faktisk flyttet seg.

Oppdatering — stigen flyttet seg under oss

Opus 5 ble lansert etter at disse målingene ble lukket, og ingenting i prisstigen endret seg: Opus er fortsatt $5/$25 per million input/output-tokens, Fable er fortsatt $10/$50, og diagrammet over er fortsatt riktig. Det som endret seg, er kapasiteten på hvert trinn. Anthropic posisjonerer Opus 5 som et sprang i dyp resonnering og langhorisont-agentarbeid — det vil si på nøyaktig det arbeidet arkitektrollen består av, til halv pris av arkitekttrinnet.

Det peker rett mot vår egen H2-vri. Hvis den dominerende arkitektkostnaden er cache-lesinger, og cache-lesinger faktureres med 10 % av inputprisen, leser en arkitekt som kjører på Opus 5 orkestreringskonteksten sin på nytt til $0,50 per million tokens i stedet for Fables $1,00. Posten som kostet 13× alt arkitekten tastet, halveres. Dette har vi ikke målt — det er aritmetikk under den samme forutsetningen om likt tokenvolum som vi flagget for 2,1×-kontrafaktikken, og det er det neste vi har tenkt å teste. Hvis det holder, er det interessante spørsmålet ikke lenger hvilke modelltyper, men om arkitekten trenger topptrinnet i det hele tatt.

Tre ting ved det nye implementørtrinnet endrer mønsteret selv, ikke bare prisen:

• Det griper lett etter underagenter — det motsatte av forgjengeren, som måtte overtales til å delegere i det hele tatt. En implementør som i stillhet starter sine egne implementører, multipliserer regningen uten at noen ser det. Derav linjen Delegering: i briefen: en bit sier nå om den får forgrene seg, og hvor bredt.
• Det verifiserer sitt eget arbeid uten å bli bedt om det. Verifikasjonsinstruksjoner skrevet for eldre modeller kjøper nå en overflødig ekstra runde, så de går ut av briefene. Arkitektens gjennomgangssløyfe er urørt.
• Det utvider omfanget. Utenfor omfang: slutter å være boilerplate og blir linjen som holder en bit som en bit.

Og trinnet vi aldri brukte, ble skarpere mens vi ikke så: Sonnet 5 kommer nær Opus-kvalitet på kodearbeid til $3/$15, med introduksjonspris under det ut august. “Hvilke besparelser dette enn måler, er de et gulv” var en gardering da vi skrev det. Nå leser det som en underdrivelse.

Del 3 — Hvor dette bevisst er på vei

Vi styrer med vilje mot en deling som vi tror hvert eneste ingeniørteam til slutt blir tvunget inn i: dyre frontier-modeller kun for idémyldring, arkitektur og gjennomgang; stadig billigere modeller for selve programmeringen. I dag er implementørene våre av Opus-klasse. Ingenting i arbeidsflyten endres når de blir av Sonnet-klasse, DeepSeek-klasse eller Kimi-klasse — grensesnittet er modelluavhengig av konstruksjon. Det er hele den strategiske verdien: den dagen subsidien tar slutt og fakturaen dobles, endrer team med denne disiplinen én konfigurasjonslinje. Team uten den reforhandler hele kostnadsstrukturen sin under press.

Fable-architect er et babysteg — adopsjonen er delvis, og det billigste trinnet har ikke hatt sin første kjøring. Men det er steget som bygger muskelen: å skrive briefer som fullt ut spesifiserer en bit, gå gjennom differ du ikke har tastet selv, behandle den dyre modellens oppmerksomhet som et budsjett. Og redesignbølgen viser hvor muskelen fører: når briefene først fungerer, fungerer issues, og den dyre modellen slutter helt å delta i implementeringen.

Hva du kan gjøre på mandag

1. Del rollene i agent-rammeverket ditt. Én regel på øktnivå: frontier-modellen planlegger og vurderer; deleger alle filendringer til en billigere implementøragent. I Claude Code er dette en ferdighet pluss underagent-definisjoner — en ettermiddag med oppsett.
2. Gjør grensen mekanisk. Legg til en krok før redigering som utfordrer den dyre modellens egne filskrivinger. En regel som ikke koster noe å bryte, blir brutt innen fredag.
3. Skriv briefer med en fast mal. Mål, kontekst, filer, design, rammer, utenfor omfang, delegasjonsbudsjett, verifiser. Malen er disiplinen — og delegasjonsbudsjettet er det som hindrer en implementør i å ansette sin egen i stillhet.
4. Gå gjennom både rapporten og diffen. Stol aldri på bare én av dem; kjør verifikasjonskommandoene som betyr noe, på nytt.
5. Mål din egen deling. Transkripsjonene dine inneholder allerede dataene — grupper etter forespørsel, prissett etter modell, og se hvem som faktisk taster. Våre viste oss et ubrukt billigtrinn og en delegasjonskanal på 9M tokens som vi ikke visste om.
6. Utvid grensesnittet fra briefer til issues. En brief delegerer en times arbeid; et issue delegerer en dag av det. Når issues dine først bærer akseptansekriterier en pipeline kan handle på, kan den dyre modellen legge arbeid inn i trackeren og overvåke i stedet for å sitte i løkken for hver bit.
7. Hold en utvei varm. Kjør en billig eller åpen modell som implementør på én lavrisiko-bit i uken. Portabilitet du aldri bruker, er portabilitet du ikke har.
8. Prissett arkitekten på nytt, ikke bare mureren. Hver modellansering flytter trinnene uten å flytte stigen. Hvis mesteparten av arkitektforbruket ditt er kontekst og ikke tasting, er et billigere arkitekttrinn verdt mer enn et billigere implementørtrinn — sjekk hvilket av dem transkripsjonene dine sier du kjøper.

Laboratoriene vil fortsette å fortelle oss at toppmodellene deres er verdt enhver pris, og — irriterende nok — for dømmekraftarbeid har de stort sett rett. Trekket er ikke å avstå. Det er å slutte å betale frontier-priser for for-løkker.