Agentic Coding er en fælde: Hvad danske dev-teams skal vide

Investér du i AI-kodningsagenter? Stop. Læs dette først.

Lars Faye, dansk tech-profil og tidligere konsulent hos en af landets største fintech-virksomheder, har for nylig publiceret en kontroversiel påstand, der har fået hele den danske tech-branche til at spærre øjnene op: Agentic coding er en fælde.

Påstanden er simpel: De samme virksomheder, der har investeret millioner i AI-drevne kodningsagenter, ender paradoksalt nok med mere kompleks, uvedligeholdelig kode — præcis de problemer AI'en skulle løse.

Og det er ikke kun Fayes personlige mening. Hacker News-debatten har eksploderet med anekdoter fra udviklere, der fortæller om kodebaser, der er blevet så uigennemskuelige, at de måtte hyre ekstern hjælp bare for at forstå, hvad deres egne AI-agenter havde skabt.

Hvad er agentic coding overhovedet?

Lad os slå fast, hvad vi taler om. Agentic coding er en arbejdsmetode, hvor en AI-agent — ofte drevet af en LLM (Large Language Model) — selvstændigt udfører kodningsopgaver. I stedet for at en udvikler skriver hver linje kode, beskriver udvikleren, hvad der skal bygges, og agenten eksekverer.

Tænk på det som at have en digital praktikant: Du giver opgaven, praktikanten udfører den, og du læser resultatet igennem. Problemet? Den digitale praktikant har læst alle Bøgerne, men aldrig faktisk arbejdet i branchen.

Workflowet tager typisk denne form:

1. Udvikleren definerer projektets krav (både mikro og makro)
2. En plan genereres
3. Agenten "trækker i armene" — itererer og gentager, ofte med flere agent-instanser — indtil opgaven er færdig

Resultatet: Udvikleren ender i rollen som "orchestrator", der styrer agenten, men med stadig større afstand til den faktiske kode, der bliver skabt og commitet.

Problemet: Kompleksitet bygger på kompleksitet

Ifølge Lars Faye og de hundredvis af udviklere, der har deltaget i debatten, er der fire centrale problemer med agentic coding i praksis:

1. Øget systemkompleksitet

AI's non-determinisme — det faktum, at samme prompt kan give forskellige resultater — betyder, at teams bliver nødt til at bygge mere komplekse systemer omkring agenten for at håndtere den øgede usikkerhed. Det, der startede som en automatisering, ender med at blive en ny kompleksitets-lag.

En udvikler på Hacker News beskriver det således: "Jeg har set teams, der har brugt måneder på at bygge pipeline-arkitekturer bare for at få agenten til at opføre sig konsistent. Det er en helt ny form for teknisk gæld — og ingen taler om det."

En anden udvikler tilføjer: "Vi har brugt tre uger på at bygge et kontrolsystem, der skal sikre, at vores agentic coding-setup ikke bryder vores CI-pipeline hver gang den genererer en ny pull request. Det var ikke i nogen roadmap. Det var bare nødvendigt."

2. Skill-atrophying blandt junior-udviklere

Det andet problem er måske endnu mere alarmerende. Mens erfarne udviklere kan bruge agentic coding som et supplement — et "super-læst intern" — risikerer junior-udviklere at miste fundamentale kodningsfærdigheder.

En 35-års veteran i branchen skriver på Hacker News:

"Du har 35 års erfaring og har allerede opbygget læringsrammen til at tilegne dig ny viden. Du ved, hvordan du bruger agentic coding som et værktøj. Men de juniorer, der starter i dag, over-reager på agentic coding og ved ikke, hvad de ikke ved."

Det er fristende at sammenligne med tidligere tech-bølger: Alle frygtede, at outsourcing ville ødelægge vestlig softwareudvikling. I stedet viste det sig, at de virksomheder, der brugte outsourcing strategisk — til commodity-opgaver — holdt deres kernekompetencer in-house. Agentic coding er den næste test: Kan virksomheder lære samme lesson uden at betale for den dyreste undervisning?

3. Vendor lock-in

Claude Code-udfald har allerede haft hele teams stående stille. Når din arbejdsgang er afhængig af en enkelt udbyders infrastruktur, er du sårbar over for nedetid, prisstigninger og strategisk pivot fra udbyderens side.

En fast medarbejders omkostning er fast; tokens er et konstant bevægeligt mål. Og i modsætning til en medarbejder, der kan forhandles med og udvikles, er du som kunde prisgivet udbyderens prissætning.

Virksomheder har rapporteret, at deres API-omkostninger til agentic coding-værktøjer er steget med 200-400% over 18 måneder — ikke fordi de bruger værktøjet mere, men fordi priserne er steget, og fordi mere komplekse opgaver kræver mere processing.

4. Uforudsigelige omkostninger

Priserne på AI-værktøjer stiger, og mange virksomheder har oplevet, at den lovede produktivitetsgevinst hurtigt bliver spist op af stigende API-omkostninger. Det, der startede som en besparelse, ender med at blive en ny bundlinje-post.

DeepClaude: 17x billigere — men løser ikke grundproblemet

Et konkret eksempel, der er blevet flittigt diskuteret i den danske tech-presse, er DeepClaude — et open source-alternativ til Claude Code, der ifølge udviklerne er 17x billigere. Det er en attraktiv proposition: samme funktionalitet til en brøkdel af prisen.

Men her kommer det interessante: DeepClaude løser ikke de grundlæggende problemer med agentic coding. De lavere omkostninger får det bare til at virke mere tilgængeligt — og dermed mere fristende — at adoptere en arbejdsmetode, der fundamentalt set har strukturelle svagheder.

DeepClaude er som at få en billigere slotmaskine: Du spinner måske gratis, men huset vinder stadig på længere sigt.

Open source-alternativer som DeepClaude er værd at holde øje med — de demokratiserer adgangen til værktøjerne — men de ændrer ikke på den fundamentale dynamik: mere kompleks kode, skill-atrophying og vendor lock-in er ikke problems, der løses ved at skifte udbyder.

Hvad gør erfarne danske teams i stedet?

Ifølge de mest respekterede stemmer i debatten er der en klar skill-kurve, når det kommer til agentic coding:

• Senior-udviklere (5+ års erfaring): Bruger agentic coding som et supplement og har allerede de nødvendige færdigheder til at spotte problemer i genereret kode.
• Junior-udviklere (0-3 års erfaring): Risikerer at opbygge en forståelse af kodning, der er afhængig af AI-støtte fra dag ét — med alle de førnævnte risikoer til følge.

En erfaren udvikler på Hacker News udtrykker det således:

"Jeg lærer stadig mere om sprog, systemer og værktøjer de sidste par år med agentic coding, end jeg gjorde i 35 års håndværksmæssig programmering. Men de er som en virkelig godt læst praktikant, der ved en masse detaljer om errata, men har meget lidt erfaring. De laver fejl med begejstring, men tager feedback — i hvert fald i starten."

Denne metafor er værd at dvæle ved: En praktikant, der ved alt om teorien, men intet om praksis. Agentic coding-værktøjer har læst hele internetten, men de har aldrig siddet ved en computer og fejlet i tre timer på en stupid typo.

Konkret guidance til danske SMV'er

Så hvad skal danske virksomheder gøre? Her er vores anbefalinger baseret på de mest nuancerede stemmer i debatten:

For ledelsen (ikke-tekniske beslutningstagere)

1. Spørg dit dev-team: Hvilke konkrete problemer forsøger I at løse med agentic coding? Hvis svaret er "produktivitet", så bed om specifikke tal.
2. Undgå at tvinge agentic coding nedover teams. Investér i tools, men lad teamet selv vælge, hvornår de bruger dem.
3. Budgetter for træning. Hvis I indfører agentic coding, så investér samtidig i at sikre, at junior-udviklere stadig lærer fundamentale færdigheder. Overvej mentorship-programmer, hvor senior-udviklere aktivt deler deres viden.
4. Mål ROI løbende. Tjek ikke bare produktivitets-tal, men også kode-kompleksitet, teknisk gæld og medarbejder-engagement.

For tech leads og arkitekter

1. Implementér meningsfulde code reviews. AI-genereret kode kræver mere gennemgang, ikke mindre.
2. Sæt grænser for, hvad agenten må ændre. Automatiske commits uden menneskeligt tjek er en risikofaktor. Sæt en regel: alt over X linjers ændring kræver en eksplicit godkendelse.
3. Hold øje med teknisk gæld. Mål kodenkompleksitet og ændringer i dit codebase over tid.
4. Dokumentér agent-konfigurationer. Hvis I bruger agentic coding, så dokumentér præcis hvilke prompts, modeller og pipeline-opsætninger I bruger. Det gør det lettere at lære af fejl og lettere at skifte udbyder.
5. Prioritér læsbarhed. Når I accepterer AI-genereret kode, så refactor for læsbarhed før I committer. Den tid, det tager, sparer I senere.

For individuelle udviklere

1. Brug agentic coding til at lære, ikke til at erstatte læring. Når agenten genererer noget, der virker interessant: undersøg det, forstå det, kritiser det.
2. Vær kritisk over for output. LLM'er genererer ikke kun fakta — de producerer også "korrekt udseende" kode med subtile fejl. Tests er ikke valgfrie, de er obligatoriske.
3. Hold fundamenterne vedlige. Læs stadig kode, skriv stadig tests, forstå stadig systemets arkitektur.
4. Vær din egen lærling. Når agenten foreslår noget, så prøv at forstå, hvorfor det er den foreslåede løsning. Spørg agenten. Lær af dens forklaringer.

Tjekliste: Er jeres brug af agentic coding bæredygtig?

Brug denne tjekliste til at vurdere, om jeres nuværende tilgang er forsvarlig:

• Alle AI-genererede commits reviewes af et menneske med domæneviden
• I har dokumenteret prompts og konfigurationer — ikke kun internt i værktøjet
• Nye udviklere kan bidrage til kodebasen uden adgang til den specifikke AI-platform
• I måler teknisk gæld over tid — ikke kun produktivitet
• Der er en exit-strategi, hvis den aktuelle platform ændrer priser eller tilgængelighed
• Junior-udviklere får stadig tid til at lære fundamentale færdigheder uden AI-assistance
• I har en person med det overordnede arkitektur-overblik — og den person er ikke afhængig af AI'en for at forklare systemet
• Onboarding-tiden for nye medarbejdere er ikke steget markant siden I indførte agentic coding

FAQ: Agentic coding i praksis

Er agentic coding altid en dårlig idé? Nej. For erfarne udviklere, der arbejder med velkendte domæner, kan agentic coding være et effektivt værktøj. Problemet opstår, når det bliver brugt som erstatning for fondamentaledygtigheder.

Hvordan spotter jeg, om mit team er blevet for afhængige af AI-kodning? Kig efter disse tegn: Uforklarlig kode, der ikke kan spores til en specifik beslutning. Faldende code review-kvalitet. Juniorsamarbejdere, der ikke kan svare på, hvorfor bestemt kode ser ud, som den gør.

Hvad med DeepClaude — bør jeg prøve det? DeepClaude kan være en god indgang til agentic coding-værktøjer, men det løser ikke de grundlæggende problemer. Hvis du prøver det, så gør det med klare forventninger og dokumentér dine resultater.

Hvordan håndterer jeg vendor lock-in? Start med at have en exit-strategi. Brug agentic coding til opgaver, der let kan omskrives manuelt. Undgå at lade agenten bygge mission-critical infrastruktur uden menneskeligt tjek.

Er AI-kodningsværktøjer bare en fase? Det er sandsynligt, at vi ser en modreaktion — ligesom med alle store tech-bølger. Men de teams, der lærer at bruge værktøjerne kritisk og bevare deres core skills, vil være bedre stillet uanset hvad der kommer.

Hvad er den største fejl, virksomheder laver med agentic coding? Den største fejl er at behandle det som en omkostningsbesparelse snarere end en produktivitets-forstærker. Agentic coding giver mest værdi, når det frigør senior-udviklere fra repetitive opgaver — ikke når det erstatter junior-udvikleres læring.

Bør jeg ansætte folk baseret på deres agentic coding-erfaring? Dette er et advarselstegn. Deudviklere, der har brugt agentic coding som deres primære arbejdsmetode fra starten, mangler ofte den grundlæggende forståelse, der gør dem i stand til at kritisere og forbedre AI-genereret kode.

Konklusion: Vær kritisk, ikke naiv

Agentic coding er ikke enten en fælde eller en mirakel-løsning. Det er et værktøj — og som alle værktøjer afhænger dets værdi af, hvem der bruger det, og hvordan.

For danske SMV'er med erfarne dev-teams kan det være en produktiv tilføjelse til værktøjskassen. For teams med mange junior-udviklere og begrænset erfaring med kritisk kodeevaluering, kan det paradoksalt nok skabe flere problemer, end det løser.

Løsningen er ikke at afvise AI-kodning helt — men at investere i den menneskelige ekspertise, der skal til for at få mest muligt ud af det, uden at miste fundamentet undervejs.

Det kræver, at vi som branche tænker os om én gang til, før vi hopper på den næste bølge. De virksomheder, der gør det, vil være bedre stillet end dem, der løber efter hype.

Vil du vide mere om, hvordan CopenAI kan hjælpe dit team med at navigere AI-landskabet? Kontakt os for en uforpligtende snak.

---

Om forfatteren: Rico Rosenkrans er Senior AI Konsulent hos CopenAI og har arbejdet med AI-implementation i danske virksomheder i over 5 år.