De flesta organisationer som bygger med AI gör samma misstag. De lägger till komplexitet. Fler steg i prompten, mer scaffolding kring modellen, mer hårdkodad logik i retrieval-pipelines. Det är logiskt. Man löser ett problem, lägger till en regel, och går vidare till nästa.
Problemet är att modellerna rör sig snabbare än reglerna.
Stegförändring, inte uppgradering
Anthropic läckte nyligen information om Claude Mythos, den första modellen tränad på Nvidias GB300-chips. Säkerhetsforskare fick testa den innan den släpptes publikt. En av de mest erfarna i världen visade att Mythos omedelbart hittade zero-day-sårbarheter i Ghost, ett open source-projekt med 50 000 stjärnor på GitHub som aldrig haft allvarliga säkerhetsproblem. Sårbarheter som de bästa mänskliga forskarna missat.
Det är inte en inkrementell förbättring. Det är en stegförändring.
Och det är precis den typen av förändring som tvingar oss att ompröva hur vi bygger system runt AI. Matt Shumer, som bevakar AI-fältet nära, kallar det "the bitter lesson" och beskriver det i en video som är väl värd att titta på. Kärnan i hans argument: varje gång modellerna blir tillräckligt mycket bättre visar det sig att enklare system presterar bättre än komplexa. All den scaffolding vi byggt blir en belastning, inte en tillgång.
Det är kontraintuitivt. Men det stämmer.
Fyra saker att granska nu
Shumer lyfter fyra specifika områden som sannolikt går sönder vid en stegförändring. De är värda att ta på allvar.
Prompt-scaffolding. De flesta produktionssystem har systemprompts på tusentals tokens. Hälften är processbeskrivningar: klassificera intent, kontrollera hallucineringar, validera format. Fråga dig, rad för rad: finns den här instruktionen för att modellen behöver den, eller för att jag behövde att modellen skulle behöva den? Anthropics egen rekommendation är tydlig: lägg bara till komplexitet som bevisligen förbättrar resultaten. OpenAIs Codex-guide säger samma sak: beskriv vad du behöver, inte hur.
Retrieval-arkitektur. Vi har lagt enormt mycket logik i hur vi styr retrieval. Chunk-storlek, re-ranking, alpha-parametrar för hybridsökning. Men smartare modeller behöver mindre av det. Med kontextfönster på miljoner tokens skiftar jobbet från att mikromanagera retrieval till att presentera en välorganiserad datamängd och låta modellen hitta vad den behöver. Det betyder inte att RAG är dött. Det betyder att vår del av arbetet förflyttas uppåt, mot datakvalitet och tillgänglighet.
Hårdkodad domänkunskap. Räkna reglerna du matar modellen med. Hur många av dem kan den härleda själv från kontexten? Om du har en skrivinstruktion på tio rader men modellen kan plocka upp stilen från ett enda exempel, kostar de där tio raderna mer än de smakar. De tar upp plats i kontextfönstret och riskerar att överbegränsa modellen.
Evalueringspipelines. Om du bygger mjukvara med AI och har manuella granskningssteg mitt i flödet, fundera på om du istället kan ha en enda, grundlig evalueringsport i slutet. Modellerna producerar kod som är tillräckligt nära rätt tillräckligt ofta för att mellankontroller ofta kostar mer än de sparar. Skriv ett heltäckande eval-skript som testar funktionella krav, icke-funktionella krav och edge cases. Och lita på det.
Outcome specs, inte processspecifikationer
Det som förenar alla fyra punkterna är en rörelse från hur till vad. Istället för att beskriva processen steg för steg, beskriv det önskade slutresultatet och de hårda begränsningar som gäller oavsett hur modellen tar sig dit.
Ett kundtjänstexempel gör det tydligt. Processversionen: klassificera intent i en av 14 kategorier, routa till rätt handler, hämta de fem bästa artiklarna med hybridsökning, generera svar baserat enbart på hämtad kontext. Outcome-versionen: lös kundens problem med hjälp av vår kunskapsbas, våra policyer och kontots historik. Kunden ska lämna nöjd. Lösningen ska följa vår returpolicy.
Skillnaden är enorm. Processversionen var nödvändig med svagare modeller. Med en Mythos-klass modell är den sannolikt en belastning som begränsar modellens utrymme att lösa problemet effektivt.
Det kräver i gengäld att du blir bättre på att definiera constraints: saker som alltid ska gälla, oavsett hur modellen når målet. Exponera aldrig kunders finansiella data. Verifiera alltid returbehörighet mot policyn. De reglerna överlever modelluppgraderingar. Processregler gör det inte.
Vad det betyder strategiskt
Stegförändringen har en ekonomisk dimension. Mythos kommer sannolikt bara vara tillgänglig på premiumplaner initialt. Det skapar en asymmetri: de som investerar i bättre modeller, och vet hur de ska använda dem, kommer att dra ifrån. Inte för att de har bättre talang, utan för att de har bättre verktyg och enklare system som ger verktygen utrymme.
Dessutom är Mythos inte ensam. Google, OpenAI och andra hyperscalers tränar på samma generation hårdvara. Vi kommer se liknande steg inom månader. Det här är inte ett Anthropic-fenomen. Det är ett kapacitetssprång i hela branschen.
Och det gäller inte bara tekniska system. Shumer gör en intressant poäng om "under the desk software", de verktyg som icke-tekniska medarbetare bygger åt sig själva med hjälp av AI. Med starkare modeller blir den kategorin allt mer sofistikerad. Applikationer som tidigare krävde en utvecklare kan nu byggas genom att specificera ett behov i vanligt språk. Det ställer nya krav på IT-organisationen: hur underhåller man det? Hur sätter man guardrails utan att kväva produktiviteten?
Den bittra läxan handlar inte om att vi gör något fel. Den handlar om att det som var rätt i förra modellgenerationen inte är rätt i nästa. Varje rund av förbättring kräver att vi förenklar. Varje gång vi tror att vår scaffolding, vår process, vårt sätt att göra saker tillför värde, behöver vi pröva om det fortfarande stämmer.
Det är obekvämt. Det är meningen.
*Baserat på Matt Shumers analys av Claude Mythos.*