Ut over AI-kodegenerering: De skjulte kostnadene ved agentdrevet utvikling

AI-verktøy har gjort utviklere raskere enn noensinne. Kode blir levert på rekordtid. Men hastighet går ikke alltid hånd i hånd med kvalitet. Den nye bølgen av agentbasert utvikling viser et klart mønster: Vi har løst feil problem.

Tallene skjuler virkeligheten

Bransjen rapporterte ferske tall i forrige måned. Noen utviklere sier at 100 prosent av ny kode kommer fra AI-agenter, med knapt menneskelig tilsyn. Undersøkelser viser at nesten 70 prosent skriver mindre enn halvparten manuelt. Vi har snudd det opp ned – fra "AI fikser de siste 20 prosent" til "mennesker fikser de siste 20 prosent".

På overflaten ser det ut som en revolusjon. Produktiviteten skyter i været. Deployments går fortere. Sideprosjekter som tok uker, er ferdige på dager.

Men overskriftene overser det viktigste: Problemene har endret karakter mer enn tallene antyder.

Nye typer feil som lurer i det skjulte

Tidlig AI slet med enkle ting. Manglende semikolon. Feil metodesignaturer. Off-by-one-feil i løkker. Slike ting fanget lintere opp på sekundet.

Nå er utfordringene dyptgående og snikende.

Feilaktige antagelser sprer seg: Agenten tolker et uklart krav galt og bygger hele funksjoner på løs grunn. Tre PR-er senere oppdager du at arkitekturen står på sand. Modellen gjettet fornuftig, kjørte på, og stilte aldri spørsmål. Da du merker det, er designmønstrene limt fast overalt.

Overdreven kompleksitet tidlig: La agenten løpe løpsk, og den prioriterer fullstendighet over enkelhet. Du får 1000 linjer med avansert struktur der 100 rene linjer holder. Unødvendige abstrakte basisklasser i stedet for funksjoner. Ekstra rammeverk. Agenten er ikke lat – den er for grundig.

Stille kodeforringelse: Agenter rydder ikke alltid opp. De endrer nærliggende kode de ikke forstår fullt ut. Fjerner kommentarer som bivirkning. Etterlater død kode. Endringene virker isolerte i PR-en, men seks måneder senere jakter du feil fra en "god" refactor to commits unna.

Dokumentert lydighet: Det ubehagelige er at agenter sjelden protesterer. De stiller ikke oppfølgingsspørsmål. De peker ikke på motsetninger i kravene. De sier ikke "er du sikker?". De gjør akkurat hva du ber om, selv om det er nonsens. De er tunet for å adlyde, ikke tenke kritisk.

Dette er ikke sjeldne tilfeldigheter. Det er systematiske feil som overlever prompts, README-instruksjoner og forhåndsplaner.

Verifiseringskrisen

Undersøkelser viser at bare 48 prosent av utviklere alltid sjekker AI-kode før commit. Verst: 38 prosent av de som gjør det, bruker mer tid enn på menneskelig kode.

Vi produserer plausibel kode raskere, men validerer dårligere. Flaskehalsen har flyttet seg fra generering til kontroll – og vi taper terreng.

Forståelsesgjeld: Den usynlige regningen

Å skrive kode er enklere enn å lese den. Du kan forstå andres arbeid uten å gjenskape det. Men det finnes en grense der forståelse blir stempling.

Når agenten spytter ut kode som funker (eller ser ut til å funke), frister det å gå videre. Deadline presser. Tester grønne. Koden virker ok. Agenten er klar for neste oppgave. Hvorfor bruke 30 minutter på å forstå når du kan shippe?

Dette er forståelsesgjeld – upåvirket av dashboards.

Over tid bygger du lag på lag med halvforstått kode. Systemet henger sammen, stort sett. Men evnen til å resonnere om delene forsvinner. Feilfeilsøking blir detektivarbeid. Endringer blir risikabelt, siden du ikke vet avhengighetene.

Tidsperspektivet

Forståelsesgjeld vokser med forsinkelse. Den dukker ikke opp i sprint-rapporter. Den slår til når noen endrer noe og finner skjørhet. Eller ytelse faller mystisk. Eller en enkel feature blir to ukers arkitekturdebatt.

I team blir det verre. Agent A lager kode, B endrer, C utvider. Antagelser stables. Misforståelser sprer seg som meldingspill uten spørsmål.

Veien videre

AI-agenter er ikke skadelige. Produktivitetsgevinstene er ekte, spesielt for nye prosjekter og klare oppgaver. Men tankesettet avgjør.

Behandle AI-kode som utkast, ikke ferdigvare. Gi den samme skepsisen som en junior-utviklers arbeid. Still spørsmål. Krev begrunnelse for kompleksitet. Utfordre antagelser.

Prioriter forståelse. Bruk tid på arkitektoniske valg, ikke bare syntaks. Kan du ikke forklare strukturen, samler du gjeld.

Gjør verifisering til vane. 48 prosent er for lite. Kreve code review, spesielt for AI-kode. "Funker" er ikke "bra nok".

Bruk agenter smart. De skinner på definerte oppgaver. Hold mennesker med på arkitektur, design og tverrsystemarbeid.

Problemet handler ikke om 80/20-andeler. Det handler om prosesser der mennesker fanger feil metrics overser. Hastighet teller bare hvis den bygger varig kode.