Vibe-koding har endret hvem som kan lage en applikasjon som ser ut til å fungere. En prompt kan generere skjermer, koble til et API og sette sammen en plausibel arbeidsflyt før et tradisjonelt utviklingsteam er ferdig med sin første designgjennomgang.

Denne hastigheten skaper et nytt problem for ansettelser og leveranser: En demo er ikke lenger et sterkt bevis på at programvaren er god. Arbeidsgivere vil i økende grad stille et vanskeligere spørsmål: Kan dette AI-byggede systemet oppføre seg korrekt når inndataene er rotete, avhengigheter svikter, brukere gjentar handlinger og den underliggende modellen endres?

Svaret vil komme fra en kvalitetsstandard som ligner mindre på visuell finpuss og mer på disiplinert programvareverifisering. De som skiller seg ut, vil ikke bare vise hva et AI-kodeverktøy produserte. De vil vise hvordan de testet det, hva det ikke kan gjøre på en trygg måte, og hvordan de vet at en endring ikke ødela noe annet.

En referansetest er dokumentasjon, ikke en poengsum på en resultatliste

Referansetester for åpen kildekode-baserte kodeagenter gir nyttige utgangspunkter, men de måler ulike evner. SWE-bench bruker reelle GitHub-problemer og øyeblikksbilder av repositorier, noe som gjør den relevant for vedlikeholdsarbeid. Terminal-Bench tester kommandolinjeinteraksjon. Andre oppførte referansetester, blant annet SlopCodeBench og ProgramBench, retter seg mot andre sider ved generert kode og agentatferd.

Disse referansetestene kan bidra til å sammenligne verktøy eller etablere en grunnlinje, men arbeidsgivere bør være forsiktige med å behandle en enkelt poengsum som bevis på at noe er klart for produksjon. En modell som løser problemer i repositorier, kan fortsatt produsere usikker autorisasjonslogikk. En agent som fullfører terminaloppgaver, kan mislykkes med å bevare tilstanden gjennom en lang arbeidsflyt. En polert webapplikasjon kan bestå en happy-path-demo, samtidig som den håndterer nye forsøk eller doble betalinger feil.

En troverdig portefølje eller intern gjennomgang bør derfor inneholde et oppgavespesifikt evalueringssett. Settet kan inneholde representative feilrapporter, normale brukerreiser, ugyldige inndata, tillatelsesgrenser, feil i avhengigheter og tidligere rettede regresjoner. Hvert tilfelle bør ha et eksplisitt forventet resultat, ikke bare et skjermbilde som ser riktig ut.

Den minimale testpakken for AI-bygd programvare

For en liten applikasjon kan man sette sammen en nyttig kvalitetspakke uten et omfattende forskningslaboratorium:

  • Akseptansetester: verifiserer den bruker synlige atferden i de viktigste arbeidsflytene, inkludert vellykkede og mislykkede utfall.
  • Enhets- og integrasjonstester: kontrollerer forretningsregler isolert og bekrefter at databaser, API-er, køer og autentisering fungerer sammen som tiltenkt.
  • Negative tester: sender manglende, feilformaterte, for store, dupliserte og uautoriserte inndata. AI-generert kode ser ofte sterkest ut på stien som vises i prompten, så de ikke-etterspurte stiene er viktige.
  • Regresjonstester: gjør hver oppdagede feil om til en permanent test. En grønn demo etter en rettelse er ikke nok hvis den samme feilen kan komme tilbake i den neste genererte endringen.
  • Sikkerhetskontroller: tester tilgangskontroll, håndtering av hemmeligheter, beskyttelse mot injeksjoner, sårbarheter i avhengigheter og om innhold man ikke stoler på, kan påvirke verktøykall eller privilegerte handlinger.
  • Operasjonelle kontroller: verifiserer tidsavbrudd, nye forsøk, idempotens, logging, varsler og trygg atferd når en avhengighet ikke er tilgjengelig.

Dette ligger nært QA-utviklingstankegangen som beskrives i Stack Overflows omtale av en agentisk livssyklus for programvareutvikling. Det viktige skiftet er kulturelt: Kvalitetssikring er ikke en avsluttende inspeksjon etter at en AI har skrevet koden. Det er strukturen som gjør rask generering trygg nok til å brukes.

Test orkestreringen, ikke bare resultatet

Når programvaren inneholder en AI-agent, er vanlige applikasjonstester nødvendige, men ikke tilstrekkelige. Systemet kan mislykkes fordi modellen misforsto en forespørsel, men det kan også mislykkes fordi den omkringliggende orkestreringen mistet kontekst, kalte et verktøy to ganger, godtok feilformatert strukturert utdata eller aldri avsluttet.

Sammendragets anbefalte områder for regresjonstesting før produksjonssetting er en praktisk sjekkliste: tap av kontekst, verktøyidempotens, promptinjeksjon, strukturert utdata, manglende avslutning, forankring i innhentet informasjon og gjenoppretting av tilstand. Dette er testbare tekniske egenskaper.

En test kan for eksempel kjøre den samme forespørselen to ganger og bekrefte at det andre forsøket ikke oppretter en duplikatordre. En annen kan avbryte en agent midt i en arbeidsflyt, starte den på nytt og kontrollere at den gjenopptar arbeidet fra en gyldig tilstand i stedet for å gjenta en irreversibel handling. En test av innhentet informasjon kan kreve at systemet bare siterer eller returnerer informasjon fra et godkjent kildesett. En test av strukturert utdata kan tilføre et ugyldig svar og bekrefte at applikasjonen avviser det på en trygg måte i stedet for å behandle det som gyldige data uten å si fra.

Langvarige systemer og systemer med flere agenter trenger spesielt tydelige feillogger. Forskere arbeider med automatisert feilattribusjon fordi det kan være vanskelig å identifisere hvilken agent som forårsaket en feil, og på hvilket tidspunkt i en lang interaksjonskjede det skjedde. I praksis bør team bevare verktøykall, inndata, utdata, modellversjoner, tidsstempler, tilstandsoverganger og endelige beslutninger i et personvernbevisst revisjonsspor. Uten disse bevisene forteller en rød test deg at noe feilet, men ikke hvor du bør begynne å rette det.

Reproduserbarhet blir et karrierefortrinn

AI-generert kode varierer. En ny kjøring kan produsere en annen implementasjon; en modelloppdatering kan endre atferden; et leverandørutfall kan endre ruting eller latenstid. Arbeidsgivere vil derfor verdsette kandidater som kan gjøre evalueringer repeterbare.

Det betyr å låse modelløyeblikksbilder der det er mulig, registrere prompter og konfigurasjon, kontrollere tilfeldigheten når plattformen tillater det og kjøre flere forsøk for oppgaver der resultatene varierer. Sammendraget peker spesifikt på låste øyeblikksbilder, lav eller null temperatur der det er tilgjengelig, og CI/CD-porter med konfidensgrenser som nyttige sikkerhetstiltak.

En praktisk rapport bør skille mellom minst tre resultater:

  1. Beståttprosent: hvor mange tilfeller som lykkes.
  2. Konsistens: hvor ofte det samme tilfellet lykkes i gjentatte kjøringer.
  3. Alvorlighetsgrad: om feilene er kosmetiske, upraktiske, skadelige for data, relevante for sikkerheten eller kan føre til en utrygg ekstern handling.

Et system som består 19 av 20 lavrisikotester av formatering, er ikke nødvendigvis bedre enn et som består 18 av 20 tilfeller, men aldri krysser en autorisasjonsgrense. Kvalitetskravet må vekte feil etter konsekvens.

Menneskelig gjennomgang bør rettes mot risiko, ikke hver eneste linje

Formålet med bedre automatisering er ikke å tvinge en person til å lese hvert eneste token som produseres av en KI på nytt. Det er å rette menneskelig oppmerksomhet mot beslutningene som tester ikke kan avklare fullt ut.

Gjennomgåere bør fokusere på autentisering og autorisasjon, oppbevaring av data, økonomiske eller kontraktsmessige handlinger, personvern, migreringer, feilgjenoppretting, tillatelser for tredjeparter og endringer som påvirker systemets eget evalueringsrammeverk. For en agent bør de også gjennomgå hvilke verktøy den kan kalle, hvilke data hvert verktøy har tilgang til, og om godkjenning kreves før en irreversibel handling.

Synlige differanser, godkjenningsflyter, arkiverte samtaler og revisjonslogger – funksjoner som fremheves i Slack Codes beskrivelse av samarbeidende KI-koding – peker mot en bredere forventning: Historikken over hvordan programvaren ble laget, vil ha betydning. En gjennomgåer bør kunne forstå forespørselen, inspisere den genererte endringen, se testbevisene og identifisere hvem som godkjente utrullingen.

Denne dokumentasjonen er ikke byråkrati for byråkratiets egen skyld. Den gjør det mulig å skille en imponerende demo fra en kontrollert endring som en annen person kan vedlikeholde.

Hva du bør ta med i en portefølje eller på et intervju

For kandidater er den sterkeste demonstrasjonen et lite system med en bevisst synlig kvalitetshistorie. Ta med repositoriet, instruksjoner for oppsett, arkitekturnotater, testkommandoer, representative testtilfeller, kjente begrensninger og en kort feilrapport. Vis én eller to feil som ble funnet og omgjort til regresjonstester. Forklar hvilken modell eller kodeagent som ble brukt, uten å fremstille verktøyet som opphavspersonen til de tekniske beslutningene.

Hvis applikasjonen bruker en agent, bør du dokumentere verktøytillatelsene, tilstandsmodellen, strategien for nye forsøk, termineringsbetingelsen og punktene der mennesker må godkjenne. Hvis den bruker informasjonsinnhenting, bør du vise hvordan kildene velges, og hva som skjer når dokumentasjon mangler. Hvis den kaller eksterne tjenester, bør du demonstrere hvordan tidsavbrudd og dupliserte forespørsler håndteres.

Ikke påstå at systemet er pålitelig basert på ett enkelt vellykket opptak. En etterprøvbar påstand høres mer ut som: «I løpet av 30 dokumenterte kjøringer av disse 12 scenariene oppfylte systemet akseptansekriteriene i 28; de to feilene gjaldt tvetydige datoinndata, og begge er dokumentert.» Selve tallet er mindre viktig enn metoden, grensene og ærligheten om hva som fortsatt ikke er testet.

Den nye definisjonen av rask

KI reduserer kostnadene ved å produsere en første versjon. Den fjerner ikke kostnadene ved å vite om denne versjonen fortjener tillit. Faktisk kan raskere generering gjøre evaluering viktigere, fordi flere endringer som ikke er gjennomgått, kan hope seg opp mellom utrullinger.

Den profesjonelle utvikleren etter vibe-koding vil bli vurdert etter løkken: definere atferd, generere eller endre kode, teste realistiske og kontradiktoriske tilfeller, inspisere beslutninger med høy risiko, registrere feil og forbedre systemet uten å miste dokumentasjonen. Referansetester kan bidra til å sammenligne egenskaper. Kvalitetssikringspraksis avgjør om disse egenskapene blir til pålitelig programvare.

Kvalitetskravet er derfor ikke «Kan du lage en app med KI?» Det er «Kan du bevise hva appen gjør, oppdage når den slutter å gjøre det, og utforme grensene som hindrer at en feil blir en hendelse?»