Vibe coding har ændret, hvem der kan producere en applikation, der ser ud til at fungere. En prompt kan generere skærmbilleder, forbinde en API og samle et plausibelt workflow, før et traditionelt udviklingsteam har afsluttet sin første designgennemgang.

Den hastighed skaber et nyt problem for ansættelse og levering: En demo er ikke længere stærkt bevis på, at software er god. Arbejdsgivere vil i stigende grad stille et sværere spørgsmål: Kan dette AI-byggede system opføre sig korrekt, når input er rodede, afhængigheder fejler, brugere gentager handlinger, og den underliggende model ændrer sig?

Svaret vil komme fra en kvalitetsstandard, der minder mindre om visuel finish og mere om disciplineret softwareverifikation. De mennesker, der skiller sig ud, vil ikke blot vise, hvad et AI-kodeværktøj har produceret. De vil vise, hvordan de testede det, hvad det ikke sikkert kan gøre, og hvordan de ved, at en ændring ikke ødelagde noget andet.

Et benchmark er evidens, ikke en ranglistescore

Open source-benchmarks for kodeagenter tilbyder nyttige udgangspunkter, men de måler forskellige evner. SWE-bench bruger virkelige GitHub-issues og snapshots af repositories, hvilket gør det relevant for vedligeholdelsesarbejde. Terminal-Bench tester interaktion via kommandolinjen. Andre nævnte benchmarks, herunder SlopCodeBench og ProgramBench, fokuserer på forskellige aspekter af genereret kode og agentadfærd.

Disse benchmarks kan hjælpe med at sammenligne værktøjer eller etablere en baseline, men arbejdsgivere bør være forsigtige med at betragte en enkelt score som bevis på produktionsparathed. En model, der løser problemer i repositories, kan stadig producere usikker autorisationslogik. En agent, der gennemfører terminalopgaver, kan fejle i at bevare tilstanden gennem et langt workflow. En poleret webapplikation kan bestå en happy-path-demo, mens den håndterer retries eller duplikerede betalinger forkert.

En troværdig portefølje eller intern gennemgang bør derfor indeholde et opgavespecifikt evalueringssæt. Sættet kan indeholde repræsentative fejlrapporter, normale brugerrejser, fejlformaterede input, tilladelsesgrænser, fejlende afhængigheder og tidligere rettede regressioner. Hver sag bør have et eksplicit forventet resultat, ikke blot et skærmbillede, der ser rigtigt ud.

Den minimale testpakke til AI-bygget software

For en lille applikation kan en nyttig kvalitetspakke bygges uden et omfattende forskningslaboratorium:

  • Acceptancetests: verificerer den brugersynlige adfærd for de vigtigste workflows, herunder vellykkede og mislykkede resultater.
  • Enheds- og integrationstests: kontrollerer forretningsregler isoleret og bekræfter, at databaser, API'er, køer og autentificering fungerer sammen efter hensigten.
  • Negative tests: sender manglende, fejlformaterede, for store, duplikerede og uautoriserede input. AI-genereret kode ser ofte stærkest ud på den sti, der vises i prompten, så de uanmodede stier er vigtige.
  • Regressionstests: gør enhver opdaget fejl til en permanent test. En grøn demo efter en rettelse er ikke nok, hvis den samme fejl kan vende tilbage i den næste genererede ændring.
  • Sikkerhedstjek: tester adgangskontrol, håndtering af hemmeligheder, beskyttelse mod injection, sårbarheder i afhængigheder, og om indhold, man ikke har tillid til, kan påvirke værktøjskald eller privilegerede handlinger.
  • Driftskontroller: verificerer timeouts, retries, idempotens, logning, alarmer og sikker adfærd, når en afhængighed ikke er tilgængelig.

Dette ligger tæt på den QA-engineering-tankegang, der beskrives i Stack Overflows beretning om en agentisk softwareudviklingslivscyklus. Det vigtige skift er kulturelt: Kvalitetssikring er ikke en afsluttende inspektion, efter at en AI har skrevet koden. Det er den struktur, der gør hurtig generering tilstrækkeligt sikker at bruge.

Test orkestreringen, ikke kun outputtet

Når software indeholder en AI-agent, er almindelige applikationstests nødvendige, men utilstrækkelige. Systemet kan fejle, fordi modellen misforstod en anmodning, men det kan også fejle, fordi den omgivende orkestrering mistede kontekst, kaldte et værktøj to gange, accepterede fejlformateret struktureret output eller aldrig afsluttede.

Digestens anbefalede områder for regression før implementering er en praktisk tjekliste: tab af kontekst, værktøjsidempotens, prompt injection, struktureret output, manglende afslutning, retrieval-forankring og gendannelse af tilstand. Dette er testbare tekniske egenskaber.

En test kan for eksempel køre den samme anmodning to gange og bekræfte, at det andet forsøg ikke opretter en duplikeret ordre. En anden kan afbryde en agent midt i et workflow, genstarte den og verificere, at den genoptager fra en gyldig tilstand i stedet for at gentage en irreversibel handling. En retrieval-test kan kræve, at systemet kun citerer eller returnerer oplysninger fra et godkendt kildesæt. En test af struktureret output kan levere et ugyldigt svar og bekræfte, at applikationen afviser det sikkert i stedet for stiltiende at behandle det som gyldige data.

Langvarige systemer og multiagentsystemer har især brug for tydelige fejlregistre. Forskere arbejder på automatiseret fejlattribution, fordi det kan være vanskeligt at identificere, hvilken agent der forårsagede en fejl, og på hvilket tidspunkt i en lang interaktionskæde det skete. I praksis bør teams bevare værktøjskald, input, output, modelversioner, tidsstempler, tilstandsovergange og endelige beslutninger i et privatlivsbevidst revisionsspor. Uden denne evidens fortæller en rød test dig, at noget fejlede, men ikke hvor du skal begynde at rette det.

Reproducerbarhed bliver en karrierefordel

AI-genereret kode varierer. En ny kørsel kan producere en anden implementering; en modelopdatering kan ændre adfærden; et leverandørudfald kan ændre routing eller latenstid. Arbejdsgivere vil derfor værdsætte kandidater, der kan gøre evalueringer reproducerbare.

Det betyder at fastlåse modelsnapshots, hvor det er muligt, registrere prompts og konfiguration, kontrollere tilfældighed, når platformen tillader det, og køre flere forsøg for opgaver, hvis resultater varierer. Digesten peger specifikt på fastlåste snapshots, lav eller nul temperatur, hvor det er tilgængeligt, samt CI/CD-gates med konfidensgrænser som nyttige sikkerhedsforanstaltninger.

En praktisk rapport bør som minimum skelne mellem tre resultater:

  1. Beståelsesrate: hvor mange tilfælde der lykkedes.
  2. Konsistens: hvor ofte det samme tilfælde lykkes ved gentagne kørsler.
  3. Alvorlighed: om fejl er kosmetiske, besværlige, skadelige for data, sikkerhedsrelevante eller kan forårsage en usikker ekstern handling.

Et system, der består 19 ud af 20 lavrisikotjek af formatering, er ikke nødvendigvis bedre end et, der består 18 ud af 20 tilfælde, men aldrig overskrider en autorisationsgrænse. Kvalitetskravet skal vægte fejl efter deres konsekvenser.

Menneskelig gennemgang bør målrettes risiko, ikke hver eneste linje

Formålet med bedre automatisering er ikke at tvinge en person til at genlæse hvert eneste token, som en AI producerer. Det er at rette menneskelig opmærksomhed mod de beslutninger, som test ikke fuldt ud kan afgøre.

Gennemgåere bør fokusere på autentificering og autorisation, dataopbevaring, økonomiske eller kontraktmæssige handlinger, privatliv, migreringer, fejlhåndtering, tredjepartstilladelser og ændringer, der påvirker selve systemets evalueringsmiljø. For en agent bør de også gennemgå, hvilke værktøjer den må kalde, hvilke data hvert værktøj har adgang til, og om der kræves godkendelse før en irreversibel handling.

Synlige diff-visninger, godkendelsesarbejdsgange, arkiverede samtaler og revisionslogge – funktioner, der fremhæves i Slack Codes beskrivelse af kollaborativ AI-kodning – peger mod en bredere forventning: Historikken for, hvordan software blev skabt, vil få betydning. En gennemgår bør kunne forstå anmodningen, inspicere den genererede ændring, se testdokumentationen og identificere, hvem der godkendte udrulningen.

Den registrering er ikke bureaukrati for bureaukratiets egen skyld. Den gør det muligt at skelne en imponerende demo fra en kontrolleret ændring, som en anden person kan vedligeholde.

Hvad du bør medtage i en portefølje eller til en jobsamtale

For kandidater er den stærkeste demonstration et lille system med en bevidst synlig kvalitetsfortælling. Medtag repositoryet, opsætningsinstruktioner, arkitekturnoter, testkommandoer, repræsentative testtilfælde, kendte begrænsninger og en kort fejlrapport. Vis en eller to fejl, der blev fundet og omsat til regressionstest. Forklar, hvilken model eller kodningsagent der blev brugt, uden at fremstille værktøjet som ophavsmanden til de tekniske beslutninger.

Hvis applikationen bruger en agent, skal du dokumentere værktøjstilladelser, tilstandsmodel, politik for gentagne forsøg, afslutningsbetingelse og punkter, hvor menneskelig godkendelse kræves. Hvis den bruger informationssøgning, skal du vise, hvordan kilder udvælges, og hvad der sker, når dokumentation mangler. Hvis den kalder eksterne tjenester, skal du demonstrere adfærden ved timeout og dublerede anmodninger.

Påstå ikke pålidelighed ud fra én enkelt vellykket optagelse. En efterprøvbar påstand lyder snarere: “På tværs af 30 registrerede kørsler af disse 12 scenarier opfyldte systemet acceptkriterierne i 28; de to fejl involverede tvetydig datoindtastning, og begge er dokumenteret.” Selve tallet er mindre vigtigt end metoden, grænserne og ærligheden om, hvad der stadig ikke er testet.

Den nye definition af hurtigt

AI sænker omkostningen ved at producere en første version. Den fjerner ikke omkostningen ved at vide, om den version fortjener tillid. Faktisk kan hurtigere generering gøre evaluering vigtigere, fordi flere ugennemgåede ændringer kan nå at samle sig mellem udrulninger.

Den professionelle i tiden efter vibe-kodning vil blive bedømt på arbejdsgangen: definér adfærd, generér eller ændr kode, test realistiske og kontradiktoriske tilfælde, inspicér beslutninger med høj risiko, registrér fejl, og forbedr systemet uden at miste dokumentationen. Benchmarks kan hjælpe med at sammenligne kapacitet. QA-praksisser afgør, om denne kapacitet bliver til pålidelig software.

Kvalitetskravet er derfor ikke: “Kan du lave en app med AI?” Det er: “Kan du bevise, hvad appen gør, opdage når den holder op med at gøre det, og udforme de begrænsninger, der forhindrer en fejl i at blive til en hændelse?”