AI-omskriving av Bun kostet 165 000 dollar på 11 dager

Hva skjedde da Bun ble skrevet om fra Zig til Rust

I juli 2026 fortalte utvikleren bak JavaScript-runtimen Bun at hele kjernen var skrevet om fra programmeringsspråket Zig til Rust ved hjelp av AI-kodeagenter. Ifølge Simon Willisons gjennomgang av annonseringen tok arbeidet 11 dager med aktiv monitorering og kostet anslagsvis 165 000 dollar i API-tokens. Dette er ikke et laboratorieeksperiment. Den nye Rust-implementasjonen har vært i produksjon i Claude Code siden 17. juni 2026.

For norske ledere og teknologiansvarlige er saken interessant av en enkel grunn: den flytter AI-drevet kodeomskriving fra teori til en dokumentert kostnad og et dokumentert tidsforbruk. Når noen har gjort det i full offentlighet, kan du regne på om det samme er mulig hos deg. Denne artikkelen bruker Bun-saken som utgangspunkt, men handler om beslutningen du står overfor: når lønner en slik omskriving seg, hva er forutsetningen som må være på plass, og hva koster det egentlig.

Fra Zig til Rust på 11 dager

Bun er en runtime for JavaScript og TypeScript, en direkte konkurrent til Node.js. Kjernen var opprinnelig skrevet i Zig, et lavnivåspråk kjent for ytelse og enkelhet. Omskrivingen flyttet denne kjernen til Rust, et språk med sterkere garantier for minnesikkerhet. Ifølge Willisons oppsummering ble hele jobben styrt gjennom agentiske arbeidsflyter der AI-modeller skrev, testet og rettet koden i sykluser.

Poenget som gjør dette relevant for andre enn Bun-teamet: dette var en oversettelse mellom to språk av en stor, moden kodebase i produksjon, ikke et grønt prototype-prosjekt. Skalaen er det nye. Store omskrivinger har historisk vært flermåneders eller flerårs-prosjekter med høy risiko for at det ferdige resultatet aldri når produksjon.

Hvorfor språkbyttet skjedde

Begrunnelsen var ikke at Zig var et dårlig valg. Tvert imot: utvikleren bak Bun roser Zig for å ha brakt prosjektet dit det var, men peker på bugs i minnehåndtering som den utløsende årsaken til byttet. Rust flytter en hel klasse av minnefeil fra kjøretid til kompileringstid. For et prosjekt der tusenvis av utviklere bygger på toppen, er færre minnebugs en direkte reduksjon av driftsrisiko.

Dette er en viktig nyanse. Omskrivingen ble ikke drevet av at AI gjorde det mulig å gjøre noe gratis, men av et konkret teknisk problem som ga en målbar gevinst. AI var virkemiddelet, ikke motivasjonen. Det er akkurat den rekkefølgen norske team bør kopiere: problemet først, verktøyet etterpå.

Hva tallene forteller

Den nye Rust-porten ga blant annet 10 prosent raskere oppstart på Linux. Selve arbeidet forbrukte 5,9 milliarder ucachede input-tokens, 690 millioner output-tokens og 72 milliarder cachede input-token-lesninger. Disse tre tallene er hele kostnadsmodellen, og vi bryter dem ned lenger ned i artikkelen.

Legg merke til hva som ikke står i tallene: hvor mange mennesketimer som gikk med til å følge opp, hvor mange feilslåtte forsøk som ble kastet, og hvor mye ekstra QA som kom etterpå. 165 000 dollar er token-regningen, ikke totalkostnaden for prosjektet. Det er et skille vi kommer tilbake til, fordi det er nettopp der mange budsjetter sprekker.

Rammeverk for når en AI-drevet omskriving lønner seg

Bun-saken viser at det er mulig. Den viser ikke at det er lurt for deg. Forskjellen ligger i tre forutsetninger som alle må være oppfylt samtidig. Mangler en av dem, faller regnestykket sammen, uansett hvor overbevisende demoen ser ut.

De tre forutsetningene

Den første er en konformitetssuite: en samling tester som fanger opp når den nye koden oppfører seg annerledes enn den gamle. Uten den vet du ikke om AI-agenten har oversatt korrekt eller stille innført nye feil. Den andre er et klart definert mål: en konkret gevinst, som færre minnebugs eller lavere driftskostnad, som lar deg regne hjem investeringen. Den tredje er kapasitet til å følge opp: mennesker som kan overvåke, korrigere og godkjenne underveis.

Det er verdt å understreke at ingen av disse tre handler om selve AI-modellen. De handler om konteksten du setter modellen inn i. Modellen er den enkleste delen å skaffe. Testene, målet og oppfølgingen er det harde arbeidet, og det er der prosjekter lykkes eller feiler.

Beslutningstabell for omskriving

Tabellen under er et utgangspunkt for å vurdere om din situasjon ligner Bun-saken nok til at en AI-drevet kodeomskriving er verdt å utrede videre.

Faktor	Gunstig for AI-omskriving	Ugunstig for AI-omskriving
Testdekning	Omfattende suite som fanger avvik i oppførsel	Få eller ingen tester, mye manuell QA
Mål med omskrivingen	Konkret, målbar gevinst (minnesikkerhet, ytelse)	Diffust ønske om modernisering
Kodebasens tilstand	Vel avgrenset, godt dokumentert oppførsel	Udokumentert, sterkt koblet, uklar oppførsel
Oppfølgingskapasitet	Team som kan monitorere aktivt over tid	Ingen ledig kapasitet til daglig oppsyn
Kostnadstoleranse	Budsjett tåler sekssifret tokenregning	Ingen buffer for uforutsette token-kostnader

Ligger du overveiende i venstre kolonne, er det grunnlag for å gå videre til et pilotområde. Ligger du overveiende i høyre, er svaret sannsynligvis at du først må bygge forutsetningene, ikke starte omskrivingen.

Skille mellom omskriving og refaktorering

En omskriving bytter ut fundamentet, ofte språk eller arkitektur, mens oppførselen skal forbli lik. En refaktorering forbedrer strukturen i eksisterende kode uten å endre språket. AI-agenter er nyttige i begge, men risikoen er høyere ved omskriving fordi hele overflaten endres samtidig. De fleste norske SMB-er trenger refaktorering og opprydding, ikke en full omskriving.

Det er en billigere og mindre risikabel inngang: la agenter rydde teknisk gjeld, øke testdekning og modernisere avgrensede moduler før du i det hele tatt vurderer å bytte språk. Da bygger du samtidig nettopp den konformitetssuiten som en eventuell senere omskriving vil kreve.

Testdekning som konformitetssuite: forutsetningen som muliggjorde prosjektet

Hvis du bare tar med deg en ting fra Bun-saken, la det være denne: omskrivingen var muliggjort av en TypeScript-testsuite som fungerte som konformitetssuite. Uten den ville AI-agenten skrevet Rust-kode som kanskje kompilerte, men som ingen kunne garantere oppførte seg likt som originalen. Testene var det som gjorde forskjellen på et eksperiment og et produksjonsklart resultat.

Hva en konformitetssuite faktisk er

En konformitetssuite er et sett tester som definerer hva systemet skal gjøre, uavhengig av hvordan det er implementert. Når du skriver om fra ett språk til et annet, kjører du den samme suiten mot den nye implementasjonen. Hver test som fortsatt passerer, bekrefter at oppførselen er bevart. Hver test som feiler, peker på et avvik AI-agenten må rette.

Dette er mekanismen som gjør agentisk omskriving mulig i det hele tatt. Agenten trenger et objektivt signal på om den er på rett vei. Testsuiten gir det signalet automatisk, tusenvis av ganger, uten at et menneske må vurdere hver kodelinje manuelt. Det er forskjellen på en løp som konvergerer mot riktig svar og en som driver av garde.

Forskjellen på testdekning og konformitet

Høy testdekning målt i prosent er ikke det samme som en god konformitetssuite. Du kan ha 90 prosent linjedekning med tester som bare bekrefter at koden kjører uten å krasje, og fortsatt mangle tester som fanger opp om resultatet er riktig. Det som teller ved omskriving, er om testene faktisk verifiserer oppførsel: gitt en input, kommer riktig output.

Tabellen under skiller mellom nivåer av testmodenhet, fra minst til mest egnet for en omskriving.

Nivå	Hva det gir	Egnethet for omskriving
Ingen automatiske tester	Manuell QA, ingen sikkerhetsnett	Uegnet
Røyktester	Bekrefter at systemet starter og kjører	Utilstrekkelig
Enhetstester på deler	Fanger feil i enkeltfunksjoner	Delvis, men huller gjenstår
Bred oppførselstesting	Verifiserer input mot output over hele overflaten	God
Konformitetssuite	Definerer korrekt oppførsel uavhengig av implementasjon	Forutsetning oppfylt

Poenget er ikke tallet på toppen av dekningsrapporten. Poenget er om suiten fanger et avvik når AI-agenten introduserer et. Gjør den ikke det, er du blind akkurat når du trenger å se best.

Aluras posisjon: testdekning er forutsetningen

Vår erfaring er tydelig på dette punktet: uten en test- eller konformitetssuite som fanger avvik, er en AI-drevet omskriving for risikabel til at Alura anbefaler den. Det er ikke en teknisk detalj, det er hele grunnlaget. En agent som skriver om kode uten et objektivt oppførselssignal, produserer kode ingen kan stole på, og gevinsten forsvinner i den etterfølgende feilsøkingen.

Konsekvensen for de fleste norske team er at det første prosjektet ikke er omskrivingen. Det er å bygge suiten. Det arbeidet har verdi uansett om du noen gang skriver om noe, fordi det gjør hele kodebasen tryggere å endre. Ser du på det slik, er testsuiten en investering du uansett burde gjøre, og omskrivingen bare en av tingene den låser opp.

Slik regner du på kostnaden bak 165 000 dollar i tokens

Tallet 165 000 dollar høres enten skremmende eller overraskende lavt ut, avhengig av hva du sammenligner med. For å bruke det til noe må du forstå hva som ligger bak. Kostnaden er summen av tre typer token-forbruk med ulik pris, og forholdet mellom dem forklarer hvorfor caching er avgjørende for økonomien i agentisk arbeid.

Token-regnestykket

Tabellen viser de tre token-typene fra Bun-omskrivingen. Merk at cachede lesninger dominerer volumet, men koster langt mindre per token enn ferske input- og output-tokens.

Token-type	Volum	Rolle i kostnaden
Ucachede input-tokens	5,9 milliarder	Ny kontekst sendt til modellen, full pris
Output-tokens	690 millioner	Koden og resonnementet modellen produserer
Cachede input-token-lesninger	72 milliarder	Gjenbrukt kontekst, sterkt rabattert per token
Anslått totalkostnad	165 000 dollar	Summen ved API-priser

Forholdet mellom 72 milliarder cachede lesninger og 5,9 milliarder ferske input-tokens forteller sin egen historie. Uten prompt-caching, der modellen gjenbruker mesteparten av konteksten til rabattert pris, ville regningen vært langt høyere. Agentisk arbeid over dager fungerer økonomisk bare fordi den samme kodebasen sendes inn om og om igjen fra cache.

Caching er ikke gratis, men billigere

Når en agent jobber med en stor kodebase, må den ha hele konteksten tilgjengelig i hver runde. Å sende den på nytt til full pris hver gang ville gjort prosjekter i denne skalaen uøkonomiske. Caching lar modellen lese den samme konteksten til en brøkdel av prisen, og det er nettopp derfor de cachede lesningene utgjør det største volumet.

For deg som skal budsjettere betyr det at kostnaden ikke skalerer lineært med hvor stor kodebasen er, men med hvor mye ny kontekst og ny output som genereres. To team med like store kodebaser kan få vidt forskjellige regninger avhengig av hvor effektivt de utnytter caching og hvor mange iterasjoner agenten trenger.

Hva 165 000 dollar betyr for et norsk budsjett

Regnet om til norske kroner er dette en betydelig, men ikke uoverkommelig sum for et prosjekt som ellers ville krevd måneder med utviklerarbeid. Spørsmålet er ikke om 165 000 dollar er mye i seg selv, men hva alternativet koster. Et team som bruker et halvt år på den samme omskrivingen manuelt, bruker fort mer enn det i lønn alene, uten samme grad av testdrevet sikkerhet.

Men vær ærlig om at token-regningen er en variabel kostnad du ikke kontrollerer fullt ut på forhånd. Antall iterasjoner avhenger av kodebasens kompleksitet og testsuitens kvalitet. Sett et kostnadstak før du starter, og mål forbruket underveis, slik at prosjektet kan stoppes hvis det løper løpsk. En sekssifret dollarklasse er ikke noe du oppdager i etterkant.

Hva 11 dager med agentisk arbeid faktisk krevde av oppfølging

Fristelsen er å lese 11 dager som at man startet agenten og kom tilbake til ferdig Rust-kode. Det var ikke det som skjedde. Beskrivelsen er 11 dager med aktiv monitorering, og det ordet bærer hele forskjellen mellom vellykket agentisk arbeid og et prosjekt som stille ryker.

Aktiv monitorering, ikke fire-and-forget

Aluras posisjon her er direkte: AI-agenter fjerner ikke behovet for menneskelig oppfølging. At Bun-omskrivingen krevde 11 dagers aktiv monitorering viser at dette er styrt arbeid, ikke fire-and-forget. Noen måtte se på hva agenten gjorde, gripe inn når den gikk feil vei, og ta beslutninger som testsuiten ikke kunne ta alene.

Dette er et poeng ledere ofte undervurderer i budsjettet. Token-kostnaden er synlig og målbar. Menneskekostnaden ved å ha erfarne utviklere på aktivt oppsyn i to uker er det ikke, men den er reell. Den samlede kostnaden for et slikt prosjekt er token-regningen pluss den menneskelige oppfølgingen, ikke det ene alene.

Menneskets rolle i loopen

Mennesket i en agentisk arbeidsflyt gjør tre ting maskinen ikke gjør godt alene: setter retning når det finnes flere gyldige veier, vurderer avveininger som ikke er fanget i tester, og stopper agenten når den står fast i en uproduktiv sløyfe. Det er kvalifisert arbeid, ikke passiv overvåkning.

For norske team betyr dette at en AI-drevet omskriving ikke frigjør teamet, den flytter arbeidet fra å skrive kode til å styre og verifisere kode. Det er fortsatt en gevinst, men en annen gevinst enn den mange forestiller seg. Du trenger fortsatt dine beste folk, du bruker dem bare annerledes. Les mer om hvordan agentisk arbeid faktisk fungerer i praksis i vår guide til AI-agenter i Norge.

Hva AI-agenter gjør mulig for norske utviklingsteam

Bun er et infrastrukturprosjekt i verdensklasse med ressurser de fleste norske SMB-er ikke har. Men mekanismen bak, agenter som jobber mot en testsuite over tid, er ikke forbeholdt slike prosjekter. Spørsmålet for et norsk team er hvilke oppgaver som faktisk blir mulige når man har verktøyet, ikke om man skal kopiere Bun i skala.

Fra kodeassistent til agent

En AI-kodeassistent foreslår mens du skriver. En AI-agent tar en oppgave, planlegger, skriver, kjører tester og retter feil i sykluser til målet er nådd. Forskjellen er graden av autonomi, og det er den forskjellen som gjorde Bun-omskrivingen mulig. Assistenten hjelper en utvikler, agenten utfører et helt arbeidsstykke under oppsyn.

For team som allerede bruker kodeassistenter er steget til agentiske arbeidsflyter mindre enn det høres ut. Verktøyene er de samme leverandørene, forskjellen ligger i hvor mye du tør delegere og hvor godt sikkerhetsnettet av tester er. Uten testene fungerer ikke autonomien.

Realistiske bruksområder i SMB

De mest realistiske bruksområdene for norske SMB-er er ikke fulle språkomskrivinger, men avgrensede jobber med tydelig fasit: migrere et rammeverk til ny versjon, øke testdekning i en eldre modul, oversette en avgrenset tjeneste mellom to språk, eller rydde teknisk gjeld i en velavgrenset del av systemet. I hvert tilfelle er testsuiten det som gjør at agenten kan jobbe trygt.

Verdien ligger i å velge oppgaver der oppførselen er klar og fasiten kan automatiseres. Der scorer agenter høyt. I oppgaver med diffuse krav og ingen tester scorer de dårlig, og du bruker mer tid på å rydde etter agenten enn du sparte. Se også hvordan tilsvarende gevinster hentes ut i analysearbeid i vår artikkel om AI-drevet analyse fra data til innsikt.

Når memory-bugs og teknisk gjeld rettferdiggjør en full omskriving

En full omskriving er nesten alltid feil svar. Den er dyr, risikabel og ender ofte med at det nye systemet aldri når den kvaliteten det gamle hadde. Bun-saken er interessant fordi den har en tydelig, teknisk begrunnelse som faktisk rettferdiggjør inngrepet. Å forstå den begrunnelsen hjelper deg å se om din egen situasjon ligner, eller om du bare er lei av gammel kode.

Minnehåndtering som driver

Bun byttet språk fordi bugs i minnehåndtering var en tilbakevendende kilde til feil, og Rust adresserer nettopp den klassen problemer på språknivå. Det er en begrunnelse som gir en målbar gevinst: færre krasj, færre sikkerhetshull knyttet til minne, lavere driftsrisiko. Når en hel kategori feil forsvinner fordi språket gjør dem umulige, er det et konkret argument.

Sammenlign det med den vanligste begrunnelsen for omskriving: at koden er gammel og ubehagelig å jobbe med. Den følelsen er reell, men den gir sjelden en gevinst du kan regne hjem. Alder alene er ikke en grunn. En målbar, tilbakevendende feilklasse som språkbyttet faktisk fjerner, kan være det.

Teknisk gjeld mot omskriving

Det meste av det team kaller behov for omskriving er egentlig teknisk gjeld som kan betales ned gradvis. Gradvis nedbetaling er tryggere enn en stor omskriving fordi systemet holdes i produksjon hele tiden og hver endring er liten nok til å verifiseres. En full omskriving setter alt på spill samtidig.

Regelen er enkel: velg omskriving bare når problemet er strukturelt og ikke kan løses inkrementelt, slik minnehåndtering på språknivå ikke kan. Ellers rydder du gjeld modul for modul, gjerne med AI-agenter mot en voksende testsuite. Da får du mye av gevinsten uten å ta hele risikoen på en gang.

Risiko og vurderinger norske team må gjøre før de starter

Aluras andre posisjon er at store omskrivinger nå er teknisk mulige med AI-agenter, men at en tokenkostnad i sekssifret dollarklasse betyr at norske team må regne hjem gevinsten før de starter. Muligheten er ikke det samme som forsvarligheten. Under er risikoene du må veie før du forplikter budsjett og folk.

De sentrale risikoene

Risiko	Konsekvens hvis den treffer	Demping
Manglende konformitetstester	Skjulte oppførselsavvik når ny kode i produksjon	Bygg suiten før omskrivingen starter
Ukontrollert token-kostnad	Budsjett sprekker underveis	Sett kostnadstak og mål forbruk daglig
Undervurdert oppfølging	Prosjektet stopper når teamet mangler kapasitet	Planlegg for aktiv monitorering over hele perioden
Leverandøravhengighet	Kostnad og tilgang styres av en ekstern part	Vurder flere leverandører og exit-kostnad
Utilstrekkelig kodegjennomgang	Feil eller sikkerhetshull slipper gjennom	Menneskelig review av all AI-generert kode

Ingen av disse risikoene er argumenter mot AI-drevet omskriving som sådan. De er argumenter for å gjøre forarbeidet skikkelig. Team som hopper over forarbeidet fordi teknologien virker enkel, er nettopp de som ender med et prosjekt de ikke får i mål.

Leverandøravhengighet og kostnadskontroll

Når kjernearbeidet ditt avhenger av en ekstern AI-leverandørs priser og tilgjengelighet, tar du på deg en avhengighet du bør forstå. Prisen på tokens kan endres, og et prosjekt som var lønnsomt til en pris kan bli ulønnsomt til en annen. Regn derfor med margin, og bygg ikke en forretningskritisk prosess på en antagelse om at prisene forblir konstante.

Kostnadskontroll i praksis betyr å sette et hardt tak, måle forbruket kontinuerlig og ha en beslutning klar om når prosjektet stoppes. Uten disse tre er token-budsjettet en åpen kran. For strategiske betraktninger rundt avhengighet av AI-plattformer, se vår artikkel om AI-drevet plattformstrategi og økosystemer.

Sikkerhet og kodegjennomgang

AI-generert kode må gjennomgås av mennesker med samme alvor som kode fra en ny utvikler, kanskje strengere. Agenter kan produsere kode som passerer testene, men introduserer subtile sikkerhetsproblemer testene ikke ser etter. Konformitetssuiten fanger oppførselsavvik, ikke nødvendigvis sikkerhetssvakheter.

Praktisk betyr det at kodegjennomgang og sikkerhetstesting ikke bortfaller fordi en agent skrev koden. De blir viktigere, fordi volumet av ny kode er større og produsert raskere enn et menneske ville gjort det. Byggetempoet øker, og kvalitetssikringen må følge med i samme tempo.

Vanlige feil når team lar AI-agenter skrive om kodebasen

De vanligste feilene handler ikke om teknologien, men om planleggingen rundt den. Bun-teamet lyktes fordi forutsetningene var på plass før de startet. Team som feiler, feiler oftest på de samme tre punktene.

Å starte uten konformitetssuite

Den dyreste feilen er å slippe en agent løs på kodebasen uten et objektivt oppførselssignal. Da produserer agenten kode som ser riktig ut, kompilerer, og stille endrer oppførsel på måter ingen oppdager før det treffer produksjon. Uten suiten har du byttet en kjent kodebase mot en ukjent, og det er en dårlig bytte.

Løsningen er kjedelig og udramatisk: bygg testene først. Det føles som at du utsetter det spennende arbeidet, men det er selve arbeidet. Alt annet hviler på det.

Å undervurdere oppfølgingen

Den andre feilen er å budsjettere token-kostnaden og glemme menneskekostnaden. 11 dagers aktiv monitorering var ikke gratis, og din versjon blir det heller ikke. Team som planlegger som om agenten jobber alene, oppdager for sent at de trenger sine beste folk på aktivt oppsyn hele veien.

Planlegg for at oppfølging er en hovedkostnad, ikke en bikostnad. Da får du et realistisk budsjett og unngår å stå uten kapasitet midt i prosjektet.

Å ikke sette et kostnadstak

Den tredje feilen er å starte uten en klar grense for hva prosjektet får koste. Token-forbruk skalerer med antall iterasjoner, og antall iterasjoner er vanskelig å forutsi. Uten et tak kan en sekssifret dollarklasse vokse seg større enn planlagt før noen reagerer.

Sett taket før du starter, mål forbruket daglig, og bestem på forhånd hva som skjer hvis du nærmer deg grensen. Et prosjekt som kan stoppes kontrollert er et prosjekt du styrer. Et uten stopp-punkt styrer deg.

Praktisk sjekkliste: har kodebasen din testdekningen som trengs

Før du vurderer en AI-drevet kodeomskriving, still deg spørsmålene under. De handler alle om det samme: har du et objektivt sikkerhetsnett som lar en agent jobbe trygt, og har du kapasitet til å styre arbeidet.

Sjekklisten

Spørsmål	Hvis ja	Hvis nei
Har vi tester som verifiserer oppførsel, ikke bare at koden kjører?	Forutsetningen nærmer seg	Bygg oppførselstester først
Fanger testene et avvik når oppførselen endres?	Klar for pilot	Suiten er for svak
Har vi et konkret, målbart mål med omskrivingen?	Gevinsten kan regnes hjem	Vent til målet er tydelig
Har vi kapasitet til aktiv monitorering over tid?	Oppfølging er dekket	Frigjør folk først
Har vi satt et kostnadstak og måler forbruket?	Kostnaden er under kontroll	Sett taket før start

Fem ja betyr at du kan starte et avgrenset pilotområde. Ett eneste nei betyr at du har et forarbeid å gjøre først, og at forarbeidet er billigere å gjøre nå enn å oppdage midt i en omskriving.

Slik bygger du suiten før du starter

Begynn med de mest kritiske arbeidsflytene, ikke med høyest linjedekning. Skriv tester som beskriver hva systemet skal gjøre for brukeren, gitt en input, forvent en bestemt output. Dette er tester som overlever en omskriving fordi de er uavhengige av implementasjonen. Ironisk nok kan AI-agenter hjelpe deg å bygge nettopp denne suiten, som en langt tryggere første bruk av verktøyet enn selve omskrivingen.

Når suiten fanger avvik pålitelig, har du bygget det som skiller Bun-saken fra et mislykket eksperiment. Da, og først da, er du i posisjon til å vurdere den store jobben. Sjekk gjerne hvordan andre norske virksomheter tar i bruk AI i praksis via vår oversikt over AI-drevet konkurranseanalyse for å se modenhetsnivået i markedet.

Ofte stilte spørsmål om AI-drevet kodeomskriving

Spørsmålene under er de vi oftest møter fra norske ledere og teknologiansvarlige når Bun-saken kommer opp.

Betyr Bun-saken at vi kan skrive om vår egen kodebase billig?

Nei. Bun-omskrivingen kostet anslagsvis 165 000 dollar i tokens og krevde 11 dager aktiv monitorering. Den var mulig fordi det fantes en konformitetssuite. Din kostnad avhenger av kodebasens størrelse, testenes kvalitet og antall iterasjoner. Billig er ikke det riktige ordet, men det kan være lønnsomt hvis gevinsten er stor nok.

Hva er en konformitetssuite, og har vi en?

En konformitetssuite er tester som definerer korrekt oppførsel uavhengig av implementasjonen, slik at du kan kjøre dem mot ny kode og se om oppførselen er bevart. De fleste team har enhetstester, men færre har en suite som faktisk fanger oppførselsavvik over hele systemet. Sjekklisten lenger opp i artikkelen hjelper deg å vurdere hvor du står.

Kan vi bruke AI-agenter uten å gjøre en full omskriving?

Ja, og det er som regel det riktige stedet å begynne. Agenter er nyttige til å øke testdekning, migrere rammeverk, rydde teknisk gjeld og modernisere avgrensede moduler. Disse jobbene har lavere risiko enn en full omskriving og bygger samtidig opp testsuiten en eventuell senere omskriving vil kreve.

Hvor mye menneskelig arbeid krever en agentisk omskriving?

Mer enn mange tror. Bun-saken beskriver 11 dagers aktiv monitorering, altså kvalifiserte mennesker på aktivt oppsyn hele perioden. Arbeidet flyttes fra å skrive kode til å styre og verifisere den, men det forsvinner ikke. Regn oppfølging som en hovedkostnad i budsjettet.

Når bør vi vente med en omskriving?

Vent hvis du mangler en konformitetssuite, hvis målet er diffust, eller hvis du ikke har kapasitet til aktiv oppfølging. Vent også hvis problemet kan løses inkrementelt gjennom nedbetaling av teknisk gjeld. En full omskriving er forsvarlig først når problemet er strukturelt og gevinsten målbar, slik minnehåndteringen var for Bun.

Oppsummering: når det er rett tid å starte

Bun-saken beviser at en stor AI-drevet kodeomskriving er teknisk mulig: fra Zig til Rust på 11 dager for anslagsvis 165 000 dollar, i produksjon siden 17. juni 2026. Men den beviser noe viktigere: det som gjorde det mulig var ikke modellen, det var testsuiten som fanget avvik, det klare tekniske målet, og menneskene som fulgte opp aktivt gjennom hele perioden.

For norske team er konklusjonen edruelig. Muligheten er reell, men den hviler på et forarbeid de fleste ennå ikke har gjort. Aluras posisjon er at testdekning er forutsetningen, at en sekssifret tokenkostnad krever at gevinsten regnes hjem først, og at aktiv oppfølging ikke bortfaller fordi en agent gjør skrivearbeidet. Har du disse tre på plass, kan du vurdere den store jobben. Har du dem ikke, er det første prosjektet å bygge dem, og det arbeidet lønner seg uansett hva du bestemmer deg for etterpå.

I Alura hjelper vi norske bedrifter med å bygge AI-strategi som faktisk lar seg gjennomføre. Vi kombinerer dyp teknisk innsikt med erfaring fra alt fra SMB til enterprise, og leverer veikart som virker i praksis, ikke bare i PowerPoint.

Bestill en strategiøkt: en halvdags samtale der vi kartlegger virksomhetens AI-modenhet, identifiserer de tre prosessene med størst potensial, og leverer et konkret veikart med budsjettramme. Uforpliktende.