For ikke så længe siden skrev en programmør, der brugte AI, et spørgsmål til en chatbot, kopierede det genererede kodestykke og indsatte det i projektet. I dag ser denne arbejdsmodel oftere helt anderledes ud.
En programmør kan give en agent en opgave, give den adgang til et repository, lade den analysere eksisterende kode, køre tests, ændre mange filer, rette fejl og derefter forberede ændringen til review. Mennesket forsvinder ikke fra processen. Det er derimod stedet, hvor arbejdet har størst værdi, der ændrer sig.
Ifølge JetBrains Developer Ecosystem Survey 2026, som omfattede over 15.000 professionelle programmører fra hele verden, brugte hele 90% af respondenterne i perioden maj-juli 2026 AI coding agents i arbejdet mindst én gang om ugen, og 68% gjorde det dagligt.
Det er ikke længere et eksperiment for nogle få entusiaster. Det er en ændring af arbejdsmodellen.
AI er ikke længere bare „en kodeassistent”
Det er vigtigt at skelne mellem to ting.
En AI-assistent hjælper programmøren.
En AI coding agent udfører opgaven.
Det er en tilsyneladende lille forskel, men fra et arbejdsmæssigt synspunkt er den enorm.
En assistent kan foreslå en funktion, forklare en fejl, generere et SQL-stykke eller skrive en test. Men det er stadig mennesket, der udfører størstedelen af operationerne.
En agent kan få en langt mere overordnet instruktion:
„Tilføj mulighed for at filtrere ordrer efter status. Undersøg den eksisterende arkitektur. Implementér backend og frontend. Tilføj tests. Kør test suite og ret fejl.”
Og den går i gang.
Den gennemgår projektets struktur. Leder efter relevante filer. Analyserer afhængigheder. Ændrer koden. Kører tests. Får en fejlmeddelelse. Forsøger at rette den. Kører tests igen.
Det er ikke længere autocomplete på steroider.
Det er en opgaveudfører, der arbejder inde i udviklingsmiljøet.
Og her begynder programmørens virkelige rolleaforandring
Hvis AI kan generere flere hundrede linjer kode på få snese sekunder, kan programmørens værdi ikke længere kun måles i antallet af skrevne linjer.
Andre kompetencer begynder at tælle.
Kan programmøren definere problemet godt?
Forstår vedkommende systemets arkitektur?
Ved vedkommende, hvilke oplysninger der skal gives til agenten?
Kan vedkommende vurdere, om løsningen faktisk passer til det eksisterende system?
Kan vedkommende designe tests?
Vil vedkommende opdage, at agenten løste problemet lokalt, men skabte et problem tre lag oppe?
Ved vedkommende, hvornår agenten skal stoppes?
Det betyder et skift i arbejdsbyrden.
Mindre: „Lad os skrive den her kode fra bunden.”
Mere: „Lad os designe løsningen, fastlægge begrænsningerne, give den rette kontekst, kontrollere resultatet og beslutte, om det kan sættes i drift.”
Programmøren begynder at ligne en leder for et lille team
Lad os forestille os et projekt, hvor flere agenter arbejder.
En analyserer den eksisterende kode.
En anden forbereder backend’en.
En tredje arbejder på brugerfladen.
En fjerde genererer tests.
En femte analyserer sikkerheden.
Mennesket kan koordinere deres arbejde, give kontekst og træffe beslutninger.
Lyder det som et udviklingsteam?
På en måde, ja.
Forskellen er, at „medarbejderne” ikke er mennesker.
Og netop derfor opstår der en ny kompetence: styring af agentic development.
Det handler ikke her om at lede mennesker, tidsplaner eller budgetter. Det handler om at styre den arbejdsproces, som udføres af AI-systemer.
Programmøren skal kunne bryde et stort problem ned i opgaver, fastlægge afhængigheder, give den rette kontekst og skabe en mekanisme til at kontrollere resultaterne.
Det ligger langt tættere på en arkitekts arbejde end på klassisk omskrivning af kode.
Programmørens vigtigste værktøj kan i dag være konteksten
En agent er kun så god som de oplysninger, den får.
Man kan sige: „Tilføj brugerpålogging.”
Og man kan sige: „Tilføj brugerpålogging. Systemet bruger den nuværende OAuth-mekanisme. Ændr ikke strukturen i brugertabellerne. Sessioner gemmes på serversiden. Indfør ikke et nyt bibliotek uden begrundelse. Bevar kompatibilitet med mobilappen. Tilføj tests for login, logout, udløbet session og ugyldigt token.”
Den anden instruktion er ikke bare længere.
Den er en bedre specifikation.
Agenten får begrænsninger, forretnings- og teknisk kontekst samt acceptkriterier.
Netop derfor får evnen til at arbejde med kontekst stadig større betydning i en verden med agenter. Programmøren fortæller ikke bare AI, hvad den skal gøre. Vedkommende skal også sige, i hvilket miljø det skal gøres, hvad der ikke må ændres, og hvordan vi ved, at opgaven er udført korrekt.
Den største fejl? At forveksle genereringshastighed med hastigheden for at skabe software
Det er meget vigtigt.
En agent kan generere en funktion på 30 sekunder.
Det betyder ikke, at funktionen er produktionsklar efter 30 sekunder.
Koden skal forstås. Testes. Integreres. Verificeres med hensyn til sikkerhed. Ydelsen skal kontrolleres. Overensstemmelse med arkitekturen skal verificeres. Effekten på de øvrige dele af systemet skal analyseres.
AI kan dramatisk forkorte fasen, hvor koden produceres, men den fjerner ikke behovet for ingeniørarbejde.
Tværtimod.
Jo lettere det er at generere kode, jo lettere er det også at generere dårlig kode.
Og problemet begynder, når mennesket ikke længere er i stand til at forstå det, det har godkendt.
Derfor forbliver mennesket stadig i loopet
Data fra Stack Overflow fra april 2026 viser et meget interessant billede. Brugen af agenter i arbejdet steg til 59%, men 63% af de adspurgte techfolk erklærede, at de sjældent eller aldrig lader agenter handle helt autonomt. 60% af de adspurgte blokerer agenter i at udføre ikke-godkendte ændringer i systemer.
Det viser én vigtig ting.
Markedet bevæger sig ikke bare i retning af: „AI gør alt, mennesket kigger bare på.”
En langt mere realistisk model er: „AI udfører mere og mere arbejde, men mennesket kontrollerer stadig retning, begrænsninger og resultat.”
Det er en fundamental forskel.
Programmøren behøver ikke manuelt at skrive hver eneste funktion. Men vedkommende skal vide, hvorfor en given funktion er blevet til, hvordan den virker, og om den overhovedet bør være i systemet.
Den nye programmør skal kunne flere forskellige verdener på én gang
De klassiske programmørkompetencer er stadig vigtige.
Kendskab til programmeringssprog, databaser, arkitektur, protokoller, sikkerhed, testning og infrastruktur forsvinder ikke bare, fordi AI kan generere kode.
Tværtimod.
Hvis nogen ikke forstår systemet, vil det være svært for dem at vurdere, om den genererede løsning er god.
Dertil kommer dog nye færdigheder.
Programmøren skal forstå modellernes begrænsninger. Skal kunne forberede kontekst. Skal vide, hvordan man fordeler opgaver mellem agenter. Skal kunne designe verifikationsprocessen. Skal forstå omkostningerne ved kald, agenternes rettigheder, adgang til data og risikoen ved automatiske handlinger.
Og frem for alt skal vedkommende lære AI ikke kun at sige: „lav”.
Men også: „lav det på den måde, fordi...”.
Det kan også ændre måden, IT-teams bygges på
I årevis betød skalering af et udviklingsteam at tilføje flere mennesker.
Flere funktioner? - Flere udviklere.
Større projekt? - Større team.
Flere kunder? - Flere personer.
Agentisk udvikling kan ændre dette forhold.
Det betyder ikke automatisk, at én udvikler erstatter ti andre. Det ville være en for simpel antagelse.
Det kan dog betyde, at én erfaren udvikler vil kunne føre tilsyn med et langt større omfang af arbejde, der udføres automatisk.
I praksis betyder det en forskydning af flaskehalsen.
I dag kan begrænsningen være antallet af personer, der kan skrive kode.
I morgen kan begrænsningen være antallet af personer, der kan designe godt, delegere og verificere arbejde udført af AI.
Og hvad med junioren?
Her bliver situationen særligt interessant.
AI kan meget hurtigt generere en løsning, som en junior tidligere ville bruge flere timer på at skrive.
Men junioren ved måske ikke, om løsningen er korrekt.
Det skaber et paradoks.
AI kan fremskynde læringen i programmering, fordi den gør det muligt hurtigere at eksperimentere, stille spørgsmål og analysere løsninger.
Samtidig kan den gøre det sværere at udvikle en grundlæggende forståelse af systemet, hvis den unge udvikler accepterer færdig kode uden at forsøge at forstå, hvordan den virker.
Derfor behøver fremtiden for juniorer ikke betyde: „AI tager deres job”.
Det kan betyde noget mere praktisk: En junior, der kun kan skrive kode, vil få det betydeligt sværere. En junior, der kan forstå kode, teste løsninger, analysere problemer og arbejde med agenter, vil opbygge en helt anden kompetenceprofil.
Det er forskellen mellem en værktøjsoperatør og en ingeniør.
Den dyreste fejl begås stadig af mennesket
En agent kan generere fejlagtig kode.
Men beslutningen om at implementere den kan stadig træffes af et menneske.
Og netop derfor flytter ansvaret for software sig ikke magisk over på AI.
Hvis en agent skaber en funktion, der virker korrekt i et testscenarie, men bryder forretningsreglerne, er problemet ikke, at AI „ikke forstod virksomheden”.
Problemet er den proces, der lod en sådan ændring gå videre.
Det fører til en meget vigtig ændring i måden at tænke kvalitet på.
Det er ikke længere nok blot at spørge: „Skrev udvikleren god kode?”
Man må oftere spørge: „Skabte teamet en god proces for kodning med AI?”
Det er et langt bredere spørgsmål.
Agenten erstatter ikke arkitekten. Den øger arkitekturens betydning
Jo mere kode der kan opstå automatisk, desto større betydning får systemets struktur.
En velgennemtænkt arkitektur gør det muligt for agenten at arbejde inden for bestemte grænser.
En dårligt designet applikation kan derimod få agenten til at omgå problemerne i stedet for at løse dem.
Derfor bliver arkitektur, dokumentation, test, kodestandarder, CI/CD, overvågning og adgangskontrol ikke mindre vigtige, men potentielt endnu vigtigere.
AI kan fremskynde arbejdet i et godt forberedt miljø.
Den vil ikke automatisk rette op på al organisatorisk og arkitektonisk kaos.
Den kan derimod meget hurtigt forstørre det.
Fremtiden tilhører ikke den udvikler, der skriver mest kode
Det er nok den vigtigste konklusion af hele denne forandring.
I lang tid blev programmering forbundet med at skrive kode.
Nu bliver kode stadig billigere og hurtigere at producere.
Det flytter værdien højere op.
I retning af at forstå problemet.
At designe løsningen.
At træffe beslutninger.
Kvalitetskontrol.
Arkitektur.
Sikkerhed.
Integration.
Forståelse af forretningen.
Og dygtig brug af agenter.
Fremtidens udvikler bruger måske mindre tid ved tastaturet, men behøver ikke at have mindre arbejde.
Hans eller hendes arbejde kan bare komme til at se anderledes ud.
I stedet for at skrive hver funktion manuelt vil vedkommende designe den måde, funktionerne bliver til på.
I stedet for selv at rette hver fejl vil vedkommende opbygge en proces, der gør det muligt for agenter at finde og rette fejl.
I stedet for at være den eneste udførende vil vedkommende blive den person, der sætter retningen for flere digitale udførere.
Og måske er det netop derfor, fremtidens vigtigste spørgsmål ikke bliver: „Kan AI programmere?”
Men: „Kan vi bygge software på en måde, hvor AI kan arbejde hurtigt, og mennesket stadig ved, hvad der sker?”
For i en verden med agenter vil den største fordel ikke være blot at have AI.
Den vil være evnen til at kontrollere den.
