Slik jobber jeg trygt med AI-kodere

La meg fortelle om øyeblikket jeg innså at jeg måtte endre hvordan jeg jobbet med AI-kodere.

Jeg hadde brukt tre timer på å feilsøke en «enkel» funksjon som en av kodene mine hadde skrevet. Den hadde trygt commitet endringer, pushet til produksjon, og til og med etterlatt en hyggelig melding om at oppgaven var fullført. Det var bare ett problem: koden var helt feil. Ikke full av bugs – den hadde misforstått hva vi egentlig prøvde å bygge.

Den hendelsen ødela noe i hvordan jeg tenkte. Jeg hadde sett på disse agentene som nyttige juniorutviklere som trengte veiledning. Men juniorutviklere sender ikke utestet kode til produksjon mens du sover.

Så jeg endret metaforen helt.

Underleverandør-rammeverket

I stedet for å behandle AI-agenter som ansatte eller assistenter, behandler jeg dem som underleverandører. Slik fungerer det i praksis:

En underleverandør har ikke nøkler til bygningen din. De dukker ikke opp uinnkalt. De fullfører arbeidsomfanget sitt og sender en faktura – som du går gjennom før du betaler. Hvis arbeidet er mangelfullt, sender du det tilbake.

Dette handler ikke om mistillit. Det handler om å skape riktige insentiver og ansvar. Når en underleverandør forstår at rollen er å levere et ferdig produkt for din gjennomgang – ikke å ta ensidige beslutninger – yter de bedre. De er fokusert. De er produktive innenfor klare rammer.

Den tekniske biten

Denne tankemodellen trenger tekniske tenner. For mine prosjekter betyr det:

Token-avgrensning er alt

Mine agenter jobber med avgrensede påloggingsdetaljer som fysisk ikke kan nå produksjon. De har lesetilgang til hovedkodebasen og skrivetilgang til et separat staging-repository. Det er ikke en policy – det er en kryptografisk begrensning. Selv om en agent skulle gå rogue eller produsere hallusinerte git-kommandoer, kan den ikke endre produksjonskode. Tokenene tillater det ikke.

Staging-repositoryet er en postkasse

Ingenting merger fra staging automatisk. Staging-repositoryets default-branch er bokstavelig talt en gravstein – en branch heter «no-main» og inneholder bare en README som sier «bruk hovedbranchen til hovedrepositoryet.»

Agenter pusher ferdig arbeid hit. De melder fra når branches er klare. Så går jeg gjennom, cherry-picker det som fungerer, og integrerer manuelt. Dette føles tungvint helt til du skjønner: slik har Linux-kjernen fungert i tjue år. Bidragsytere sender inn patches. Maintainereappliserer dem.

Gjennomgang er ikke forhandlingsbart

Ingen agent merger noen sinne sin egen kode. Slutt. En branch slettes ikke før jeg verifiserer – uavhengig, programmert – at commitene er trygt inne i produksjon. «Tillit, men verifiser» er ikke nok når verifisering er gratis.

Hvorfor dette fungerer for solo-utviklere

Her er greia med å være solo-utvikler eller liten gjeng: du bygger ikke bare programvare. Du vedlikeholder kontekst som ikke finnes noe sted i kodebasen. Din hendelseshistorikk. Dine edge cases. Kunden som har en merkelig konfigurasjon. De tre tingene du prøvde som ikke fungerte.

Agenter har null tilgang til denne konteksten. De leser filer, men de forstår ikke din verden. Så målet er ikke å gi dem mer autonomi – det er å maksimere arbeidet de kan gjøre trygt innenfor din gjennomgangskapasitet.

Dette er der «vibe coding» får et dårlig rykte. Gjort feil betyr vibe coding at agentene får gjøre hva de vil og håpe det funker. Gjort riktig betyr det å bruke AI som en forsterker for din dømmekraft, ikke en erstatning for den.

Den praktiske gevinsten

Når du først aksepterer underleverandør-forholdet, skjer noe uventet: du tar flere sjanser. Du er villig til å spinne opp den eksperimentelle funksjonen fordi nedsiden er avgrenset. Agenten kan ikke ødelegge produksjon. De kan levere noe overraskende galt, eller noe overraskende bra – men uansett fanger du det før det betyr noe.

Jeg har startet flere sideprosjekter de siste seks månedene enn de foregående to årene. Ikke fordi jeg jobber hardere – fordi jeg delegerer aggressivt innenfor trygge grenser.

Slik bygger du dette inn i arbeidsflyten

Hvis du bruker AI-agenter til utvikling, spør deg selv:

1. Hva kan agenten min nå akkurat nå? Hvis svaret er «produksjon», er det et problem.
2. Finnes det en teknisk begrensning som forhindrer feil handlinger, eller bare en policy?
3. Hvem merger kode? Hvis det ikke er et menneske, hvorfor ikke?

Verktøyene finnes. Token-avgrensning, separate staging-repositories, branch-beskyttelse – dette er ikke eksotiske Git-workflows. Det er forskjellen mellom AI-assistert utvikling og AI-ulykker.

Hos NameOcean tenker vi mye på dette mens vi bygger vibe coding-støtte i hosting-miljøet vårt. Målet er ikke å automatisere alt – det er å skape rom der AI kan være genuint nyttig uten å skape nye risikokategorier.

Din dømmekraft er fortsatt flaskehalsen. Det er ikke en begrensning – det er poenget. Agentene eksisterer for å forsterke det du kan gjøre, ikke for å erstatte dømmekraften som faktisk får programvare til å fungere for virkelige brukere.

Bygg deretter.