Stop med at bygge til den nuværende model: Sådan rider du kapabilitetskurven

Den 14. maj 2026 trykkede Jarred Sumner på merge-knappen til en pull request, der tilføjede over én million linjer Rust til Bun, JavaScript-runtimen, han har bygget de sidste fire år. PR #30412 omfattede 6.755 commits og 1.009.257 linjer kode. Den blev skrevet på ni dage, og Sumner selv tastede ikke en eneste linje. Det gjorde Claude.

Det her er ikke en kuriøsitet. Det er et signal om, hvor langt sprogmodellerne har flyttet sig på 12 måneder, og hvad det betyder for dig, der bygger AI-applikationer.

Bun-historien er ikke en isoleret kuriøsitet

Bun blev oprindeligt skrevet i Zig, et low-level systemsprog. At porte en million linjer mellem to systemsprog er traditionelt et flerårigt projekt med betydelig risiko for subtile fejl. Sumner skrev en 600-linjers PORTING.md-guide, der mappede hver Zig-pattern til sin Rust-pendant, satte en sværm af Claude-agenter i gang parallelt mod testsuiten, og lod feedback-loopet køre. Da han lagde branchen op første gang, sagde han, at der var "stor sandsynlighed for, at hele koden bliver smidt væk". Seks dage senere bestod den 99,8% af testene. Tre dage efter blev den merged.

På Anthropics Developer Day for nylig satte Jeremy Hadfield, produktchef for kodning hos Anthropic, ord på, hvad denne type begivenheder er udtryk for. Han kalder det "the capability curve". Den beskriver, hvordan kapabilitetsniveauet hos sprogmodeller flytter sig så hurtigt, at det ændrer fundamentet under alle, der bygger AI-applikationer lige nu.

For dig, der har en AI-applikation i produktion, er det her ikke en abstrakt observation. Det er en konkret risiko, hvis du ikke arbejder med systematisk at absorbere kapabilitetsforbedringer i dit eget setup.

Hvor langt er vi kommet på 12 måneder?

SWE-bench Verified er det mest etablerede mål for software engineering-kapabilitet hos sprogmodeller. Den består af 500 GitHub-issues fra rigtige open-source-projekter, hvor modellen skal generere en patch, der består unit tests. For et år siden, i marts 2025, lå Anthropics Claude 3.7 Sonnet omkring 60%. I dag, april 2026, scorer Claude Opus 4.7 87,6%. Anthropics interne Mythos Preview ligger på 93,9% og har i praksis mættet benchmarken.

På 12 måneder er modellerne gået fra at løse hver anden GitHub-issue til at løse næsten ni ud af ti. Sumner ville aldrig have kunnet køre Bun-porten med Sonnet 3.7. Sonnet 3.7 ville være gået i loop første gang den ramte en uventet Zig-makro og havde slet ikke kunnet holde sammen på rationalet over hundredetusinder af tokens. Det er det samme produkt, samme prompt-stil, samme arbejdsgang. Det er bare en anden model.

Hadfield gennemgik på scenen, hvor disse kapabilitetsgevinster konkret kommer fra. Tre områder skiller sig ud.

Planning før action. Sonnet 3.7 angreb opgaver, som de fleste af os angriber IKEA-møbler. Den smed sig direkte ud i koden, byggede noget, opdagede, at den havde misforstået opgaven, prøvede igen. Den planlagde, efter den havde fejlet. Dagens modeller læser kodebasen først, skriver en plan ud, fanger deres egne misforståelser i planlægningsfasen og rammer ofte rigtigt første gang. For dig betyder det, at du ikke længere behøver at bygge omfattende prompt-scaffolding, der tvinger modellen til at planlægge. Sæt reasoning-niveauet højt, og lad den selv finde sin plan.

Error recovery. "Doom looping" var et af de mest udbredte failure modes ved tidligere modeller. Modellen ramte en fejl, foreslog en løsning, fejlede igen med samme tilgang, foreslog samme løsning lidt omformuleret. Det er stort set løst nu. Når Opus 4.7 møder en fejl, læser den output'et, ræsonnerer om, hvad der gik galt, og prøver en anden tilgang. Det betyder færre spildte tokens og højere succesrate på opgaver, hvor modellen ikke kommer rigtigt i mål første gang.

Sustained attention over lange runs. For et år siden mistede modellerne tråden et sted mellem 100.000 og 200.000 tokens. Lange refactorings krævede, at man chunkede opgaven op i bidder og førte konteksten manuelt fra session til session. I dag holder Opus 4.7 sammenhæng over 1 million tokens i sit context-vindue, og den glemmer ikke instruktionerne fra starten af opgaven halvvejs igennem. Det er det, Bun-porten lever af. Hadfield var ærlig om, at coherencen ikke er perfekt over hele kontekstvinduet, men forskellen fra for 12 måneder siden er enorm.

Tilsammen muliggør de tre ting det, vi nu kalder lange autonome agenter. Modeller, der kører i timer eller dage, ikke minutter.

Du har bygget til en model, der ikke længere findes

Hvis du har bygget en agent eller en AI-baseret feature de seneste 12 måneder, er der stor sandsynlighed for, at du har bygget den til at kompensere for svagheder ved den model, du startede med. Du har den 3.000-linjers Frankenstein-prompt, som Hadfield kalder det. Hver linje blev tilføjet for at fikse en konkret fejl, Claude lavede. Hver fejl er sandsynligvis ikke længere noget, Claude laver.

Det er det stille problem ved at bygge i et felt med tre måneders takt. Dit scaffolding bremser dig. Det binder din applikation fast til kapabilitetsniveauet hos den model, du arbejdede med, da du skrev prompten. Den nye model lander, du tester den i din eksisterende setup, ser måske 1-2 procentpoint forbedring og tænker: "Det her var ikke meget". Det, Hadfield har observeret hos kunder, er, at de samme kunder ofte en uge senere, når de har testet modellen på sværere opgaver, opdager, at modellen har taget et stort skridt. Det var deres måling, der ikke kunne følge med.

Det her er problemet med saturerede evals og oppustet scaffolding. Begge dele giver dig falsk tryghed om, at intet er ændret. Begge dele kan løses.

Disciplin nummer ét: byg evals, du faktisk kan bruge

Evals er AI-eraens unit tests, Hadfields formulering. Hvis du bygger en AI-applikation uden evals, svarer det til at bygge en traditionel applikation uden unit tests. Du kan godt slippe afsted med det, men du opbygger teknisk gæld og ved aldrig, om dine ændringer flytter ting i den rigtige retning.

To fælder.

Den første er at vælge en akademisk benchmark som proxy for din applikation: SWE-bench Verified, BrowseComp, Terminal-Bench. De er fine til at sammenligne modeller på generelle opgaver, men de måler ikke din use case. Hvis du bygger en finansagent, skal du indsamle de konkrete fejlmønstre, dine kunder ser i produktion, og bygge dem til evaluations. Hvis du bygger en HubSpot-integration, der skal genkende leadkvalitet, skal din eval bestå af eksempler, der ligner dine kunders rigtige leads.

Den anden fælde er at lade dine evals saturere. Hvis Opus 4.7 rammer 90% eller mere på din eval, og de sidste 10% er enten urimelige eller noget, ingen model kan, så er den eval blind for fremtidige modelforbedringer. Du tester gennem en lukket dør. Når Mythos eller den næste Opus lander, vil din eval rapportere "ingen forbedring", og du vil tage en strategisk forkert beslutning.

Løsningen er to-delt. Behold gerne dine regression-evals, dem, der skal sikre, at modellen ikke pludselig taber kapabilitet på opgaver, den burde kunne klare. Men ved siden af skal du have evals, der er designet til at fange næste generations forbedringer. De skal være svære nok til, at den nuværende frontier-model ikke kan klare dem perfekt.

Hadfields praktiske observation er, at de virksomheder, der har gode evals, er de hurtigste til at adoptere nye modeller. Når Mythos lander, kører de deres eval-script, ser tallene, og deployer, hvis det ser fornuftigt ud. De konkurrenter, der ikke har evals, bruger to uger på at læse Twitter, prøve modellen manuelt, og diskutere "vibes". I 2026 er to ugers forsinkelse i adoption af en bedre model en konkret konkurrenceulempe.

Disciplin nummer to: skrump dit scaffolding

Hver gang en ny model lander, skal du tage din prompt frem og spørge: Hvor mange af de her linjer er workarounds for problemer, modellen ikke længere har?

Den klassiske udvikling er, at en agent starter med en kort, klar prompt. Modellen laver en fejl. Du tilføjer to linjer, der instruerer den i at undgå fejlen. Et par måneder senere har du 3.000 linjer prompt, og du ved ikke længere, hvilke af dem der gør forskel. De fleste af dem blev skrevet til en model, der ikke længere findes.

Når du shrinker scaffolding, sker der typisk to ting. Det første er, at applikationen bliver hurtigere. Færre tokens i system-prompten betyder lavere latency og lavere omkostninger per kald. Det andet er, at modellen bliver bedre. Det lyder kontraintuitivt, men det er reelt. Lange, modstridende eller forældede instruktioner forvirrer en moderne model mere, end de hjælper den. Når den får plads til at gøre det, den allerede kan, gør den det bedre.

Hadfields praktiske råd: Beskriv, hvad du intender, ikke hvordan du arbejder rundt om svagheder. "Find leads, der matcher vores ICP, og opret dem som contacts i HubSpot med korrekt lead source" er bedre end "Husk altid at tjekke, om kontakten allerede eksisterer, husk at undgå at tilføje samme person to gange, husk at sætte lead source til..." Den nuværende model ved det her. Lad den arbejde.

Bun-historien er ekstrem. De fleste af os flytter ikke millioner af linjer kode på en uge. Men princippet skalerer ned. Den Zoho CRM-integration, der tog en uge for seks måneder siden, tager halvanden dag nu, hvis du har stillet dit setup om, så Claude kan arbejde autonomt mod dit testsuite. Den HubSpot CMS-modul-migration, vi for et år siden ville have håndteret manuelt fil for fil, kører nu som en flerstuet agent, der læser den gamle struktur, planlægger ændringerne, og åbner en pull request med både ny kode og opdaterede tests.

Forskellen mellem virksomheder, der får værdi af det, og virksomheder, der ikke gør, ligger sjældent i modellen selv. Den ligger i to ting: Har du evals, der måler, hvad du faktisk laver, og er du villig til løbende at skære dit scaffolding ned, så det matcher dagens model i stedet for fortidens?

Hadfield afsluttede sin keynote med en formulering, jeg tager med mig. Du skal ikke bygge til den model, der findes nu. Du skal bygge til den, der lander om tre måneder. Den foundation, du står på, bliver mere intelligent over tid. Dine applikationer skal designes, så de absorberer det skift automatisk, ikke så de skal renoveres for hver release.

Den virksomhed, der i dag har sit eval-setup i orden og er disciplineret omkring at skrumpe scaffolding, vil om seks måneder være måneder foran konkurrenter, der ikke har. Det er ikke en spekulation. Det er en konsekvens af kurven.