Når KI-agenten tar feil, rett beskrivelsen før koden

Et tenkt eksempel: et skjema godtar en dato i feil format. Utvikleren ber KI-agenten rette det, og rettingen er på plass etter få minutter. Uka etter bygger agenten et nytt skjema, og den samme feilen er tilbake.

Ingen gjorde noe galt i koden. Beskrivelsen sa aldri hvilket format som gjaldt. En agent som bygger på nytt fra samme beskrivelse, gjør samme feil igjen. Spørsmålet etter en feil er derfor ikke hvem som gjorde den, men hvilket steg som slapp den gjennom. Svaret finnes ved å gå bakover i løpet, ett steg om gangen.

Gjennomgangen er stedet feilen ble oppdaget, sjelden der den oppstod

Feilen dukker opp når noen tester skjemaet. Det er lett å tro at det er her problemet hører hjemme. Men gjennomgangen fant feilen. Den laget den ikke.

En gjennomgang som bare retter det den ser, blir en evig opprydding. Det nyttige spørsmålet er et annet: hvorfor slapp dette gjennom tidligere?

Koden gjør som regel nøyaktig det den ble bedt om

Ser man på koden, følger den instruksen. Agenten fikk ikke vite at datoen skulle ha et bestemt format, så den valgte et selv.

Å lappe koden alene løser dagens feil. Neste bygg fra den samme beskrivelsen tar den med seg tilbake. En kodeendring uten en endring lenger opp er en retting som må gjentas.

En plan uten grensetilfeller lar feilen gå rett igjennom

Planen beskriver hva skjemaet skal gjøre når alt går som forventet. Den sier lite om tomme felt, datoer skrevet på ulike måter eller filer som er større enn vanlig.

Det er i slike kanter feil gjerne bor. Finnes ikke grensetilfellet i planen, finnes det heller ikke i koden. Mangler det, er det planen som må få en linje til.

Spesifikasjonen er der de fleste feil kan stoppes

Spesifikasjonen sa at skjemaet skulle ta imot en dato. Den sa ikke hvilken. Et ønske som «brukervennlig dato» kan ikke sjekkes. Et krav som «datoen skrives som dag, måned, år» kan sjekkes med ja eller nei.

Krav som kan besvares med ja eller nei, gir agenten noe å bygge mot og gjennomgangen noe å sjekke mot. Det bygger på tanken om at hvert steg etterlater noe som kan leses, beskrevet i Når agenten skriver koden. Rettes kravet her, rettes alle senere bygg samtidig.

Noen feil sitter i selve ideen

Av og til er beskrivelsen presis, planen grundig og koden riktig, og resultatet er likevel feil. Oppgaven var formulert feil fra starten. Kanskje trengte ikke brukerne et nytt skjema i det hele tatt.

Da hjelper ingen kodeendring. Det som må rettes, er spørsmålet løpet startet med. Det er det dyreste stedet å finne en feil, og det viktigste.

Rett der feilen kom inn, så forsvinner den fra neste kjøring

Når beskrivelsen rettes, blir neste kjøring riktig av seg selv. Det er fordelen med et løp som kan gjentas: en retting oppstrøms virker hver gang løpet kjøres. Tanken er beskrevet i AI-fabrikken som idé.

Regelen er enkel: når en KI-agent tar feil, spor feilen bakover og rett den i steget der den kom inn, ikke der den ble oppdaget.

Se hvordan Xala bygger fagsystemer med testbare leveranser.

Vanlige spørsmål

Hvorfor gjør en KI-agent samme feil flere ganger? Fordi den bygger fra samme beskrivelse hver gang, og feilen står fortsatt der.

Skal man rette koden eller spesifikasjonen når en KI-agent tar feil? Begge kan trenges, men spesifikasjonen må rettes for at feilen ikke skal komme tilbake.

Hva er en rotårsak i systemutvikling? Steget der feilen kom inn i løpet, ikke stedet i løpet der feilen ble oppdaget.

Kan kodegjennomgang alene fange feil fra KI-agenter? Den fanger mye, men den oppdager feil etter at de er laget. Den forhindrer dem ikke.

Hva bør en IT-leder spørre en leverandør som bruker KI-agenter? Hvordan feil spores tilbake i løpet, og i hvilket steg rettingen faktisk skjer.