Brug nyere AI-modeller til at instruere ældre modeller

Med få måneders mellemrum lander en ny frontier-AI-model, og mønsteret gentager sig: den er mærkbart bedre til at udøve dømmekraft og mærkbart dyrere end modellerne før den. Her i juni 2026 ligger Anthropics nyeste Claude-model øverst på kodebenchmarks, OpenAIs nyeste GPT-generation driver Codex, og Googles Gemini Pro-modeller konkurrerer hårdt på prisen. Den forrige generation — Opus, Sonnet, ældre GPT-modeller — er stadig tilgængelig, stadig dygtig og langt billigere.

De fleste behandler det som et valg: betal for den bedste, eller spar med resten. Jeg mener, den ramme er forkert. Den opsætning, der faktisk virker, er at bruge dem sammen med en klar arbejdsdeling: den nyeste model skriver instruktionerne, de ældre modeller følger dem.

Prisasymmetrien — og hvad den køber

Prisforskellen mellem en frontier-model og arbejdshest-niveauet er stor nok til, at det sjældent giver mening at køre alt på den nyeste model til rutinearbejde. Men forskellen i evner er ikke jævnt fordelt. Ældre modeller er tæt på frontier-niveau på veldefinerede opgaver: skriv denne funktion, oversæt denne side, følg denne tjekliste. Forskellen viser sig i dømmekraften — at håndtere tvetydighed, opdage hvad der mangler, vide hvornår en regel ikke bør gælde.

Den asymmetri peger på arbejdsdelingen. Dømmekraft er nødvendig, når der træffes beslutninger. Udførelse kræver mest af alt beslutninger, der allerede er truffet og skrevet tydeligt ned.

Så træf beslutningerne én gang med den stærkeste tilgængelige model, og skriv dem ned i en form, de billigere modeller kan følge. Det er samme logik som en senior udvikler, der skriver retningslinjer for et team. Du behøver ikke senioren i hvert eneste code review, hvis retningslinjerne er gode nok — du har brug for senioren dér, hvor retningslinjerne slipper op.

Sådan ser det ud i praksis

Mønsteret har fire trin:

1. Arbejd strategien igennem med den nyeste model. Ikke “skriv en artikel til mig”, men de underliggende beslutninger: hvem målgruppen er, hvad reglerne er, hvor grænsetilfældene ligger, hvordan fejl ser ud. Frontier-modellen er bedst her, for det er her, tvetydigheden bor.
2. Lad den skrive holdbare instruktioner. Projektinstruktionsfiler som AGENTS.md eller CLAUDE.md, prompts, tjeklister, stilregler, gode og dårlige eksempler. Resultatet er ikke arbejde — det er drejebogen for arbejdet.
3. Lad billigere modeller udføre inden for de skinner. Claude Sonnet, Codex, Gemini, eller hvad der passer til dit setup. Daglige opgaver, udkast, oversættelser, refaktoreringer, indholdsopdateringer — alt sammen kørende på instruktioner, der allerede indeholder dømmekraften.
4. Eskalér, når skinnerne slutter. Når noget er reelt nyt, strider mod en eksisterende regel eller føles strategisk vigtigt, så gå tilbage til frontier-modellen og opdatér drejebogen.

Er instruktionsfiler og AI-kodeværktøjer generelt nyt for dig, er grundlaget dækket i kom i gang med programmering med AI.

Et konkret eksempel

Jeg driver to sprogversioner af dette website, som hver retter sig mod sit eget marked. Strategispørgsmålene — hvilket marked hvert site betjener, hvordan de to sites indhold undgår at drive fra hinanden, hvordan jeg undgår søgeordskannibalisering mellem beslægtede artikler — blev arbejdet igennem med den nyeste Claude-model, som derefter skrev reglerne ind i repositoriets AGENTS.md: målgrupper, formuleringseksempler med gode og dårlige versioner, et SEO-afsnit og en tjekliste for nye artikler.

Pointen med det arbejde er ikke, at frontier-modellen skrev pæn dokumentation. Pointen er, at en billigere model nu kan levere et udgivelsesklart udkast i første forsøg, fordi instruktionerne allerede indeholder de beslutninger, den ellers ville gætte sig til. Den dyre model kørte én gang. De billige modeller kører hver dag.

Sådan ser gode instruktioner ud

At skrive instruktioner til en svagere model er en færdighed i sig selv, og frontier-modellerne er reelt gode til det, når man beder dem direkte. Nogle få egenskaber betyder mere end længden:

• Konkrete eksempler slår abstrakte regler. “Skriv i en rolig, direkte tone” er pynt. En god sætning og en dårlig sætning side om side med én linje, der forklarer forskellen, ændrer adfærd.
• Tjeklister slår prosa. En nummereret liste over, hvad en færdig opgave indeholder, er noget, en lille model selv kan kontrollere sig op imod.
• Obligatoriske selvtjek fanger fejl tidligt. Regler som “konkludér om overlap, før du skriver” tvinger modellen til at vise sit ræsonnement dér, hvor du kan se det.
• Eskaleringsregler forhindrer tavse fejl. Instruktionen “hvis opgaven ikke passer til reglerne, så stop og sig det” er den billigste forsikring, der findes.

Begrænsningerne

Det her er ikke et trick, der fjerner behovet for review. Instruktioner ældes: fakta ændrer sig, strategier ændrer sig, og en drejebog skrevet i januar driver stille ud af kurs hen over sommeren. Tidsfølsomme påstande — modellers evner, priser, SEO-anbefalinger — bør blive hos den model, der kan verificere dem, ikke fryses fast i instruktioner. Og ingen instruktionsfil gør en lille model god til dømmekraft; den reducerer kun, hvor ofte dømmekraft er nødvendig.

Sammenligningen mellem konkrete værktøjer betyder mindre end selve strukturen. Om din daglige arbejdshest er ChatGPT eller Claude — et spørgsmål, jeg har behandlet i ChatGPT mod Claude for udviklere — er løftestangen den samme: den nyeste model er mest værdifuld, ikke som en hurtigere arbejder, men som forfatteren af det system, dine billigere arbejdere kører på.

Vil du have hjælp til at sætte det op i et rigtigt projekt — instruktionsfiler, indholdsregler og et workflow, dine værktøjer faktisk følger — så tag kontakt.