Bag AI-koden: De skjulte omkostninger ved agent-drevet udvikling
Ud over AI-kode: De skjulte omkostninger ved agent-drevet udvikling
AI hjælper udviklere med at kode hurtigere end nogensinde. Resultaterne kommer i løbet af dage i stedet for uger. Men hurtighed går ikke altid hånd i hånd med kvalitet. Den nyeste bølge af agent-baserede værktøjer viser et klart mønster: Vi har løst det forkerte problem.
Talene skjuler sandheden
Sidste måned kom rapporter med imponerende tal. Nogle udviklere siger, at AI har lavet 100% af deres seneste kode med kun lidt menneskelig justering. Undersøgelser viser, at 70% skriver mindre end halvdelen manuelt. Vi har vendt det om: Fra AI på de sidste 20% til mennesker på de sidste 20%.
Det lyder fantastisk. Produktiviteten eksploderer. Udrulninger sker oftere. Men det overser noget stort: Problemernes art har ændret sig mere end tallene viser.
Nye fejltyper dukker op
De gamle AI-værktøjer fejlede på basale ting. Manglende semikolonner. Forkerte metoder. Fejl i løkker. Lintere fangede dem med det samme.
Nu er fejlene dybere og sværere at spotte.
Forkert antagelse spredes: Agenten misforstår en uklar opgave og bygger et helt feature på det. Tre pull requests senere står du med en skrøbelig arkitektur. Modellen gættede fornuftigt, kørte videre og tvivlede aldrig. Designet sidder fast i koden.
For meget kompleksitet for tidligt: Lad agenten løbe løbsk. Den laver 1000 linjer med fancy struktur, når 100 enkle nok. Unødvendige klasser og rammer. Modellen er ikke doven – den er for grundig.
Kode forringes stille: Agenten roder i nærliggende kode uden fuld forståelse. Fjerner kommentarer. Efterlader død kode. Ændringerne ser isolerede ud i PR'en, men måneder senere jager du fejl fra en gammel refactor.
Undlappelig lydighed: Agenten protesterer aldrig. Den stiller ikke spørgsmål. Den peger ikke på modstridende krav. Den siger ikke "er du sikker?". Den gør bare, hvad du beder om – selvom det er forkert. Den er trænet til at adlyde, ikke tænke kritisk.
Disse fejl er ikke sjældne. De sker trods gode prompts, README-instruktioner og klare planer.
Krisen i tjek af kode
Undersøgelser viser, at kun 48% altid gennemgår AI-kode før commit. Endnu værre: 38% af dem bruger mere tid end på menneskelig kode.
Vi laver plausibel kode hurtigt, men tjekker den ikke godt nok. Flaskehalsen er flyttet fra skrivning til validering – og vi taber.
Forståelsesgæld: Den usynlige regning
Det er lettere at læse kode end at skrive den. Men der er en grænse, hvor læsning bliver til blind godkendelse.
Når AI laver noget, der virker, vil du bare videre. Fristerne banker på. Testerne grønne. Koden ser fin ud. Hvorfor bruge 30 minutter på at forstå, når du kan shippe?
Det her kalder jeg forståelsesgæld. Den vises ikke i dashboards.
Efter måneder har du lag af kode, du kun halvforstår. Systemet kører – mest. Men når det krasher, bliver debug en jagt. Ændringer bliver risikable, fordi du ikke kender afhængighederne.
Problemet med timing
Gælden vokser langsomt. Den dukker ikke op i sprint-rapporter. Den rammer, når nogen skal ændre noget og finder skrøbeligheden. Eller ydeevne falder uden grund. Eller en lille opgave bliver til to ugers arkitektur-debat.
I teams er det værst. Agent A laver kode. Agent B ændrer. Agent C udvider. Antagelser stable sig. Misforståelser spreder sig som telefonspil mellem maskiner uden spørgsmål.
Vejen frem
AI-agenter er ikke fjenden. Gevinstene er ægte, især til nye projekter og klare opgaver. Men tankesættet tæller.
Se AI-kode som udkast, ikke færdigt. Tjek det som en junior-kollegas arbejde. Stil spørgsmål. Kræv begrundelse for kompleksitet. Udfordr antagelser.
Sæt tid af til forståelse. Dyk ned i arkitektur, ikke kun syntax. Kan du ikke forklare valgene, bygger du gæld.
Gør tjek til regel. Lad ikke 48% være normen. Review er et must – især for AI-kode. "Det virker" er ikke "det er godt".
Brug agenter klogt. De er stærke til præcise opgaver. Hold mennesker med på arkitektur, mønstre og krydsende systemer.
Det handler ikke om 80/20. Det handler om at holde mennesker engagerede, så vi fanger fejl, tallene misser. Hurtighed er kun god, hvis den holder.