Agentisk utvikling: slik endres arbeidsmåten når AI skriver koden

Agentisk utvikling betyr at utviklere lar AI-agenter utføre større arbeidsoppgaver selvstendig — lese kodebasen, gjøre endringen, kjøre testene og rette seg selv — mens mennesket setter retningen og gjennomgår resultatet. Det øker tempoet betydelig, men flytter samtidig flaskehalsen: det som begrenser dere er ikke lenger hvor raskt kode skrives, men hvor raskt den kan verifiseres.

• Oppgaver formuleres som mål og akseptansekriterier framfor detaljerte instruksjoner
• Gjennomgang blir det viktigste momentet, ikke det siste før lunsj
• Tester og typekontroll går fra fint å ha til forutsetning, siden de er agentens fasit
• Mye kode skrives raskt, noe som gjør det billigere å forkaste et forslag og gjøre om
• Ansvaret for resultatet ligger fortsatt hos den som godkjenner endringen

En agent presterer omtrent som en ny utvikler med perfekt hukommelse, men uten historikk. Den blir god i en kodebase der den kan kontrollere seg selv, og upålitelig i en der ingenting lar seg verifisere automatisk.

• Tester som kan kjøres fra kommandolinjen og som sier noe om virkeligheten
• Linting og typekontroll som gir rask, entydig tilbakemelding
• En måte å starte systemet lokalt uten hemmelige steg
• Kortfattet dokumentasjon av konvensjoner — hvordan dere navngir, hvor ting hører hjemme
• Små, tydelige endringer som lar seg gjennomgå på ti minutter

• Les endringen som helhet først: løser den det som ble bestilt, og bare det?
• Vær særlig oppmerksom på det som ser rimelig ut, men ikke testes — feilhåndtering, grensetilfeller, rettigheter
• Krev at agenten viser hvordan den har verifisert arbeidet, ikke bare at den sier det fungerer
• Vær skeptisk til brede endringer: mange filer med små justeringer skjuler ofte en misforståelse
• Kontroller at ingen sikkerhetssteg er fjernet for å få testene grønne

Den største risikoen er ikke at agenten skriver feil kode — det fanges opp av tester og gjennomgang. Den er at teamet slutter å forstå sitt eget system. Når ingen lenger kan forklare hvorfor en løsning ser ut som den gjør, blir hver framtidige endring dyrere. Motmiddelet er å kreve begrunnelser i beslutninger og holde endringene små nok til at noen faktisk leser dem.

• Hemmeligheter og nøkler skal aldri ligge der en agent leser dem ved et uhell
• Avhengigheter som foreslås automatisk må kontrolleres før de innføres
• Produksjonsdata skal ikke brukes som grunnlag i utviklingsarbeid
• Rettigheter for automatikk skal være egne og begrensede, ikke en administrators

Mål på flyt og kvalitet, ikke på antall kodelinjer. Rimelige mål er tiden fra påbegynt oppgave til endring i drift, hvor stor andel av endringene som må rettes i ettertid, og hvor ofte noe går i stykker i produksjon. Øker tempoet mens feilene står stille, er arbeidsmåten en gevinst. Øker begge, har dere bare flyttet arbeidet fram i tid.