For ikke så længe siden handlede samtalen om kunstig intelligens i programmering hovedsageligt om ét spørgsmål: vil AI tage programmørernes arbejde? I 2026 er det spørgsmål ved at være forældet. AI skriver allerede kode, laver tests, analyserer repositories, foreslår rettelser, forbereder pull requests, og stadigt mere avancerede agenter kan udføre hele sekvenser af opgaver uden, at en udvikler skal styre dem skridt for skridt.
Problemstillingen har derfor ændret sig.
Vi spørger ikke længere kun, om AI kan programmere.
Vi spørger, hvem der har ansvaret for software, som AI har programmeret.
Og det er et langt vigtigere spørgsmål.
Kodning er blevet hurtigere. At bygge godt software er det ikke nødvendigvis
Lad os starte med én ting: det giver ingen mening at lade som om, at AI i programmering er en midlertidig trend. Den er ikke.
AI-værktøjer trænger stadig dybere ind i den daglige softwareudviklingsproces. Fra simple forslag til enkelte kodefragmenter er vi gået til agenter, der kan analysere et større projektkontekst, ændre mange filer, køre tests, reagere på fejl og forberede ændringer til menneskelig verifikation. Markedet udvikler sig mod agent-baseret softwareudvikling, ikke kun klassisk autocomplete.
Det er en enorm produktivitetsændring.
En udvikler behøver ikke længere skrive hvert eneste kodefragment fra bunden. De kan give AI en opgave, få en første implementering, teste den, rette til og gå videre til næste problem.
Og her opstår et paradoks.
Jo lettere det er at skrive kode, desto mindre værdi har selve at skrive koden.
Til gengæld får spørgsmålet mere værdi: hvad skal egentlig skrives, hvordan skal det virke, og hvordan sikrer vi, at det er gjort korrekt?
Det er forskellen mellem at generere kode og softwareengineering.
"Det virker" er kun begyndelsen
Enhver developer kender situationen, hvor noget virker. Endpointet returnerer et svar. Formularen sendes. En record gemmes i databasen. Knappen udfører handlingen. En test passerer. Så kan man sige: færdig.
Men god softwareengineering begynder netop dér.
For senere dukker spørgsmålene op:
- Er løsningen sikker?
- Fungerer den under høj belastning?
- Hvad sker der, hvis en bruger indtaster uventede data?
- Håndterer den fejl ordentligt?
- Kan den nemt udvides?
- Vil en anden udvikler forstå koden om et år?
- Er løsningen i overensstemmelse med systemets arkitektur?
- Duplikerer den logik, der allerede findes andre steder?
- Skaber den teknisk gæld?
- Testen verifierer virkelig korrekt adfærd, eller bekræfter den blot, at koden gør præcis, hvad forfatteren forventede?
AI kan hjælpe med at svare på nogle af disse spørgsmål. Den kan også hjælpe med at lave tests, finde potentielle problemer eller foreslå refaktoreringer. Men den fritager ikke organisationen fra ansvaret for svarene.
Det farligste kode er ikke det, der ikke virker
Kode, der straks fejler, er relativt nemt at finde.
Meget mere farligt er kode, der fungerer tilstrækkeligt godt til at nå produktion, men har problemer, som ikke er synlige ved første øjekast.
Den kan være unødigt kompliceret. Den kan duplikere eksisterende logik. Den kan indeholde fejl i håndteringen af edge cases. Den kan have performance-problemer. Den kan bruge biblioteker eller mønstre, som teamet ikke ønsker i projektet.
Og den kan se meget professionel ud.
Det er netop en af fælderne ved generativ AI; kode kan være overbevisende, før den er god.
En Sonar-undersøgelse offentliggjort i 2026 viser, at 53% af udviklere tilskrev AI en negativ indflydelse på teknisk gæld ved at generere kode, som så korrekt ud, men viste sig ustabilt.
Det betyder ikke, at AI kun producerer dårlig kode. Det betyder noget mere praktisk: mere genereret kode er ikke automatisk mere værdi.
AI kan også accelerere ophobningen af teknisk gæld
Forestil dig et klassisk projekt.
Før AI kunne en developer bruge to dage på at bygge en funktion. Efter AI tager den en halv dag. Fantastisk.
Men hvad hvis antallet af ændringer i projektet samtidig stiger flere gange?
Hvad hvis i stedet for én gennemtænkt implementering opstår fem lignende?
Hvad hvis nye funktioner tilføjes hurtigere, end teamet kan refaktorere?
Hvad hvis kode regelmæssigt genereres af forskellige modeller med forskellige antagelser om arkitektur?
Så øger AI ikke kun produktiviteten. Den kan også øge tempoet for ophobning af teknisk gæld.
En GitClear-analyse af 211 mio. linjer kode viser en stigning i kode-duplikation i den analyserede periode, og forfatterne forbinder denne trend blandt andet med populariseringen af AI-assisteret kodning. Det er ikke bevis for, at hver linje genereret af AI er dårlig, men et tydeligt signal om, at højere forandringshastighed kræver stærkere kvalitetskontrol.
Her gælder en vigtig regel: hvis AI øger hastigheden for at skrive kode, må verifikationsprocessen også udvikle sig.
Man kan ikke blot fordoble produktionen af kode og lade resten af processen være uændret.
"AI vil selv tjekke sin kode"
Det lyder fristende. AI skrev en funktion. En anden AI tjekker den. En tredje laver tests.
Problem løst? - Ikke nødvendigvis.
I 2026 ser vi oftere situationer, hvor én agent skriver kode, og en anden laver review. Der opstår dermed en lukket AI-til-AI loop: én agent laver ændringen, en anden analyserer den, og organisationen kan acceptere resultatet uden tilstrækkelig menneskelig involvering. Studier af dette mønster viser, at AI-to-AI code review vokser, omend det stadig er en minoritet af agentaktiviteten.
Det kan være meget værdifuldt. Men det har også en fundamental begrænsning - to AI’er kan begå samme slags fejl.
Hvis den kodeskrivende agent bygger på en forkert forretningsantagelse, kan review-agenten overse det. Hvis begge systemer er baseret på lignende mønstre, kan de begge overse samme problem.
Derfor skal mennesket stadig være en del af processen. Ikke som en, der manuelt omskriver kode. Men som en, der forstår systemet, forretningskonteksten, risikoen og konsekvenserne af tekniske beslutninger.
Fremtidens udvikler vil ikke være mindre ansvarlig. Vedkommende får mere ansvar
Det er en vigtig ændring.
Man kan forestille sig en udvikler, der tidligere brugte 70% af tiden på implementering, og som takket være AI i dag kan bruge langt mere tid på analyse, arkitektur, test, review og problemløsning.
Det er et positivt scenarie.
Udvikleren behøver ikke være en maskine, der kun skriver kode. Han eller hun kan blive endnu mere ingeniøragtig. Problemet opstår, når organisationen tolker øget produktivitet udelukkende som mulighed for at reducere nødvendige arbejdstimer.
Sålandt er det nemt at ende i et absurd model: "Hvis AI gjorde det på en time, hvorfor tog det tidligere tre dage?"
Men de tre dage indeholdt måske analyse, arkitektur, tests, review, rettelser, integration, dokumentation og deployment.
Kodning var kun en del af arbejdet.
Hvad med sikkerheden?
Her bliver sagen endnu vigtigere.
Genereret kode kan indeholde sårbarheder, forkerte antagelser om autorisation, utilstrækkelig datavalidering eller farlig brug af biblioteker.
Det er derfor ikke nok at sige: "AI har tjekket koden".
Forskning i AI-drevet code review viser, at sådanne værktøjer ikke bør erstatte dedikerede sikkerhedsmechanismer og manuel audit. I en undersøgelse af GitHub Copilot Code Review pegede forfatterne på problemer med at opdage visse kritiske sårbarheder, herunder SQL injection, XSS og insecure deserialization.
Det fører til en sund regel: AI kan være en del af sikkerhedsprocessen. Den bør ikke være den eneste sikkerhed. Især ikke for applikationer, der behandler kundedata, betalinger, dokumenter, medarbejderdata eller forretningskritisk information.
Det største problem opstår, når det er uklart, hvem der tog beslutningen
I traditionelle processer kan man spore ændringen.
En udvikler skrev koden.
Et pull request blev oprettet.
Nogen reviewede det.
Tests blev kørt.
Ændringen blev deployet til produktion.
I en agentdrevet udviklingsverden bliver processen mere kompleks. En agent kan udføre dusinvis af operationer. Den kan ændre mange filer. Den kan generere tests. Den kan rette fejl selv. Den kan forberede et pull request.
Derfor bliver governance-regler for AI i softwareudviklingsprocessen stadigt vigtigere.
Hvem må køre en agent?
Hvilke repositories har den adgang til?
Må den ændre produktionskode?
Må den køre database-migrationer?
Må den installere afhængigheder?
Må den bruge produktionsdata?
Hvem godkender dens ændringer?
Har hver ændring et audit-spor?
Kan man genskabe, hvorfor en beslutning blev taget?
Disse er ikke spørgsmål af typen "AI vil måske blive vigtig senere". Det er spørgsmål om softwareudviklingsprocessen nu.
Det er ikke tilfældigt, at developer-værktøjer begynder at tilføje funktioner til kontekstkontrol, kodestandarder, agent-review og overvågning af agentbrug. At sådanne mekanismer bliver en del af developer-værktøjerne viser retningen: en agent kan ikke bare være en "ekstra programmør", den skal være en del af en kontrolleret engineering-proces.
"Vibe coding" er fantastisk. Indtil et vist punkt
Der er intet galt i at eksperimentere.
Vil du lave en prototype? AI er fantastisk.
Skal du hurtigt teste en idé? Perfekt.
Vil du lave et proof of concept? Endnu bedre.
Et lille internt automation? Måske kan AI lave det meste arbejde.
Problemet opstår, når en prototype begynder at blive behandlet som et produkt.
Pludselig går "lad os lave det hurtigt" over i "lad os integrere det med CRM".
Så: "lad os tilføje betalinger".
Næste skridt: "lad os få 500 brugere".
En måned senere: "hvorfor er systemet så langsomt, og hvorfor kan ingen andre end forfatteren videreudvikle det?"
En prototype kan være hurtig. Et produkt må være designet. Det er en stor forskel.
AI fjerner ikke ansvaret. Den flytter det højere op
Og dette er måske den vigtigste konklusion i diskussionen.
Hvis en udvikler tidligere primært var ansvarlig for korrekt kode, er vedkommende i dag ofte ansvarlig for en langt bredere proces: forståelse af problemet, valg af løsning, kontrol af kvaliteten af genereret kode, sikkerhed, tests, arkitektur, vedligeholdelsesmuligheder og overensstemmelse med forretningskrav.
AI kan udføre en del af arbejdet. Men den bør ikke automatisk overtage ansvaret.
Aktuelle begivenheder i AI-verdenen viser, at kontrolproblemet ikke længere er teoretisk. For nylig er der rapporteret hændelser, hvor agenter i udviklingsmiljøer havde indflydelse på eksterne afhængigheder, herunder OpenAI-agenter, der angiveligt påvirkede RubyGems under tests. OpenAI bekræftede agenternes involvering og gav forklaringer om hændelsen.
Det er et godt eksempel på, hvorfor øget autonomi i AI øger betydningen af adgangsbegrænsning, sandboxing, monitorering og menneskelig kontrol.
AI kan få adgang til kode. Det betyder ikke, at den bør have adgang til alt.
Hvad bør et godt softwarehus gøre?
Først og fremmest: lade være med at lade som om, AI ikke eksisterer. Tværtimod.
Brug den, hvor den reelt øger teamets produktivitet: ved kodeanalyse, prototyping, dokumentation, tests, refaktorering, generering af gentagne elementer og fejlanalyse.
Men behold samtidig klassiske softwareengineering-principper.
Arkitektur betyder stadig noget.
Code review betyder stadig noget.
Tests betyder stadig noget.
Sikkerhed betyder stadig noget.
Dokumentation betyder stadig noget.
Udviklerens erfaring betyder stadig noget.
Og vigtigst af alt betyder det stadig noget, at et menneske kan sige: "Ja, AI genererede denne kode. Men inden vi deployer den, skal vi undersøge, om vi overhovedet burde skrive den sådan."
Det dyreste kan være ikke, hvad du betaler for at skrive koden
Det er et perspektiv, man bør ændre.
Hvis AI kan skabe en funktion på en brøkdel af tiden, er det fantastisk. Men omkostningen ved software slutter ikke ved den første deployment.
Systemet skal videreudvikles.
Det skal integreres med flere tjenester.
Kravene vil ændre sig.
Nye enheder, browsere, betalingssystemer, regler og kundebehov vil dukke op.
Nogen skal tilbage i koden om et år.
Nogen skal finde en fejl kl. 02:00 om natten.
Nogen skal udføre migrationer.
Nogen skal sikre systemet.
Så viser det sig, om virksomheden virkelig sparede penge ved hurtig udvikling, eller blot flyttede omkostningen til senere.
Derfor handler ægte værdi ikke om at få AI til at skrive så meget kode som muligt.
Værdien ligger i at bruge AI til at bygge bedre software hurtigere, uden at miste kontrollen over, hvad der bliver bygget.
Hos Web24 ser vi AI som et værktøj, ikke en erstatning for engineering
AI kan være et fremragende teammedlem.
Den kan øge arbejdsfarten.
Den kan tage gentagne opgaver.
Den kan hjælpe udviklere med at analysere store mængder kode.
Den kan forkorte vejen fra idé til en første fungerende løsning.
Men mellem "det virker" og "klargjort til at køre i fem år" ligger et stort rum.
Det er netop der, rigtig softwareengineering begynder. For i dag er det lettere end nogensinde at generere kode. Det er sværere at bygge et system, man trygt kan tage ansvar for. Og måske bliver netop den evne en af de vigtigste kompetencer for softwarehuse i de kommende år.
Ikke alene at skrive kode.
Ikke alene at bruge AI.
Men evnen til at kombinere AI, menneskelig erfaring, arkitektur, sikkerhed og ansvar for hele systemet.
