Vibe coding har förändrat vilka som kan skapa en applikation som ser ut att fungera. En prompt kan generera skärmbilder, ansluta ett API och sätta samman ett plausibelt arbetsflöde innan ett traditionellt utvecklingsteam har avslutat sin första designgranskning.

Den hastigheten skapar ett nytt problem för rekrytering och leverans: en demo är inte längre starka bevis på att programvara är bra. Arbetsgivare kommer i allt högre grad att ställa en svårare fråga: kan det här AI-byggda systemet bete sig korrekt när indata är röriga, beroenden slutar fungera, användare upprepar åtgärder och den underliggande modellen förändras?

Svaret kommer att bygga på en kvalitetsnivå som liknar disciplinerad programvaruverifiering mer än visuell finslipning. De som utmärker sig kommer inte bara att visa vad ett AI-kodverktyg producerade. De kommer att visa hur de testade det, vad det inte kan göra på ett säkert sätt och hur de vet att en ändring inte har förstört något annat.

Ett benchmark är bevis, inte en topplistepoäng

Benchmarktester av kodningsagenter med öppen källkod erbjuder användbara utgångspunkter, men de mäter olika förmågor. SWE-bench använder verkliga GitHub-ärenden och ögonblicksbilder av kodarkiv, vilket gör det relevant för underhållsarbete. Terminal-Bench testar interaktion med kommandoraden. Andra listade benchmarktester, däribland SlopCodeBench och ProgramBench, riktar in sig på andra aspekter av genererad kod och agentbeteende.

Dessa benchmarktester kan hjälpa till att jämföra verktyg eller fastställa en baslinje, men arbetsgivare bör vara försiktiga med att behandla ett enskilt resultat som bevis på produktionsberedskap. En modell som löser problem i kodarkiv kan fortfarande generera osäker auktoriseringslogik. En agent som slutför terminaluppgifter kan misslyckas med att bevara tillstånd genom ett långt arbetsflöde. En polerad webbapplikation kan klara en demo med lyckad väg men hantera omförsök eller dubbla betalningar felaktigt.

En trovärdig portfölj eller intern granskning bör därför innehålla en uppgiftsspecifik utvärderingsuppsättning. Den kan innehålla representativa felrapporter, normala användarresor, felaktig indata, behörighetsgränser, beroendefel och tidigare åtgärdade regressioner. Varje fall bör ha ett uttryckligt förväntat resultat, inte bara en skärmbild som ser rätt ut.

Det minsta testpaketet för AI-byggd programvara

För en liten applikation kan ett användbart kvalitetspaket byggas utan ett avancerat forskningslaboratorium:

  • Acceptanstester: verifiera det användarsynliga beteendet för de viktigaste arbetsflödena, inklusive lyckade och misslyckade utfall.
  • Enhets- och integrationstester: kontrollera affärsregler isolerat och bekräfta att databaser, API:er, köer och autentisering fungerar tillsammans som avsett.
  • Negativa tester: skicka in saknade, felaktigt formaterade, överdimensionerade, duplicerade och obehöriga indata. AI-genererad kod ser ofta bäst ut på den väg som visades i prompten, så de vägar som inte efterfrågades är viktiga.
  • Regressionstester: gör varje upptäckt defekt till ett permanent test. En grön demo efter en korrigering räcker inte om samma fel kan återkomma i nästa genererade ändring.
  • Säkerhetskontroller: testa åtkomstkontroll, hantering av hemligheter, skydd mot injicering, sårbarheter i beroenden och om opålitligt innehåll kan påverka verktygsanrop eller privilegierade åtgärder.
  • Driftskontroller: verifiera tidsgränser, omförsök, idempotens, loggning, aviseringar och säkert beteende när ett beroende inte är tillgängligt.

Detta ligger nära det QA-tekniska tankesätt som beskrivs i Stack Overflows redogörelse för en agentisk livscykel för programvaruutveckling. Den viktiga förändringen är kulturell: kvalitetssäkring är inte en slutinspektion efter att en AI har skrivit koden. Det är den struktur som gör snabb generering tillräckligt säker att använda.

Testa orkestreringen, inte bara resultatet

När programvara innehåller en AI-agent är vanliga applikationstester nödvändiga men otillräckliga. Systemet kan misslyckas för att modellen missförstod en begäran, men det kan också misslyckas för att den omgivande orkestreringen tappade kontext, anropade ett verktyg två gånger, accepterade felaktigt formaterade strukturerade utdata eller aldrig avslutades.

Digestens rekommenderade områden för regressionstester före driftsättning är en praktisk checklista: kontextförlust, verktygsidempotens, promptinjektering, strukturerade utdata, utebliven terminering, förankring i hämtad information och återställning av tillstånd. Detta är testbara tekniska egenskaper.

Ett test kan till exempel köra samma begäran två gånger och bekräfta att det andra försöket inte skapar en dubblettorder. Ett annat kan avbryta en agent mitt i ett arbetsflöde, starta om den och verifiera att den återupptar arbetet från ett giltigt tillstånd i stället för att upprepa en oåterkallelig åtgärd. Ett hämtningstest kan kräva att systemet endast citerar eller returnerar information från en godkänd källuppsättning. Ett test av strukturerade utdata kan förse systemet med ett ogiltigt svar och bekräfta att applikationen avvisar det på ett säkert sätt i stället för att i tysthet behandla det som giltiga data.

Långvariga system och system med flera agenter behöver särskilt tydliga felregister. Forskare arbetar med automatiserad felattribuering eftersom det kan vara svårt att identifiera vilken agent som orsakade ett fel och vid vilken punkt i en lång interaktionskedja. I praktiken bör team bevara verktygsanrop, indata, utdata, modellversioner, tidsstämplar, tillståndsövergångar och slutliga beslut i ett integritetsmedvetet revisionsspår. Utan dessa bevis visar ett rött test att något gick fel, men inte var man ska börja åtgärda det.

Reproducerbarhet blir en karriärfördel

AI-genererad kod varierar. En ny körning kan ge en annan implementation; en modelluppdatering kan förändra beteendet; ett avbrott hos en leverantör kan ändra dirigering eller fördröjning. Arbetsgivare kommer därför att värdesätta kandidater som kan göra utvärderingar repeterbara.

Det innebär att låsa modellögonblicksbilder där det är möjligt, dokumentera promptar och konfiguration, kontrollera slumpmässighet när plattformen tillåter det och köra flera försök för uppgifter vars utfall varierar. Digesten pekar särskilt på låsta ögonblicksbilder, låg eller noll temperatur där det är tillgängligt samt CI/CD-grindar med konfidensintervall som användbara skyddsåtgärder.

En praktisk rapport bör skilja mellan åtminstone tre resultat:

  1. Godkänd andel: hur många fall som lyckades.
  2. Konsekvens: hur ofta samma fall lyckas vid upprepade körningar.
  3. Allvarlighetsgrad: om felen är kosmetiska, besvärliga, dataskadande, säkerhetsrelaterade eller kan orsaka en osäker extern åtgärd.

Ett system som klarar 19 av 20 lågriskkontroller av formatering är inte nödvändigtvis bättre än ett som klarar 18 av 20 fall men aldrig överskrider en auktoriseringsgräns. Kvalitetskraven måste väga felen efter deras konsekvenser.

Mänsklig granskning bör inriktas på risk, inte på varje rad

Syftet med bättre automatisering är inte att tvinga en person att läsa om varje token som produceras av en AI. Det är att rikta människans uppmärksamhet mot de beslut som tester inte helt kan avgöra.

Granskare bör fokusera på autentisering och auktorisering, datalagring, finansiella eller avtalsmässiga åtgärder, integritet, migreringar, felåterställning, behörigheter för tredje part och ändringar som påverkar systemets eget utvärderingsramverk. För en agent bör de också granska vilka verktyg den får anropa, vilka data varje verktyg kan komma åt och om godkännande krävs före en oåterkallelig åtgärd.

Synliga diffar, arbetsflöden för godkännande, arkiverade konversationer och granskningsloggar – funktioner som lyfts fram i Slack Codes beskrivning av kollaborativ AI-kodning – pekar mot en bredare förväntan: historiken över hur programvara skapades kommer att spela roll. En granskare bör kunna förstå begäran, inspektera den genererade ändringen, se testbevisen och identifiera vem som godkände driftsättningen.

Den dokumentationen är inte byråkrati för byråkratins skull. Den gör det möjligt att skilja en imponerande demo från en kontrollerad ändring som någon annan kan underhålla.

Vad du bör ta med i en portfolio eller på en intervju

För kandidater är den starkaste demonstrationen ett litet system med en medvetet synlig kvalitetsberättelse. Inkludera kodarkivet, instruktioner för att konfigurera systemet, arkitekturbeskrivningar, testkommandon, representativa testfall, kända begränsningar och en kort felrapport. Visa en eller två buggar som hittades och omvandlades till regressionstester. Förklara vilken modell eller kodningsagent som användes utan att framställa verktyget som upphovsperson till de tekniska besluten.

Om applikationen använder en agent ska du dokumentera verktygsbehörigheterna, tillståndsmodellen, strategin för nya försök, avslutningsvillkoret och punkterna där mänskligt godkännande krävs. Om den använder informationssökning ska du visa hur källorna väljs och vad som händer när underlag saknas. Om den anropar externa tjänster ska du demonstrera beteendet vid timeout och duplicerade begäranden.

Påstå inte att systemet är tillförlitligt utifrån en enda lyckad inspelning. Ett kontrollerbart påstående låter mer som: ”I 30 inspelade körningar av dessa 12 scenarier uppfyllde systemet acceptanskriterierna i 28; de två felen gällde tvetydig datuminmatning och båda är dokumenterade.” Själva antalet är mindre viktigt än metoden, gränserna och ärligheten kring vad som återstår att testa.

Den nya definitionen av snabbt

AI sänker kostnaden för att ta fram en första version. Den tar inte bort kostnaden för att veta om den versionen förtjänar förtroende. Faktum är att snabbare generering kan göra utvärdering ännu viktigare, eftersom fler ogranskade ändringar kan samlas mellan driftsättningar.

Yrkespersonen efter vibe-kodning kommer att bedömas utifrån loopen: definiera beteende, generera eller ändra kod, testa realistiska och kontradiktoriska fall, granska beslut med hög risk, dokumentera fel och förbättra systemet utan att förlora bevis. Riktmärken kan hjälpa till att jämföra kapacitet. QA-metoder avgör om den kapaciteten blir till tillförlitlig programvara.

Kvalitetskravet är därför inte ”Kan du skapa en app med AI?” Det är ”Kan du bevisa vad appen gör, upptäcka när den slutar göra det och utforma begränsningar som hindrar ett fel från att bli en incident?”