Innan kod skriven av en agent driftsätts måste följande villkor vara uppfyllda: testsviten passerar, linter och typkontroller godkänns, diffen har den storlek och omfattning som planen föreskrev, projektet bygger felfritt, en säkerhetsskanning rapporterar inga nya sårbarheter och en människa har granskat och godkänt diffen. Var och en av dessa är en verifieringsgrind: en kontroll som måste passeras innan arbetet går vidare till nästa steg. Ytterligare en grind inträffar innan någon kod ens existerar: mänskligt godkännande av planen. Det är den grind som sparar mest pengar, eftersom en avvisad plan kostar noll kronor att köra. Denna artikel definierar grindar, listar de som är kritiska för agentkod och beskriver hur Ivy Tendril hanterar dem.

Vad en grind är

En grind är ett villkor kopplat till en fasövergång. Arbete i fas N kan inte övergå till fas N+1 förrän villkoret är uppfyllt. Villkoret måste utvärderas på exakt samma sätt varje gång, och resultatet måste dokumenteras så att det kan granskas i efterhand.

Tre egenskaper skiljer en grind från ett löst förslag:

Den blockerar. En misslyckad grind stoppar övergången helt. En kontroll vars misslyckande bara är rådgivande är en rapport, inte en grind.
Den är automatisk eller explicit. Antingen utvärderas den av ett program (tester, linter, bygge) eller så fattar en namngiven person ett protokollfört beslut (granskning). ”Någon tittade förmodligen på det” är ingetdera.
Den har en definierad väg vid fel. När grinden inte passeras skickas arbetet till en specifik mottagare: tillbaka till agenten, tillbaka till planen eller till en människa. Arbete som fallerar i en grind och blir liggande utan ägare är den vanligaste anledningen till att agentgenererad kod går förlorad.

Människoskriven kod passerar också grindar: kontinuerlig integration och pull request-granskning. Skillnaden med agentproducerad kod är volymen. När en enskild utvecklare kan öppna tjugo pull requests per dag blir granskningen den trängsta flaskhalsen. Grindarna före granskning måste därför filtrera bort så mycket felaktigheter som möjligt innan en person läser diffen. Artikeln Mönster för agentorkestrering beskriver hur verifiering samverkar med köhantering, isolering och kostnadskontroll.

De grindar som är avgörande för agentkod

Grind	Vad den kontrollerar	Vad ett fel vanligtvis innebär
Plangodkännande	En människa har läst planen och godkänt tillvägagångssätt och omfattning	Uppgiften var underspecificerad eller strategin är felaktig
Tester	Befintliga tester passerar; nytt beteende täcks av tester	Agenten har haft sönder något eller missat att skriva tester för ändringen
Linter och typkontroll	Koden följer projektets regler och kompilerar	Regelbrott, oanvänd kod eller typfel som uppstod när agenten försökte få testerna att passera
Diff-storlek och omfattning	Ändrade filer matchar planen; diffen förblir lättgranskad	Agenten ändrade filer utanför planen eller refaktorerade orelaterad kod
Bygge	Hela projektet bygger felfritt från grenen	Något fungerar isolerat men inte i det sammansatta projektet
Säkerhetsskanning	Inga nya hemligheter, sårbara beroenden eller flaggade mönster	Agenten lade till en hemlighet/API-nyckel, ett osäkert paket eller ett osäkert funktionsanrop
Diffgodkännande	En människa har läst diffen och godkänt den	Allt automatiserade grindar inte kan bedöma: intention, namngivning, produktpassning

De första sex körs innan en människa behöver kopplas in: plangrinden körs före exekvering och resten körs inuti agentens worktree direkt efter körningen. Två av dem förtjänar extra uppmärksamhet.

De risker som är specifika för modellgenererad kod – osäker hantering av utdata, skadliga beroenden i leveranskedjan, läckta autentiseringsuppgifter – finns katalogiserade i OWASP Top 10 for LLM Applications, vilket är en utmärkt checklista för vad säkerhetsgrinden faktiskt bör leta efter.

Diff-storlek och omfattning (scope) är den grind team oftast hoppar över, trots att den är viktigare för agenter än för människor. En agent som ombeds fixa en enkel null-kontroll kan ibland även formatera om filen, byta namn på en variabel och uppdatera tre anropsställen. Tillsammans förvandlar detta en granskning på 10 rader till en på 300 rader. En omfattningsgrind jämför berörda filer och moduler mot planen och larmar vid avvikelser.

Säkerhetsskanning fångar hemligheter, sårbarheter i beroenden och otillåtna mönster. Agenter kopierar mönster från omgivande kod, så ett arkiv med ett osäkert mönster tenderar snabbt att få fler.

Varför plangranskningen förhindrar bortkastad körning

Alla grindar efter exekveringen delar en olycklig egenskap: när de misslyckas har tokens och pengar redan förbrukats. Tester, linter, bygge och skanning talar om att körningen gick fel. Endast plangrinden talar om det för dig innan den går fel.

Titta på vad de senare grindarna fångar upp. Ett testfel på grund av att agenten missförstod kravet är ett planproblem. Ett omfattningsfel för att agenten rörde moduler som uppgiften inte nämnde är ett planproblem. Ett byggfel för att planen krävde en förändring i ett paket utan att ta hänsyn till beroende paket är ett planproblem. I vart och ett av dessa fall hade en granskare som läst en skriftlig plan i två minuter upptäckt problemet direkt – till exakt noll exekveringskostnad.

Detta är anledningen till att mjukvarufabrikens arbetsflöde – Ivys namn för en repeterbar sekvens av planering, exekvering, verifiering och granskning – har exakt två mänskliga kontrollpunkter och placerar en av dem innan någon kod ens existerar. Planens kontrollpunkt är platsen där omfattning, tillvägagångssätt och prioritering beslutas. Diffens kontrollpunkt är platsen där korrektheten bekräftas. Allt däremellan sker helautomatiskt.

Hur Ivy Tendril kör verifieringsgrindar

Ivy Tendril är en local-first skrivbordsapplikation (macOS, Windows, Linux) som tar en uppgift från plan till granskad pull request. De två mänskliga kontrollpunkterna och de automatiserade grindarna däremellan är inbyggda direkt i dess livscykel. Se dokumentationen för Review-appen för gränssnittet.

Plangrind. En plan börjar som ett utkast. En människa läser den och kan expandera (Expand), dela upp (Split) eller uppdatera (Update) den, eller kommentera direkt i utkastet och få planen omskriven. Exekveringen startar inte förrän planen är godkänd.
Isolerad exekvering. Varje plan körs i ett eget Git-worktree på en egen branch, så att verifieringen körs mot exakt den planens ändringar och ingenting annat. Git worktrees för parallella AI-agenter beskriver varför isolering gör grindarna pålitliga.
Verifieringsflikar. Efter körning visar Review-appen tester, linter och diff som separata flikar, så att granskaren ser alla tre perspektiven innan ett beslut fattas.
CI-import i Pro. Team vars grindar körs i CI – GitHub Actions eller något annat system – kan importera dessa resultat direkt till Review-appen i Pro-planen, så att granskaren slipper öppna ett externt verktyg.
Väg vid fel. När en verifiering misslyckas skickas arbetet tillbaka till agenten med felloggarna bifogade. Agenten får den faktiska test- eller linter-utdatan, inte en sammanfattning, och körs om i samma worktree. Vyn Jobs strömmar agentens utdata och verktygsanrop under tiden.
Diffgrind. Först efter att verifieringen passerats och en människa har godkänt diffen öppnar Tendril en pull request på GitHub. Ingenting skeppas utan båda godkännandena.

Kostnaden spåras per plan och per jobb, så en plan som misslyckades med verifieringen tre gånger innan den godkändes visar exakt vad omkörningarna kostade. Det ger underlag för att avgöra om plangrinden borde ha varit striktare från början.

Hur du kommer igång

Dokumentera dina nuvarande grindar. De flesta team upptäcker att de har tester och kodgranskning, och att en linter körs någonstans men att ingen vet om den blockerar.
Installera Tendril: curl -sSf https://cdn.ivy.app/install-tendril.sh | sh (macOS, Linux) eller irm https://cdn.ivy.app/install-tendril.ps1 | iex (Windows). Se installation.
Kör en plan genom hela livscykeln och läs test- och linter-flikarna innan du granskar diffen. Notera vad du skulle ha missat genom att enbart läsa diffen.
Lägg till en omfattningskontroll i din plangranskning: matchar listan över filer agenten får röra själva planen?

Tendril är gratis och källkodstillgängligt under Functional Source License. CI-verifieringsimport, teamfunktioner, lokal hosting (on-prem) och SSO finns tillgängliga i Pro- och Enterprise-planerna.

Vanliga frågor

Borde verifieringsgrindar blockera automatiskt eller bara informera granskaren?

Tester, linter, typkontroller och byggen måste blockera hårt; en granskare ska inte ödsla tid på en diff som inte ens kompilerar. Omfattnings- och säkerhetsgranskningar bör visas för granskaren med möjlighet att manuellt godkänna, eftersom båda ibland har legitima skäl till undantag.

Hur många omkörningar (retries) bör en agent få vid misslyckad verifiering?

Sätt en tydlig gräns och logga den. Upprepade verifieringsfel är nästan alltid ett planproblem snarare än ett körningsproblem; skicka tillbaka uppgiften till planstadiet istället för att betala för ett femte misslyckat försök. Kostnadsspårning per jobb gör omkörningskostnaden synlig.

Spelar mänsklig granskning av diffen fortfarande roll om alla automatiska grindar passerar?

Ja, tveklöst. Automatiska grindar kontrollerar endast det som kan specificeras i förväg. De kontrollerar inte om ändringen uppfyller den egentliga avsikten med ärendet, om koden blir underhållbar eller om själva planen var feltänkt från början. Det är därför diffgranskningen är en av de två obligatoriska mänskliga grindarna.

Kom igång med Ivy Tendril

Är du redo för parallell agentorkestrering på utvecklarnivå?

Utforska källkoden: Upptäck Ivy Tendril på GitHub (Open Source).
Läs dokumentationen: Hitta integrationsguider på tendril.ivy.app.
Boka arkitekturgenomgång: Kontakta renco@ivy.app för en 30-minuters teknisk konsultation.

Verifieringsgrindar: vad som måste gälla innan agentkod skeppas