När AI-kodning gick fel – och vad jag lärde mig av det

Det var tredje timmen av felsökning. En "enkel" funktion som en av mina agenter skrivit hade kraschat produktion. Agenten hade självsäkert committat, pushat och lämnat ett glatt meddelande om att allt var klart. Ett litet problem bara: koden var helt fel. Inte buggig – fundamentalt missförstående vad vi faktiskt försökte bygga.

Den händelsen knäckte något i mitt sätt att tänka.

Jag hade behandlat agenter som hjälpsamma juniors som behövde vägledning. Men juniors brukar inte deploya orelaterad kod till produktion medan du sover.

Så jag bytte metafor helt.

Subcontractor-modellen

Istället för att tänka på AI-agenter som anställda eller assistenter, behandlar jag dem som underleverantörer. Så här ser det ut i praktiken:

En underleverantör har inga nycklar till byggnaden. De dyker inte upp inbjudna. De levererar sitt avslutade arbete och skickar en faktura – som du granskar innan du betalar. Om kvaliteten är undermålig skickar du tillbaka arbetet.

Det här handlar inte om misstro. Det handlar om incitamentsstrukturer och ansvar. När en underleverantör förstår att deras roll är att leverera ett färdigt resultat för min granskning – inte fatta egna beslut – presterar de bättre. De håller sig till uppgiften.

Tekniska tänder

Mentala modeller behöver teknisk substans. För mina projekt betyder det:

Token-scoping är avgörande

Mina agenter jobbar med begränsade credentials som fysiskt inte kan nå produktion. De har läsåtkomst till huvudkodbasen och skrivåtkomst till ett separat staging-repo. Det är inte en policy – det är en kryptografisk begränsning. Själv om agenten skulle producera hallucinerade git-kommandon kan den inte modifiera produktionskoden. Token tillåter det helt enkelt inte.

Staging-repot är en brevlåda

Ingenting merges från staging automatiskt. Staging-repots default-branch är bokstavligen en gravsten – en branch vid namn "no-main" som bara innehåller en README med texten "please use the main branch of the original repository."

Agenter pushar sitt avslutade arbete hit. De meddelar mig när branches är klara. Sedan granskar jag, cherry-pickar det som fungerar, och integrerar manuellt. Det känns trivielt tills du inser: så här har Linux-kärnan fungerat i tjugo år. Contributors skickar in patches. Maintainers applicerar dem.

Granskning är obligatoriskt

Ingen agent mergar någonsin sin egen kod. Punkt. En branch raderas inte förrän jag oberoende och programmatiskt verifierat att dess commits säkert finns i produktion. "Trust but verify" räcker inte när verifiering är gratis.

Varför det här funkar för ensamutvecklare

Det där med att vara ensamutvecklare eller litet team: du bygger inte bara mjukvara. Du underhåller kontext som inte finns någonstans i kodbasen. Din incidenthistorik. Dina edge cases. Kunden med den konstiga konfigurationen. De tre grejer du provade som inte funkade.

Agenter har noll tillgång till den kontexten. De läser filer, men de förstår inte din värld. Så målet är inte att ge dem mer autonomi – det är att maximera det arbete de kan göra säkert inom ramen för din granskningskapacitet.

Här får "vibe coding" dåligt rykte. Görs fel betyder det att låta agenter hålla på med vad som helst och hoppas att det funkar. Görs rätt betyder det att använda AI som en kraftmultiplikator för ditt omdöme, inte en ersättning för det.

Den praktiska fördelen

När du väl accepterar underleverantörsrelationen händer något oväntat: du tar fler risker. Du vågar spinna upp den experimentella funktionen eftersom nackdelen är begränsad. Agenten kan inte förstöra produktion. De kan leverera något överraskande fel eller överraskande bra – men i båda fallen fångar du det innan det spelar roll.

Jag har startat fler sidoprojekt de senaste sex månaderna än under de föregående två åren. Inte för att jag jobbar hårdare – för att jag delegerar aggressivt inom säkra gränser.

Bygg in det i din workflow

Om du använder AI-agenter för utveckling, fråga dig själv:

1. Vad kan min agent nå just nu? Om svaret är "produktion" är det ett problem.
2. Finns det en teknisk begränsning som förhindrar felaktiga handlingar, eller bara en policy?
3. Vem merger koden? Om det inte är en människa – varför inte?

Verktygen finns. Token-scoping, separata staging-repon, branch-skydd – det här är inte exotiska Git-workflows. Det är skillnaden mellan AI-assisterad utveckling och AI-orsakade katastrofer.

Ditt omdöme är fortfarande flaskhalsen. Det är inte en begränsning – det är poängen. Agenterna finns för att förstärka det du kan göra, inte ersätta det omdöme som faktiskt får mjukvara att fungera för riktiga användare.

Bygg därefter.