Hvorfor AI-kodingen din sannsynligvis ikke fungerer (og hva du faktisk kan gjøre med det)

La meg male et bilde. Klokken er 23. Du har en feature som skal leveres, og du har holdt på med en AI-kodingassistent i den siste timen. Hver prompt får et svar. Hvert svar blir limt inn. Noe av det fungerer. Noe av det fungerer ikke. Du er ikke helt sikker på hva som er hva.

Lurer på om dette høres kjent ut?

Her er det ubehagelige faktum: de fleste utviklere bruker AI-agenter på samme måte som du ville brukt en kalkulator hvis du selv måtte trykke på knappene. Jo, den regner. Nei, du har ingen anelse om hva som skjer inni der. Og når den uunngåelig gir deg noe som høres plausibelt ut men er subtil feil, er det du som må feilsøke klokken 23.

Teamene som faktisk leverer ekte produksjonskode med AI har skjønt noe annet. De har sluttet å tenke på AI-assistanse som et prompt-og-svar-spill. I stedet bygger de systemer — looper — som lar AI gjøre små, trygge, verifiserbare endringer kontinuerlig. Resultatene snakker for seg selv: færre regresjoner, mindre kontekst-overløp, og faktisk lesbare diffs.

Problemet med "alt i ett"

Det er en forførende enkelthet ved one-shot prompting. "Lag meg et brukerautentiseringssystem." Ferdig. "Refaktorer hele denne modulen til å bruke den nye API-en." Bang. Det føles produktivt. Det føles raskt.

Hel til det ikke gjør det.

Tenk på hva som faktisk skjer når du kaster en stor oppgave på en AI i ett skudd. Først treffer du kontekstveggen. De fleste kodebaser verdt å jobbe med er for store til å få plass i AI-ens minne. Så den begynner å gjette på delene den ikke kan se — tar forutsetninger om avhengigheter, navnekonvensjoner, arkitekturmønstre som kanskje er helt feil.

Deretter kommer gjennomgangsproblemet. Hvis AI-en returnerer en 500-linjers diff, hva gjør du egentlig med det? Du skummer den. Du stoler på den mer enn du bør fordi AI-en virker sikker. Du merger den og håper.

Her er greia med håp: det er ikke en kvalitetskontrollprosess.

Det tredje problemet er den snikeste. AI-modeller er trent til å være hjelpsomme, noe som betyr at de er trent til å virke selvsikre. Når en AI gir deg kode som ser fornuftig ut, ser den sannsynligvis fornuftig ut fordi den er trent på fornuftig kode. Det betyr ikke at den er korrekt for din spesifikke kontekst. Uten en port som sjekker faktisk oppførsel, blir selvtillit ditt eneste akseptkriterium — og selvtillit er en forferdelig måler for korrekthet.

Inn i loopen

Alternativet høres nesten skuffende enkelt ut: i stedet for én stor prompt, gjør mange små steg. Etter hvert steg, sjekk arbeidet ditt. Deretter gjør du neste steg.

Handle. Sjekk. Gjenta.

Det er en agentic loop i sin mest grunnleggende form, og hvis det høres nesten for åpenbart ut til å være verdt å diskutere, tenk på at de fleste teamene fremdeles ikke gjør det. Magien er ikke i konseptet — det er i disiplineringen av å håndheve det rigorøst.

Her er hva det ser ut som i praksis. I stedet for å be AI-en om å "fikse alle de feilende testene", ville du:

1. Kjør testpakken og identifiser den første feilen
2. Be AI-en om å fikse bare den ene feilen
3. Kjør testene igjen for å verifisere fiksen
4. Hvis den passerer, gå videre til neste feil; hvis den feiler, blir endringen revertet
5. Gjenta til null feil — eller til AI-en rapporterer at den ikke kan gjøre fremgang

Legg merke til hva som skjer her. Hver endring er uavhengig verifisert. Når noe går i stykker, vet du nøyaktig hvilken redigering som forårsaket det. Når noe fungerer, blir det værende. Loopen bygger en rigg av verifisert fremgang i stedet for en haug av håpefullt-korrekt kode.

De tre reglene som får det til å fungere

Ikke alle looper er like. En dårlig designet loop er verre enn ingen loop i det hele tatt — den kan kjøre for alltid og gjøre kosmetiske endringer, eller den kan være selvsikker på å ødelegge ting mens den ser ut til å jobbe. Looper som faktisk leverer har tre ikke-forhandlingsbare egenskaper.

Først: en automatisert port som ikke lar seg overtales. Porten er din sannhetsdetektor. Det kan være en testpakke som passerer, en linter som returnerer null feil, en type-sjekker som bekrefter ingen type-mismatch, eller en automatisert skjermdump-sammenligning som fanger visuelle regresjoner. Det kritiske punktet er at porten er deterministisk og objektiv. Du kan ikke prate deg forbi den, og det kan heller ikke AI-en. Hvis koden ikke passerer porten, skjedde det ikke — revertet, ikke merga.

Dette er hardere enn det høres ut fordi det betyr å forplikte seg til å bygge infrastrukturen for portene dine. Du trenger ekte tester med ekte dekning. Du trenger type-sjekkeren din til faktisk å kjøre. Du trenger at CI/CD-pipelinen er en førsteklasses borger, ikke en ettertanke.

Andre: én endring per iterering. Dette føles smerkelig tregt når du er vant til one-shot prompting. Hvorfor ikke fikse alle type-feilene på en gang? Hvorfor ikke adressere hver lintadvarsel i én runde?

Fordi når du grupperer endringer sammen og noe går i stykker, har du ingen anelse om hva som forårsaket det. AI-en kan fikse tre ting, ødelegge én, og det samlede resultatet ser positivt ut — så endringen blir merga. Nå har du en regresjon uten klar gjerningsmann.

Én endring, én verifisering, én dom. Det er tregere per steg, men det er monumentalt raskere totalt fordi hvert steg er uavhengig gjennomgåbart og revertbart. Når noe går i stykker i produksjon, kjører du git bisect til den eksakte endringen som forårsaket det i stedet for å feilsøke et halvferdig rot av sammenkoblede modifikasjoner.

Tredje: en ærlig stoppbetingelse. En loop uten en stoppbetingelse er enten uendelig eller stopper vilkårlig. Begge deler er dårlig. Stoppbetingelsen bør være et målbart signal: testantall som når null, en "ingenting å forbedre"-rapport i flere runder, en evalueringsskår som flater ut.

Disiplinen her er å akseptere ærlige hopp over. Når koden faktisk er god, er det korrekte outputtet "forandret ingenting — ingenting trengte å forandres." En loop som vet når den er ferdig er verdt ti som bare fortsetter å male ut marginale endringer for å virke produktive.

Hva looper fanger som prompter går glipp av

La meg gi deg et konkret eksempel på hvorfor dette betyr noe.

Tenk deg en selvforbedringsloop som kjører på et produksjons adminkontrollpanel. Loopen tar skjermdumper av hver side, ber AI-en identifisere og fikse én brukbarhetsproblemer per runde, kjører type-sjekk og linting, og fortsetter til den ikke finner noe mer å forbedre.

Over flere runder produserer denne loopen dusinvis av genuine forbedringer. Pen UI-polering. Bedre feilmeldinger. Smartere tomtilstander.

Men den mest verdifulle fiksen var ikke en polering — det var en bug. Én runde, skjermdumphardverket flagga at en innstillingsside renderte frameworkets fullside-krasjskjerm. Greia er: dette krasjet var fullstendig klientside. API-helsesjekkene hadde vært grønne hele tiden fordi API-en var fin. Et menneske som gjennomgikk skjermdumper kunne ha scrolla forbi akkurat den siden eller antatt at det var en forbigående renderingsglitch.

Den automatiserte loopen fanget den, ekstraherte den faktiske feilen ("Cannot read properties of undefined (reading 'memes')"), sporet den til en state-merge-bug i komponentlivssyklusen, og fikset den ved roten. Og fordi hardverket nå vet å se etter det krasjskjermmønsteret, vil det fange hele den klassen av bugs for alltid.

Det er utbetalingen. En loop gjør ikke bare arbeid — den bygger en rigg som akkumulerer verifiserte forbedringer og forhindrer verifiserte regresjoner fra å komme tilbake.

Hvorfor dette betyr noe for teamet ditt

Hvis du bygger en startup, har du ikke tid til AI-verktøy som krever konstant barnepike. Hvis du er utvikler, har du ikke tålmodighet for verktøy som introduserer flere bugs enn de fikser.

Agentic looper adresserer begge bekymringene. De gjør AI-assistanse genuine pålitelig ved å erstatte tillit med verifisering. De gjør fremgang målbar ved å gjøre hver endring ansvarlig. De gjør feilsøking håndterbar ved å sikre at når noe går i stykker, vet du nøyaktig når og hvorfor.

Det beste? Denne tilnærmingen er ikke begrenset til kodegenerering. Samme mønster fungerer for automatisert testing, bug-jakt, sikkerhetsskanning, dokumentasjonsoppdateringer, avhengighetsadministrasjon — overalt du har brukt one-shot prompter der du hadde hatt nytte av kontinuerlig verifisering.

Enten du jobber alene eller administrerer et team, er spørsmålet ikke om du skal bruke AI for koding. Spørsmålet er om du bruker det på en måte som faktisk gjør deg raskere — eller bare får deg til å føle deg opptatt mens du akkumulerer teknisk gjeld.

Looper er ikke den eneste måten å jobbe med AI på. Men de er den eneste måten jeg har sett som skalerer til seriøs produksjonsbruk uten å akkumulere en gravplass av plausibelt-men-feil kode.

Din tur.