Den farligste agent­feilen ser ut som en vellykket kjøring

Håvard Bartnes advarer mot fellene som gjør det vanskelig å være «human in the loop».

– Jeg bygger et rammeverk for produktutvikling, og sjekker som ikke forhindret én eneste hendelse er akkurat den delen jeg har automatisert, skriver Håvard Bartnes.
Publisert

✍ leserinnlegg

Dette er et leserinnlegg fra en ekstern skribent, som betyr at innholdet ikke nødvendigvis speiler kode24s meninger. Vil du også bidra? Send oss en epost på [email protected], eller les mer her!

«Hva i huleste? Jeg var jo personen inni denne loopen.» 

Henriette Kopstad skrev det her på kode24 forrige uke. Agenten hennes hadde «lest» en fil den aldri fikk lest. Verktøyet antok derfor at fila var tom, og agenten meldte at alt gikk fint. Teknisk sett hadde den rett. Men fila var jo ikke tom. Hun fant det ved å gå gjennom systemet jobb for jobb, uka etter.

Wei Wu dokumenterte 22 slike hendelser over åtte uker i et assistentsystem med 4 286 enhetstester og 827 governance-sjekker. Den verste typen er den som later som om den gikk bra. Når agenten pakker feilen inn i en troverdig fortelling og serverer den som et vellykket resultat. Wu skriver at feilen lyver, og at den lyver godt.

To av tallene hans burde vært nevnt hver gang noen sier human-in-the-loop. 

  • 70 prosent av de stille feilene ble funnet av et menneske som så på det systemet faktisk leverte. Testene fanget ikke opp dem. 
  • Og sjekkene hadde ikke forhindret en eneste hendelse på forhånd, men hindret 87 prosent i å komme tilbake. Revisjoner er regresjonsmotorer, ikke prediksjonsmotorer.

Det funnet likte jeg dårlig. Det gir ingen av leirene rett, og aller minst min egen. 

Jeg bygger et rammeverk for produktutvikling, og sjekker som ikke forhindret én eneste hendelse er akkurat den delen jeg har automatisert.

Mennesket i loopen følger ikke med

En studie antatt på EASE 2026 gikk gjennom 33 596 pull requests skrevet av agenter:

  • 61 prosent av dem hadde ingen review-aktivitet i det hele tatt. 
  • Av kommentarene som fantes, var 72 prosent skrevet av andre agenter.

Snill purk, slem purk

Du kan gi en agent to slags instrukser, og de oppfører seg omtrent som et gammelt avhørspar.

  • Prosaen er den snille purken. CLAUDE.md, en skill, en regel du skrev ned fordi du mente det. Den setter seg ned, byr på kaffe og forklarer pent hvorfor det hadde vært lurt å kjøre testene. Den avhørte agenten nikker. Noen ganger kjører den til og med testene.
  • Hooken er den slemme purken. Den forklarer ingenting, men blokkerer døra og sier nei.

I mitt eget oppsett satt den snille purken alene lenge. Jeg var overbevist om at avhørene gikk fint.

Hva porten din spør om

Hvor mange av portene i prosjektet ditt sjekker at testene kjører? At konvensjonene følges? At formateringen er riktig, at commit-meldingene ser ut som de skal?

Og hvor mange spør hvorvidt tingen burde bygges i det hele tatt?

Ditt oppsett har jeg ingen tilgang til, så jeg søkte i alle andres. 12. august ga CLAUDE.md-filer på GitHub 751.616 treff: 

  • «Definition of done» fantes i 7.904 av dem. 
  • «Who is this for» i 65. 
  • «Why are we building» i 8.

Åtte.

Det tallet betyr kanskje ikke så mye. En fil er ikke et prosjekt. Jeg vet ingenting om de åtte. Men DORA-rapporten for 2025 peker på brukerorientering som en av sju ting som avgjør om KI-satsingen lønner seg, og kurven deres viser at de teamene som er helt uten opplever at KI gjør ting verre for dem.

Loggen min

En uke av sommeren forsvant i å skrive regler for agentoppsettet mitt, og deretter noen småskript som sjekker at reglene faktisk følges. 

Første dagen med skriptene på plass:

  • Agenten skrev en regel om å verifisere gamle påstander hver morgen, og brøt den to ganger før lunsj

  • Gjentok en bestemt feil om en bestemt person to dager etter at den hadde logget en korreksjon om nettopp det

  • Ble tatt tre ganger av samme skript, to av gangene innen tjue minutter etter at jeg skrev det

  • La en sjekk i feil mappe, der dataene den leter etter ikke finnes

  • Skrev to regex-mønstre som ikke traff sin egen utløsende setning

De to siste er mine. Mønstrene skrev jeg selv, plasseringen godkjente jeg, og en halv dag gikk med til å lete etter feil i skriptet før jeg skjønte at det bare lå feil sted.

Regelen om å verifisere gamle påstander står fortsatt i fila. Den er godt formulert. Jeg leser den av og til og synes den er fornuftig.

Wu fant at de mest seiglivede feilene lå i skjøtene mellom komponenter, der ingen test kjører. Levetiden varierte fra tretten timer til seksti dager. Om det samme gjelder skjøten mellom det vi skriver ned og det vi faktisk håndhever, vet jeg ikke. 

Men den snille purken alene holder nok ikke.

Foretrekk oss i Google Discover

Ved å legge oss til som foretrukket kilde i Google vil du blant annet få opp flere av sakene våre i Google Discover. Tusen takk for støtten!

Foretrekk oss 😻
Bygget med Labrador CMS