Modellen ble ikke smartere. Stillaset rundt den ble bedre.

Tre resultater, null nye modeller

September har vært en merkelig måned i AI.

Den 8. september kunngjorde OpenAI at rundt 10 000 agenter, over 88 timer, hadde produsert et bevis for en variant av Navier-Stokes-problemet. Agentene sendte nesten fem millioner meldinger til hverandre, og regningen lå på flere millioner dollar.

Verdt å presisere med en gang: Navier-Stokes er ett av de syv Millennium-problemene, men det OpenAI beviste er ikke den formuleringen prisen gjelder. Clay-instituttet har ikke godkjent resultatet og fører problemet som uløst. Beviset er kontrollert maskinelt i Lean, men uavhengig fagfellevurdering tar år.

Noen dager senere kom to forskningsartikler om det samme temaet fra hver sin kant av verden. The Last AI Built by Humans, 75 sider fra Shanghai Jiao Tong, Tsinghua, ByteDance og Shanghai AI Lab, som skisserer fem nivåer av selvforbedrende AI. Og Dream-RSI fra University of Maryland, Google DeepMind og University of Virginia.

Det interessante er ikke overskriftene. Det er en detalj som går igjen i alle tre, og som nesten ingen snakker om:

Ingen av dem brukte en bedre modell.

Vektene, altså selve modellen, sto stille. Det som endret seg var stillaset rundt den. Hvordan arbeidet ble delt opp, hvem som kontrollerte hvem, hva som ble lagret, og når det var lov å gi opp.

Det er en påstand vi har gjentatt lenge: strukturen kommer før teknologien. Forskjellen nå er at det ikke er vi som påstår det. Det er forskningsmiljøene som demonstrerer det.

Hva en loop faktisk er

Boris Cherny, mannen bak Claude Code, sa noe i et intervju i juni som har gått rundt siden:

«Jeg prompter ikke Claude lenger. Jeg har loops som kjører. Det er de som prompter Claude og finner ut hva som skal gjøres. Jobben min er å skrive loops.»

En loop er ikke komplisert. Den gjør fire ting, om og om igjen:

1. Den ber modellen om å prøve noe
2. Den leser hva som kom tilbake
3. Den avgjør om oppgaven faktisk er løst
4. Hvis ikke: den ber om et nytt forsøk, med det den lærte

Det er alt. Og likevel er det denne firetrinnsmekanismen som ligger under hvert eneste av resultatene over.

Eksempel 1: 30 av 60 agenter produserte ingenting

Det best dokumenterte tilfellet er Anthropics arbeid på Riemann-hypotesen i august.

Modellen genererte og testet 650 ideer uten å lykkes med noe som helst. Så, over halvannet døgn, koordinerte den rundt 60 underagenter som kjørte 2 400 shell-kommandoer, skrev hundrevis av Python-skript og kontrollerte hverandres arbeid. Til sammen 31 millioner tokens.

Fordelingen av de 60 underagentene er det mest lærerike i hele saken:

Halvparten produserte ingenting.

Det er ikke en svakhet i oppsettet. Det er oppsettet. Strukturen var det som gjorde at 30 bortkastede forsøk ikke kostet noe særlig, og at de 2 som traff ble fanget opp i stedet for å drukne.

Legg også merke til at 13 agenter, altså like mange som utviklet støtteideer, hadde én eneste jobb: å sjekke om argumentene holdt.

Resultatet var å flytte en nedre grense fra 41,6 til 67,2 prosent. Riemann-hypotesen er fortsatt uløst, og Anthropic skriver selv at de ikke tror teknikken vil løse den. Noen uker senere publiserte matematikeren Youness Lamzouri et enklere bevis for samme grense, uten AI.

Den siste setningen er verdt å lese en gang til.

Eksempel 2: 423 sikkerhetsfeil i Firefox på en måned

Matematikk er langt fra hverdagen til de fleste. Dette er nærmere.

Mozilla satte opp en loop mot Firefox-kodebasen som endte med 423 rettede sikkerhetsfeil på en måned. Loopen hadde tre trinn:

Prioritering. En modell gikk gjennom millioner av kodelinjer og ga hver fil to karakterer: hvor sannsynlig det var at den inneholdt minnefeil, og hvor lett den var å nå fra en nettside. Agentene brukte tiden der risikoen var størst.

Forsøk. Agentene prøvde å få programmet til å krasje. Noen feil krevde «14, 15, 20 ulike tilnærminger» før de lot seg gjenskape.

Kontroll. To porter før et menneske ble involvert. Først måtte det faktisk ha skjedd en krasj, beskrevet som «et krystallklart signal». Deretter måtte en egen kontrollagent bekrefte at feilrapporten ga mening.

Resultatet var at det nesten ikke kom falske positiver fram til utviklerne.

Og så det ærlige forbeholdet, som er minst like interessant: når agenten rettet en feil, rettet den som regel bare det ene stedet. Menneskene så på og sa: dette er riktig, men vi bør sjekke tre lignende steder også.

Eksempel 3: Loggene er verdien

Dream-RSI-artikkelen tar dette ett steg videre, og det er her det blir relevant for hvordan dere jobber.

Vanligvis, hvis du vil teste en ny strategi for hvordan loopen skal lete, må du kjøre hele loopen på nytt. Det koster penger og tid.

Poenget i artikkelen er at det ikke er nødvendig, hvis du har tatt vare på hva som ble prøvd sist. Koden som ble skrevet, poengsummen den fikk, om den krasjet. Har du de loggene, kan du teste tusenvis av nye strategier mot dem uten å kjøre en eneste ny beregning. Forskerne kaller det å drømme.

Konkret: en lasso-løser ble utviklet på 1 879 agent-kall, mot 51 200 generasjoner for metoden som holdt rekorden. På en av testene gikk samlet compute ned 42 prosent.

Og igjen: modellen ble aldri rørt. Bare koden som bestemmer hva som skal prøves neste gang ble skrevet om.

Det vanskelige er ikke loopen. Det er stoppbetingelsen.

Her er poenget for dere, og det er ikke det man skulle tro.

Å skrive selve loopen er trivielt. Noen linjer kode. Det vanskelige er å svare på ett spørsmål:

Hvordan vet loopen at den er ferdig?

Firefox hadde et krystallklart svar: programmet krasjet, eller så gjorde det ikke det. Riemann-arbeidet hadde tusenvis av numeriske kontroller mot kjente verdier. Dream-RSI hadde en poengsum for hvor rask koden var.

I alle tre tilfellene fantes det et signal som ikke lot seg diskutere.

De fleste forretningsprosesser har ikke det. «Er dette tilbudet godt nok?» har ikke en fuzzer som krasjer. «Er denne fakturaen riktig kontert?» har det faktisk, hvis kontoplanen og reglene finnes skriftlig. «Er dette dokumentet oppdatert?» har det, hvis noen har bestemt hva oppdatert betyr.

Det er her arbeidet ligger. Ikke i modellen, ikke i loopen, men i å gjøre kriteriene eksplisitte nok til at en maskin kan sjekke dem.

Det er også derfor «vi burde bruke mer AI» sjelden fører noe sted, mens «vi burde skrive ned hva som faktisk er riktig her» gjør det.

Fire ting å ta med videre

Dere trenger ikke en bedre modell. Dere trenger en etterprøvbar definisjon av ferdig. Det er noe et menneske i virksomheten må bestemme, ikke noe en leverandør kan levere.

Regn med at det meste mislykkes. 30 av 60 agenter produserte ingenting, og det var greit fordi det var billig. Bygg ting som tåler å feile, i stedet for å jage noe som treffer hver gang.

Ta vare på loggene. Det som ble prøvd, hva som kom ut, hva som ikke virket. Det er råstoffet neste runde bygger på. Virksomheter som ikke dokumenterer, betaler for den samme oppdagelsen to ganger.

Behold kontrollen. I begge de dokumenterte eksemplene hadde mennesker en rolle som ikke lot seg automatisere bort: å se det agenten ikke så. Det mønsteret er ikke midlertidig.

Og en ting til, om hvor arbeidet deres tar veien

Alle eksemplene over har noe til felles som er lett å overse: arbeidet foregikk inne i en leverandørs modell.

Det er verdt et spørsmål, og det gjelder ikke bare matematikere.

Når dere kjører deres egne problemer, dokumenter og kundedata gjennom et AI-verktøy, hvor tar det veien? Hvem har databehandleravtale med hvem? Hva deles, og hva deles ikke?

Det er ikke et spørsmål om mistillit til leverandøren. Det er et spørsmål om å vite svaret før det blir aktuelt, i stedet for etterpå. Det er den samme jobben som ligger under alt det andre her: strukturen må på plass før teknologien.

Loopen er ikke magi. Den er en ryddig måte å jobbe på, satt i system. Det er akkurat derfor den virker.