Det lønner seg mer enn noen gang å investere i riggen

Jeg har alltid sett verdien av å forbedre utviklerhverdagen, men jeg har ikke alltid lykkes med det. Ikke fordi jeg manglet ideene, men fordi Bash, GitHub Actions og operativsystemer aldri var min sterkeste side. Det tok for lang tid, og features ble prioritert i stedet. De siste årene har dette regnestykket blitt snudd på hodet. Med AI kan selv små team med begrensede ressurser få gjort ambisiøse forbedringer som tidligere ble liggende.

Med «riggen» mener jeg alt som omgir koden og gjør at du kan stole på den: tester, lint, CI/CD, deploy-miljøer, observability og instruksjonene agentene jobber etter.

Mange utviklere jeg snakker med bruker AI nesten utelukkende til å bygge features. Issue inn, feature ut. Det er forståelig, det er tross alt hva produkteier ser. Problemet kommer med den drastiske økningen i kodebidrag. Et kriterium for å lykkes er at systemene rundt tåler det tempoet. En nøkkel for å få til det er å bruke AI både til å forbedre riggen og være en del av den.

Hvorfor investere i riggen

Svaret er enkelt: fart. Jo mer tillit du har til riggen, jo mer er du villig til å stole på at neste PR skrevet av agenten din faktisk gjør det som var intensjonen. Fart handler ikke om hvor fort agenten din spytter ut kode, men hvor raskt du tør å merge den.

Hvor fort du tør å bevege deg uten å finlese hver kodeendring avhenger av hva som står på spill. Det er forskjell på det å brekke et system med få brukere i et internverktøy kontra en betalingsflyt med tusenvis av brukere.

Felles for systemer med høy tillit er nøyaktig det samme som før: gode arkitekturmønstre, tester, automatiserte sjekker, observability og rask rollback. Jeg tror at jo bedre riggen er, jo mer komfortabel er du med å bevege deg nedover denne listen:

1. Agenten lager PR-en, og et menneske reviewer
2. Agenten lager PR-en, og et menneske skummer den fordi sjekkene er gode.
3. Agenten merger selv for visse typer endringer
4. Lights off: issue inn, prod ut. Ingen mennesker i loopen.

Målet er ikke at alle prosjekter skal nå nivå 4. Målet burde heller være å ha en rigg som tillater det der det gir mening. Ville du auto-merget en Renovate-PR der alle sjekker er grønne? Dokumentasjon? Lint-regler? Hvis svaret er nei, er det verdt å spørre seg hva som må til for å bli komfortabel med det.

Claude Code-teamet hos Anthropic tar disse ideene langt. Flere agenter leser endringene og klassifiserer risikoen, og risikoen avgjør hvor mye menneskelig review som kreves. Endringer med lav risiko merges automatisk dersom sjekkene er grønne. Jeg synes dette sitatet fra en unavngitt ansatt der oppsummerer det nye tankesettet bra.

Slowing down does lower your error rate, but mostly because you're doing less of everything. We'd rather get faster at noticing and fixing problems

Flaskehalsen har flyttet seg

Når koden har blitt billig å skrive, så flytter flaskehalsen seg til alt som skal til for å stole på den: lint, typesjekker, tester, pipelines og rutiner. Agenter bruker disse verktøyene på samme måte som oss, men titalls ganger per feature og gjerne flere i parallell. Så selv om koden er billig å skrive, er den fortsatt dyr å kjøre.

Det er også her noe av oppsiden ligger. Gjør du riggen noen prosent raskere og mer treffsikker, får du gevinsten igjen på hver kjøring, i hver feature. Det er renters rente-effekten.

Nylig skrev vi om flere hundre ende-til-ende tester fra Cypress til Playwright. Ved å utnytte workers og shards i Playwright reduserte vi kjøretiden fra 16 til 4 minutter i CI. Det er 12 minutter spart per testkjøring, for hver eneste feature. Arbeidet tok mindre enn en arbeidsdag, så investeringen var raskt tjent inn.

Anthropic har nylig skrevet seg vekk fra Git til et eget versjonskontrollverktøy fordi de opplever at versjonskontrollen er en flaskehals i CI. OpenAI skriver om lignende erfaringer, hvor Git og CI ble en flaskehals når agentene skriver mesteparten av koden. De færreste har den skalaen, men budskapet er tydelig.

Fallgruven

Det er også risiko forbundet med å bevege seg så fort. Selv om koden er billig, kan den havne på feil sted, bryte med eksisterende prinsipper og/eller arkitektur. Det som holder kodebasen skalerbar, er ikke bare god arkitektur på papiret, men arkitektur som er håndhevet i riggen. Lint-regler som stopper anti-patterns, instruksjoner som agentene jobber ut fra.

Det er også utfordringer knyttet til sikkerhet og tilgangsstyring, både til brukere og agentene selv. Sikkerhet må tenkes på i hvert ledd, spesielt når bidrag til kodebasen gjerne kan komme fra prosjektlederen din.

Den største risikoen er at kodebasen vokser raskere enn vår egen forståelse av den. Derfor mener jeg at endringer som innfører nye arkitekturmønstre, avhengigheter eller berører kritiske deler av applikasjonen fortsatt fortjener menneskelig gjennomgang. Store veivalg burde tas av mennesker, for beslutningene er det vi som må leve med og bygge videre på.

Viktigere å dele enn noen gang

Husker du for noen år siden da du fant ut at kollegaen din hadde brukt en helt overlegen plugin i VSCode i et år uten å si ifra til deg, eller en effektiv macro i IntelliJ som kunne spart deg for utrolig mye tid?

Nå er det bare å kjøre gangetabellen på det regnestykket. Skills og AGENTS.md-filer er den nye pluginen, og det er bare å utnytte det til det fulle. Det er ikke bare deg selv som får gevinsten, det gjør også agentene.

Tar det lang tid å spinne opp en ny tjeneste hos dere? Har du funnet en effektiv måte å debugge APIet ditt på? Skriv prosedyren ned i en skill, så nytten kan deles av alle.

Gjør dette på mandag

Vær ambisiøs! Ikke nøy deg med å være en “issue inn, feature ut”-utvikler. Hvis kreativiteten stopper deg, her er noen grep som nylig har gjort utviklerhverdagen min bedre:

Forbedre riggen med AI

• Gjør om repo-regler til lint-regler i stedet for å ha dem i AGENTS.md
• Sett opp automatiske preview-miljø på hver commit
• Bytt fra ESLint-regler til Oxlint. Vi reduserte lint-tiden i repoet vårt fra 30 til 3 sekunder

Integrere AI som en del av riggen

• La en review-agent fra en annen leverandør gjennomgå koden før du åpner en PR
• La en agent begynne å jobbe med en oppgave så snart den er registrert i Jira/GitHub
• La en agent klassifisere risiko ved PR-er og automatisk merge endringer med lav risiko, som dokumentasjon, lint-regler og dependencies
• La agenter inspisere produksjonslogger og se etter avvik

Velg én ting i riggen som bremser dere. Gi agenten i oppgave å forbedre det, gevinsten vil du få tilbake i hver eneste feature.