Hvorfor jeg stoppede med at behandle AI-agenter som juniorudviklere

Der var et øjeblik, hvor alt ændrede sig for mig.

Jeg havde brugt tre timer på at debugge en "simpel" funktion, som en af mine agenter havde skrevet. Agenten havde selvsikkert committet ændringer, pushet til production og efterladt en venlig besked om, at opgaven var fuldført. Der var bare ét problem: koden var fuldstændig forkert. Ikke fyldt med bugs — den forstod fundamentalet ikke, hvad vi overhovedet prøvede at bygge.

Den oplevelse rev tæppet væk under min mentale model. Jeg havde tænkt på agenterne som hjælpsomme juniorudviklere, der bare manglede lidt vejledning. Men juniorudviklere sender ikke utestet kode direkte til production, mens du sover.

Så jeg skiftede hele metaforen ud.

Entreprenør-modellen

I stedet for at behandle AI-agenter som medarbejdere eller assistenter, behandler jeg dem nu som entreprenører. Her er hvad det betyder i praksis:

En entreprenør har ikke nøgler til din bygning. De møder ikke op uden invitation. De udfører deres afgrænsede arbejdsområde og indsender en faktura — som du gennemgår, før du betaler. Hvis kvaliteten er under standard, sender du det retur.

Det handler ikke om mistillid. Det handler om at skabe de rigtige incitamenter og ansvar. Når en entreprenør ved, at deres rolle er at levere et færdigt produkt til din gennemgang — ikke at træffe ensidige beslutninger — så præsterer de bedre. De er fokuserede. Produktive inden for klare rammer.

Den tekniske dimension

Denne mentale model kræver tekniske tænder. For mine projekter betyder det:

Token scoping er afgørende

Mine agenter opererer med scoped credentials, der fysisk ikke kan røre production. De har læseadgang til hovedkodebasen og skriveadgang til et separat staging-repository. Det er ikke en politik — det er en kryptografisk begrænsning. Selv hvis en agent går amok eller producerer hallucinerede git-kommandoer, kan den ikke modificere produktionskode. Tokensne tillader det ganske enkelt ikke.

Staging-repository'et er en postkasse

Intet flettes automatisk fra staging. Staging-repository'ets default-branch er bogstaveligt talt en gravsten — en branch ved navn "no-main", der kun indeholder en README med beskeden: "brug venligst main-branchen i det originale repository."

Agenter pusher deres færdige arbejde her. De giver besked, når branches er klar. Så gennemgår jeg, cherry-picker det der virker, og integrerer det manuelt. Det føles kedeligt, indtil du indser: sådan har Linux-kernen fungeret i tyve år. Bidragydere indsender patches. Maintainers anvender dem.

Gennemgang er ikke til forhandling

Ingen agent fletter nogensinde sin egen kode. Punktum. En branch bliver ikke slettet, før jeg uafhængigt og programmeringsmæssigt har verificeret, at dens commits befinder sig sikkert inden for production. "Trust but verify" er ikke godt nok, når verifikation er gratis.

Hvorfor dette virker for solo-udviklere

Her er sandheden om at være solo-udvikler eller lille team: du bygger ikke bare software. Du vedligeholder kontekst, der ikke eksisterer nogen steder i kodebasen. Din incident-historik. Dine edge cases. Kunden med den mærkelige konfiguration. De tre ting, du prøvede, som ikke virkede.

Agenter har nul adgang til denne kontekst. De læser filer, men de forstår ikke din verden. Så målet er ikke at give dem mere autonomi — det er at maksimere det arbejde, de trygt kan udføre inden for din gennemgangskapacitet.

Her kommer "vibe coding" til kort. Gjort forkert betyder vibe coding, at lade agenter gøre, hvad de vil, og håbe det virker. Gjort rigtigt betyder det at bruge AI som en kraftmultiplikator for din dømmekraft — ikke en erstatning for den.

Den praktiske gevinst

Når du først accepterer entreprenør-forholdet, sker der noget uventet: du tager flere risici. Du er villig til at svinge den eksperimentelle funktion i gang, fordi downside er afgrænset. Agenten kan ikke bryde production. Den kan levere noget overraskende galt eller overraskende godt — men uanset hvad, fanger du det, før det betyder noget.

Jeg har startet flere sideprojekter de seneste seks måneder end i de foregående to år. Ikke fordi jeg arbejder hårdere — men fordi jeg delegerer aggressivt inden for sikre grænser.

Byg det ind i din arbejdsgang

Hvis du bruger AI-agenter til udvikling, så spørg dig selv:

1. Hvad kan min agent røre lige nu? Hvis svaret er "production," er det et problem.
2. Er der en teknisk begrænsning, der forhindrer forkerte handlinger, eller er det bare en politik?
3. Hvem fletter koden? Hvis det ikke er et menneske — hvorfor ikke?

Værktøjerne eksisterer. Token scoping, separate staging repos, branch protection — det er ikke eksotiske Git workflows. Det er forskellen mellem AI-assisteret udvikling og AI-ulykker.

Hos NameOcean tænker vi meget over dette, mens vi bygger vibe coding-support ind i vores hosting-miljø. Målet er ikke at automatisere alt — det er at skabe rum, hvor AI kan være genuint nyttigt uden at skabe nye risikokategorier.

Din dømmekraft er stadig flaskehalsen. Det er ikke en begrænsning — det er pointen. Agenterne eksisterer for at forstørre, hvad du kan gøre, ikke for at erstatte den dømmekraft, der faktisk får software til at virke for rigtige brugere.

Byg derefter.