Arbeidsflyt: planlegg, la AI skrive, du reviewer

AI-verktøy er raske til å skrive kode og dårlige til å vite hva som skal skrives. Arbeidsflyten som fungerer, flytter menneskets tid fra å skrive til å planlegge og reviewe. Her er den, steg for steg.

Prinsippet

Tre roller, tre steg:

1. Mennesket planlegger. Hva skal gjøres, hvor i koden, hvordan skal det testes, og hva skal ikke røres.
2. AI skriver. Kode, tester og en oppsummering av hva som ble gjort.
3. Mennesket reviewer. Som om en ny kollega hadde skrevet det. Fordi det er det som har skjedd.

Hopper du over steg 1, får du kode som løser feil problem. Hopper du over steg 3, får du kode ingen forstår om tre måneder.

Steg 1: Planen

En god oppgave til en AI-agent ser ut som en god oppgave til en junior utvikler. Den inneholder:

• Målet i én setning. «Brukeren skal kunne laste ned faktura som PDF fra ordresiden.»
• Hvor i koden. Navn på filer, komponenter eller moduler som skal endres, og hvilke som ikke skal røres.
• Mønsteret som skal følges. «Gjør det slik som eksport til Excel er gjort i ExportButton.tsx.»
• Hvordan det verifiseres. Hvilke tester som skal skrives eller kjøres, og hva som skal sjekkes manuelt.
• Grensene. Ingen nye avhengigheter uten å spørre. Ingen endringer i databaseskjema.

Be agenten lage en plan før den skriver kode, og les planen. Det tar to minutter og sparer en time.

Steg 2: Skrivingen

La agenten jobbe på en egen branch. Be om små steg: én fil eller én funksjon om gangen når oppgaven er usikker, større steg når mønsteret er klart. Be alltid om at tester kjøres før den sier seg ferdig.

Når noe går galt, ikke rett koden selv med en gang. Forklar hva som er feil og la agenten rette. Det lærer deg hva verktøyet misforstår, og det holder arbeidsflyten ren.

Steg 3: Review

Review av AI-skrevet kode er det samme som review av kode fra en kollega, med tre tillegg:

• Sjekk at problemet som ble løst er problemet som ble stilt. AI løser gjerne et enklere naboproblem.
• Sjekk hva som ble slettet eller endret utenfor oppgaven. Agenter «rydder» gjerne i kode de ikke ble bedt om å røre.
• Sjekk at testene tester noe. En test som alltid er grønn er verre enn ingen test.

Hva som skal i PR-en

Beskrivelsen i en pull request der AI har skrevet mye, skal si tre ting: hva oppgaven var, hva som ble generert, og hva du har verifisert selv. Da vet den som reviewer hvor de skal se nøye.

Oppgave: PDF-eksport av faktura fra ordresiden
Generert: InvoicePdfButton.tsx, invoicePdf.ts, tester for begge
Verifisert manuelt: eksport av ordre med 0, 1 og 40 linjer, norsk tegnsett i kundenavn
Ikke rørt: ordre-API, databaseskjema

Når arbeidsflyten ikke passer

Noen oppgaver er dårlig egnet: utforskende arbeid der du ikke vet hva du vil ha, ytelsesoptimalisering som krever måling, og endringer i kode ingen i teamet forstår. Der skriver mennesket selv, og bruker AI til å forklare og foreslå.

Les også Hva AI er dårlig på i kode, og hvordan du sikrer deg.