Av Nils Ekström, CTO på Stomme AI
Din agent har 28 färdigheter. E-posttriagering. Kalenderhantering. Webbforskning. Kodutrullning. Betalningshantering. CRM-operationer. Dokumentgenerering. Tjugo till.
Var och en av dem gick igenom en process som vi kallar smedjan.
Smedjan är inte en kodgranskning. Det är en automatiserad adversariell pipeline som genererar en färdighet, skapar omfattande tester och sedan attackerar sitt eget resultat för att hitta säkerhetshålen, kantfallen och fellägen som normal testning missar.
Här är hur det fungerar — och varför vi byggde den.
Problemet med normal testning
Standard mjukvarutestning fungerar så här: en utvecklare skriver kod, sedan skriver den tester för att verifiera att koden fungerar. Problemet är uppenbart — personen som skriver testerna har samma mentala modell som personen som skrev koden. De delar samma antaganden och samma blinda fläckar.
Om utvecklaren inte tänkte på vad som händer när en tidszon är UTC-12, tänkte inte testet på det heller.
AI-genererad kod förvärrar detta problem. När du ber en AI att skriva en färdighet och sedan ber samma AI att skriva tester för den färdigheten får du tester som verifierar AI:ns antaganden — inte tester som utmanar dem.
Du behöver en fientlig granskare.
Smedjans pipeline
Steg 1: Specifikation
Vi skriver en kort beskrivning för varje färdighet. Inte pseudokod — en funktionell specifikation:
- Vad färdigheten gör
- Vilka indata den accepterar
- Vilka utdata den producerar
- Vilka kantfall som är viktiga
- Vilka säkerhetsbegränsningar som gäller
- Vilka integrationer den berör
Specifikationen är kontraktet. Allt nedströms testas mot den.
Steg 2: Generering
En AI-agent skriver den första implementationen. Komplett med felhantering, indatavalidering, typkontroll och integrationspunkter. Detta är ett kompetent första utkast — inte slutgiltigt, och skickas aldrig som det är.
Steg 3: Testgenerering
En separat AI-agent — en som inte har sett implementationen — genererar tester enbart utifrån specifikationen. Detta är kritiskt: testskrivaren vet inte hur koden fungerar. Den vet bara vad den ska göra.
Detta ger tester som utmanar implementationens antaganden snarare än att bekräfta dem. Om implementationen hanterar ett null-värde genom att returnera en tom array, men specifikationen säger att den ska kasta ett fel, fångar testet upp det.
Minimum: 50 tester per färdighet. Komplexa färdigheter får 150–200.
Steg 4: Adversariell granskning
En tredje AI-agent granskar implementationen och testen med ett enda direktiv: bryt den.
Denna agent letar efter:
- Säkerhetssårbarheter. Injektionsattacker, exponering av autentiseringsuppgifter, icke-validerade indata, vägar för behörighetseskalering.
- Kantfall som testen missar. Unicode-tecken i e-postämnen. Kalenderhändelser som sträcker sig över midnatt. Filer utan filändelse. Rate limit-svar från API:er.
- Prestandaproblem. N+1-frågor. Obegränsade loopar. Minnesläckor i långvariga operationer.
- Integrationsfel. Vad som händer när e-post-API:et returnerar en 429. När kalender-API:et är nere. När filsystemet är skrivskyddat.
Den adversariella granskaren är fientlig av design. Den försöker inte verifiera att koden fungerar. Den försöker bevisa att den inte gör det.
Steg 5: Iteration
Fel från den adversariella granskningen matas tillbaka till genereringssteget. Färdigheten byggs om — inte lagas. En ny implementation åtgärdar de identifierade problemen, nya tester verifierar rättningarna, och den adversariella granskaren attackerar igen.
Denna loop körs tills färdigheten klarar allt. Vanligtvis 2–4 iterationer per färdighet. Vissa komplexa färdigheter tog 6.
Steg 6: Mänsklig granskning
En människa granskar det slutliga resultatet. Inte rad för rad — utan arkitekturen, säkerhetsmodellen och integrationskvaliteten. Gör denna färdighet det som specifikationen säger? Upprätthålls säkerhetsbegränsningarna? Skulle vi lita på detta med en kunds e-post?
Vad den adversariella granskningen faktiskt fångar
I vår sprint med 28 färdigheter hade varje färdighet som klarade den initiala genereringen problem som fångades av den adversariella granskaren:
- En e-posttriageringsfärdighet som inte hanterade e-post utan ämnesrad
- En kalenderfärdighet som felaktigt beräknade varaktigheten för händelser som korsade sommartidsövergångar
- En filhanteringsfärdighet som följde symlänkar utanför sandlådan
- En betalningshanteringsfärdighet som loggade kortmetadata i klartext
- En webbforskningsfärdighet som inte validerade URL-scheman, vilket tillät file://-åtkomst
Ingen av dessa skulle ha fångats av konventionell testning. Var och en skulle ha orsakat ett verkligt problem för en verklig kund.
Varför detta är viktigt för dig
Du behöver inte förstå smedjan för att använda din agent. Men du bör veta att den finns.
Varje förmåga din agent har — varje e-post den triagerar, varje möte den schemalägger, varje fil den hanterar — byggdes med denna pipeline. Genererad, testad, attackerad, ombyggd, omtestad och granskad.
2 939 tester. 100 % godkända. Inga säkerhetsbrister i den slutliga uppsättningen.
Det är inte ett marknadsföringsnummer. Det är en ingenjörsstandard. Och det är därför din agent hanterar din e-post klockan tre på morgonen utan att du behöver oroa dig.