Verktøy som Claude Code og GitHub Copilot endrer hvor lang tid det tar å produsere kode. De endrer ikke hvem som må forstå den om to år.

Jeg bruker slike verktøy daglig, og de er nyttige. Men de har flyttet flaskehalsen i utviklingsarbeid, ikke fjernet den. Skriveren er blitt rask; leseren, den som skal vurdere om koden er riktig og vedlikeholdbar, er fortsatt et menneske med erfaring. Dette er den viktigste avveiningen for en bedrift som vurderer hva AI betyr for utviklingsbudsjettet.

Hva verktøyene faktisk er gode til

De er sterke på arbeid som er godt definert og kjedelig: skrive tester for kode som finnes, konvertere et dataformat til et annet, lage et første utkast av en integrasjon mot et API med god dokumentasjon, rydde i navngiving på tvers av mange filer, skrive migrasjonsskript. Alt dette er oppgaver der riktig svar kan kjennes igjen når man ser det.

De er også gode på å komme i gang. Et tomt prosjekt med byggeoppsett, prosjektstruktur og et par eksempler er ofte gjort i minutter i stedet for en halv dag. For en liten leverandør er det reell verdi: mer av tiden går til det kunden faktisk betaler for.

Hvor de er svakest

Svakheten ligger i alt som krever kontekst verktøyet ikke har. Hvorfor systemet ble bygget slik det ble. Hvilken av to like gode løsninger som passer til driftsmiljøet kunden har. Hvilke antagelser i kravspesifikasjonen som er feil. Hvilke deler av kodebasen som ser stygge ut fordi noen tok en bevisst avgjørelse for fire år siden.

En annen svakhet er mer subtil: resultatet ser alltid ferdig ut. Kode som er nesten riktig, leses som kode som er riktig, fordi den er velformatert og har fornuftige navn. Feil som tidligere avslørte seg selv ved at koden var rotete, er nå pent innpakket.

Vedlikeholdbarhet er ikke det samme som at det virker

En applikasjon i drift er ikke ferdig, den er et ansvar. Den skal utvides, feilrettes, oppgraderes når rammeverket får ny hovedversjon, og til slutt overtas av noen andre. Kostnaden over levetiden ligger i disse tingene, ikke i den første leveransen.

Da betyr det mindre hvor koden kom fra, og mer om den har egenskapene som gjør endring trygt: en struktur noen kan forklare, navn som beskriver hva ting er i kundens domene, tester som faktisk feiler når oppførselen endres, og ingen duplisering av samme logikk på fire steder. Genererer du raskt uten å stille de kravene, får du et system som virker nå og er dyrt å røre senere.

Det klassiske eksempelet er duplisering. Får du generert den samme valideringen i fem endepunkter fordi det var raskt hver gang, er systemet fullt funksjonelt. Så endres regelen, og noen må finne alle fem.

Kompetansen er det som gjør gevinsten varig

Dette er kjernen. Verktøyene gir mest verdi til den som allerede kan faget, fordi gevinsten avhenger av evnen til å vurdere svaret. Det krever at man kan lese kode raskt, kjenner mønstrene i språket og rammeverket, og vet hvordan det aktuelle systemet henger sammen.

Konkret er det noen spørsmål jeg stiller til alt jeg får generert, og de er de samme jeg ville stilt i en vanlig kodegjennomgang. Hva skjer her ved feil eller tom respons? Er dette en spørring som skalerer når tabellen har millioner av rader? Hører denne logikken hjemme her, eller er den lagt der det var lettest? Finnes dette allerede et annet sted i kodebasen? Er det lagt til en avhengighet vi ikke trenger?

Uten den kompetansen blir resultatet en kodebase ingen i organisasjonen egentlig kjenner. Den kan være ryddig og velfungerende, og likevel være et problem, fordi endringer må gjøres av noen som må lese seg opp fra bunnen hver gang. Det er den samme situasjonen som når en ekstern utvikler forsvinner uten dokumentasjon — bare at man ikke merker det før første endringsbehov.

Arkitektur og avgjørelser kan ikke delegeres

Det finnes en klasse beslutninger som må tas av noen som har ansvaret for konsekvensen: hvordan data modelleres, hvor grensene mellom tjenester går, hvilke deler som må kunne endres ofte, hva som skal logges og hvor lenge. Slike valg blir vanskelige å reversere fort, og de avhenger av kunnskap om kunden og driftsmiljøet.

Verktøyene kan gjerne brukes til å utrede alternativer — de er nyttige som samtalepartner i en designfase. Men valget mellom alternativene er ingeniørarbeid, og ansvaret for det kan ikke legges hos et verktøy.

Praktiske regler jeg holder meg til

Små, avgrensede oppgaver av gangen, med tydelig kontekst, framfor «bygg denne funksjonen». Alt leses før det committes, og jeg committer aldri noe jeg ikke kunne forklart i et møte. Tester skrives eller gjennomgås med samme skepsis som koden, ellers kan man ende opp med tester som bekrefter feil oppførsel. Nye avhengigheter behandles som et bevisst valg, aldri som noe som glir inn fordi et utkast brukte dem.

Og for hemmeligheter: aldri nøkler, passord eller pasientdata inn i en forespørsel. I regulerte miljøer er det også et spørsmål om hva som er avklart med kunden i det hele tatt — noen kunder har krav som gjør at en ekstern tjeneste ikke kan se kildekoden. Det avklares før, ikke etter.

Hva dette bør bety for et innkjøp

Om en leverandør bruker AI-verktøy, er i seg selv ikke et kvalitetstegn eller et faresignal. Spørsmålene som betyr noe er de samme som før: kan de forklare hvordan løsningen er bygget og hvorfor, finnes det tester som beskriver oppførselen, kan en ny utvikler settes inn uten at alt må skrives om, og hva koster det å endre noe om ett år.

Det er også rimelig å spørre konkret hvordan verktøyene brukes — om generert kode gjennomgås, og om kildekode eller data sendes til eksterne tjenester. Et tydelig svar på dette sier mer om leverandørens modenhet enn hvilke verktøy de har i bruk.

For egen del: jeg bruker AI der det sparer tid på arbeid som kan verifiseres, og holder arkitektur, datamodell og gjennomgang hos meg. Kunden skal sitte igjen med et system som kan vedlikeholdes av andre enn den som skrev det — det er det eneste målet som betyr noe over tid.