Hvorfor Out-of-the-Box AI Irriterer Teams — og Hvad Man Kan Gøre Ved Det

Med de fleste teknologier er det sådan, at jo længere man bruger dem, jo mere roligt kommer man til at stole på dem. Med AI-værktøjer har det modsatte været sandt: i deres årlige undersøgelse af mere end 49.000 udviklere, optegnede Stack Overflow en stigning i brugen til 84%, selvom tilliden til nøjagtigheden af disse værktøjer faldt fra 40% til 29% på blot ét år.

Dette efekt er velkendt for mig. Vores egen første oplevelse med AI-værktøjer i udviklingen havde lidt at gøre med wow-effekten af hurtigere arbejde og mindre slid, som tech-pressen skrev om. Vores udviklere blev skuffet: AI producerede middelmådig kode, der tog lang tid at gennemgå, og som til sidst måtte skrives om. Holdet forventede, at AI ville spare tid, men fik i stedet ekstra arbejde. Så ikke længe efter disse første forsøg på at integrere AI-værktøjer i den daglige arbejdsproces, gik holdet tilbage til at arbejde på den måde, de altid havde.

I dag accelererer disse værktøjer både skrivning af kode og gennemgang af den for vores udviklere — ikke fordi vi fandt en bedre model, men fordi vi ændrede, hvordan vi arbejder med den. Her er, hvad der hjalp os til at komme dertil.

Hvorfor AI-Skrevet Kode Irriterer Udviklere

AI bygger på en enorm mængde offentlig kode fra hele internettet, og denne kode er sjældent eksemplarisk: dens kvalitet er gennemsnitlig, og modellen reproducerer dette gennemsnit.

“Gennemsnit” er ikke grænsen for, hvad der er muligt — det er blot, hvad modellen producerer, indtil den kender dit projekt: dets konventioner, dets kodestruktur, dets arkitektoniske beslutninger. I en undersøgelse af over 600 udviklere fandt Qodo ud, at blandt dem, der var utilfredse med kvaliteten af AI-kode, tilskrev 44% det præcis manglen på kontekst. Det er, hvad holder outputtet fast på et middelmådigt niveau.

Det gode nyheds er, at konteksten, som AI modtager, er det eneste variable, som et hold har fuld kontrol over. Hvordan godt værktøjet forstår projektet, afhænger ikke af modellen, men af, hvad man giver den.

Den anden grund er mental — selv naturen af arbejdet ændrer sig. Når AI skriver det meste af koden, er udviklerens hovedakt ikke længere at skrive, men at gennemgå, hvad der er genereret: at læse en andens løsning, at veje alternativerne, at beslutte, hvad der er klar til at sende. Det er en anden færdighed end at skrive kode selv, og for enhver, der elskede at skrive koden, kommer det ikke let.

I sin 2025 Octoverse-rapport beskriver GitHub præcis denne ændring: udviklerne, der er gået længst med AI, kalder sig ikke længere “forfattere af kode” og bliver noget, der ligner dens “kreative direktører”, hvor den vigtigste færdighed er at styre og verificere. Men vejen til denne rolle går gennem fejl og frustration, indtil en person ser gevinsten i sit eget arbejde.

Hvad Gør AI Til Et Fungerende Værktøj

Da vores hold først begyndte at bruge AI, arbejdede nogle udviklere med Claude Code, andre prøvede OpenAI Codex, GitHub Copilot eller Gemini CLI, og hvert værktøj gav et forskelligt resultat. Så da vi satte os for at bringe orden i, hvordan holdet arbejdede med AI, var det første, vi gjorde, at vi valgte et enkelt værktøj.

Dette er ikke kun vores praksis. Tag historien om holdet på Linear: indtil begyndelsen af 2026 fulgte de en “lad alle arbejde, som det passer dem”-princippet, og i januar droppede ledelsen denne tilgang og flyttede alle til en enkelt måde at arbejde på — at begrænse valget til to AI-værktøjer og bede udviklerne om at skrive kode kun med dem, og ikke for hånd. Ifølge virksomheden steg den gennemsnitlige produktivitet allerede næste måned med 30% i merged PRs og med 33% i opgaver lukket per ingeniør.

Det sagde, skal en fælles værktøj på sigt ikke forbedre koden — det skal konfigureres: opsætte regler, noget i retning af en rules.md, der beskriver, hvordan man skriver kode — hvilke tilgange at følge, hvad man skal undgå. Så kommer brugerdefinerede færdigheder til de opgaver, der er typiske for dit projekt, så du ikke behøver at forklare det samme igen og igen. Og til sidst er det værd at pege agenten mod din eksisterende kodebase: den analyserer, hvordan projektet er skrevet, og producerer ny kode i samme stil som den generiske.

Men det sværeste er ikke teknisk. Overgangen fra forfatter af koden til dens evaluator sker ikke af sig selv — den overgang behøver hjælp. Den mest direkte vej er træning og certificering. I vores tilfælde er ti udviklere i gang med et partnerprogram med værktøjsudbyderen, mens en person, der er ansvarlig for tilpasning, arbejder sammen med dem og forklarer, hvorfor værktøjet producerede et bestemt resultat, og hvordan man kan rette det.

Når holdet arbejder på en koordineret måde, er der én flaskehals tilbage — gennemgang — og det er værd at forstærke med AI. Agenten gennemgår hver enkelt pull-anmodning først og tager sig af det åbenlyse: rutinemæssige fejl, stil, gentagelse, sikkerhedslukninger. Den menneskelige gennemgående ser derefter ikke på alt uden diskrimination, kun på arkitekturen og de kritiske beslutninger. Effekten er synlig, selv inden for virksomheder, der bygger disse værktøjer: hos Anthropic steg andelen af pull-anmodninger, der fik en substantiel gennemgang, fra 16% til 54%, og ingeniørerne var uenige med mindre end 1% af dens kommentarer.

Til os forkortede dette en gennemgangscyklus, der tidligere strakte sig over to eller tre dage og adskillige runder, og det løftede den rutine af vores senior-ingeniører, så de kun havde de virkelig svære punkter tilbage. Når værktøjet endelig begyndte at producere resultater, der ikke behøvede at blive omskrevet, opstod tilliden til det også.

Hvor Tillid Til AI-Værktøjer Betaler Sig

Først og fremmest — i skrivning af kode: når værktøjet kender projektet, og agenten håndterer den første gennemgang, skriver holdet mere og bedre i samme mængde tid. I vores tilfælde accelererede AI-værktøjerne arbejdet med omkring 30-40%.

Ud over det har AI gjort det lettere at få nye medarbejdere på omgang. Når en ny person kommer ind i et projekt, skal en erfaren person normalt besvare adskillige spørgsmål om, hvordan projektets kode er sat sammen. Nu tager agenten på sig den rolle: hvis projektet er godt dokumenteret, retter newcomeren op til 95% af disse spørgsmål til det og ikke til kollegerne.

Det er en lignende historie med dokumentation: en udkast til en arkitektur, der tidligere slugte timer, skrives nu for størstedelens vedkommende af agenten selv — ifølge vores skøn omkring 80% af udkastet, hvis man giver det nok kontekst. Hvad der er tilbage for mennesket, er det, der ikke er i repository — beslutningerne, kompromiserne, ekspertisen.

Lige så vigtigt er det at være ærlig omkring grænserne for, hvad AI kan gøre, fordi det er overvurderede forventninger, der fører til skuffelse fra starten. AI tager ikke på sig overholdelse — en menneskelig underskriver på medicinske eller finansielle data, og virksomheden, ikke modellen, bærer ansvaret for en lækkage. Det accelererer ikke integrationer med <a href="https://ith partners, hvor adskillige timer går med i opkald og koordination. Out-of-the-box AI er virkelig irriterende — men kun, når det bruges som en færdig løsning. Den hele forskel mellem frustration og gevinst ligger i, hvad man bygger omkring det: en fælles standard, projektets kontekst og udviklerens nye rol.