AI-kodning: Hvornår det virker — og hvornår det koster dig

Den historie har de fleste hørt nu: et produkt bygget med AI-værktøjer blev solgt til Wix for 80 millioner dollars seks måneder efter lancering. Det er nemt at konkludere, at AI-kodning bare er en god forretning. Virkeligheden er mere nuanceret — og langt mere interessant.

Værktøjerne er en klar gevinst på én type opgaver og en klar omkostning på en anden. De teams, der forstår den forskel, leverer hurtigere uden at akkumulere gæld, de først opdager seks måneder senere.

Perceptionen versus virkeligheden

En ny undersøgelse fra METR satte erfarne udviklere til at løse konkrete problemer i deres egne store kodebaser. Før de gik i gang, estimerede deltagerne, at AI-værktøjer gjorde dem omkring 24% hurtigere. Da arbejdet var færdigt, mente de stadig 20% hurtigere.

Den faktiske måling viste noget andet: de var 19% langsommere med AI-assistance.

Det gap mellem, hvad udviklerne tror, og hvad der faktisk sker, er den vigtigste indsigt i AI-kodningsforskning. AI gør selve skrivefasen hurtigere, men gør til gengæld gennemgangen langsommere. Og mennesker erremarkværdigt dårlige til at bemærke den omkostning — den føles bare som almindeligt arbejde.

De 15 minutter, du sparede på at sætte projektet op, registrerer du tydeligt som en gevinst. De 25 minutter, du brugte på at debugge det "næsten rigtige" output, registrerer du ikke som et tab. Det føles som din opgave.

Hvor gevinsten faktisk er reel

Forskningen peger samstemmende på én kategori: ny kode i ukendt territorium.

GitHubs kontrollerede studie viste, at udviklere byggede en webserver fra scratch 55% hurtigere med Copilot. Feltstudier på tværs af flere virksomheder fandt 26% flere gennemførte opgaver, og juniorudviklere leverede 27-39% mere output på kortere opgaver. McKinseys laboratoriearbejde viser, at dokumentation og greenfield-kode lander på roughly halv tid.

Det er MVP-profilen. Et tomt projekt, et framework du er ved at lære, boilerplate der stort set kopierer sig selv, eller en funktion du kan beskrive i en kort prompt. På det arbejde gør værktøjerne præcis, hvad marketingen lover.

Problemet er at genkende, at det ikke er hele softwarudvikling.

Hvor slowdowns sniger sig ind

METR's forsinkelse opstod præcis der, hvor man ville forvente det: hos erfarne udviklere, der vedligeholdt kodebaser, de selv havde skrevet i årevis. Modellen producerede plausibelt klingende kode til et system, den ikke forstod. Udvikleren brugte tid på at vurdere, om det var korrekt. Og den vurdering kostede mere, end det ville have gjort bare at skrive funktionen selv.

På skala er det her, teams kommer i problemer. En startup, der lænner sig hårdt på AI-kodning for at shippe sit MVP, rammer product-market fit, begynder at vokse — og opdager tre måneder senere, at det "fungerende kode" inkluderer row-level security checks der er kommenteret ud, et admin-panel der er tilgængeligt for enhver autentificeret bruger, og API-nøgler der endte i client-side bundtet.

AI'en skrev hurtigt. AI'en indførte også en sikkerhedsgennemgang, som ingen nogensinde planlagde.

Faros AI-forskningen, der målte over 10.000 udviklere på tværs af virkelige teams, fandt at AI-assistance faktisk gjorde teams langsommere i 20-40% af scenarierne — særligt i kodebaser over 100.000 linjer, hvor context-vinduet ikke kan rumme hele billedet. Det er brownfield-problemet, og det er der, de fleste etablerede teams befinder sig det meste af tiden.

Sikkerhedsregningen, ingen nævner

Hver uge bringer en ny historie: en startups AI-genererede kode eksponerede brugerdata, en AI-assisteret deployment efterlod en databaseport åben, eller prompt injection fandt vej ind i et produktionssystem.

Det er ikke eksotiske edge cases. Det er forudsigelige resultater af at rette et værktøj, der er optimeret til plausibel kode, mod sikkerhedskritisk arbejde — uden at en sikkerhedsekspert gennemgår resultatet.

Mønsteret er konsekvent. AI-kodningsværktøjer er trænet på offentligt tilgængelig kode, og den kode indeholder en masse kendte sårbarheder, fejlkonfigurerede tilladelser og hardcoded secrets. Når du beder sådan et værktøj om at bygge et brugerauthenticeringssystem eller en betalingsintegration, ender du ofte med en plausibel version af, hvordan det ser ud — hvilket ikke nødvendigvis er en sikker version.

For startups, der bevæger sig hurtigt, er det her den kritiske risiko. Du bygger ikke bare et MVP. Du bygger et omdømme og en compliance-overflade. Et databrud i dit første år er ikke et teknisk problem. Det er et problem, der kan afslutte hele virksomheden.

Den praktiske ramme

Forskningen peger på en klar operationel model:

Brug AI aggressivt til greenfield-arbejde. Nye projekter, prototyper, scaffolding, ukendte stacks og velspecificerede features er der, hvor speed-up'en er reel og stor. Det er det meste af, hvad der får et MVP live, og det er her, værktøjerne tjener deres abonnementspris.

Brug AI selektivt til brownfield-arbejde. I en kodebase, du kender godt, eller på noget der berører authentication, betalinger eller brugerdata: behandl AI-output som et første udkast, der skal gennemgås af en sikkerhedsekspert. Den tid, du budgetterer med den gennemgang, er den reelle omkostning ved værktøjet på det arbejde. Lad ikke "føles hurtigere"-signalet overtale dig til at springe over.

Ship småt, med tests. Ustabiliteten i AI-output viser sig mest i store, komplekse ændringer. Små, inkrementelle ændringer med ægte testdækning fanger de subtile fejl, der slipper gennem gennemgangen og forårsager incidents i produktion. Det er generelt god praksis, men det bliver kritisk, når AI er med i kæden.

Hærdning før brugere rører det. Slå row-level security checks til. Fjern secrets fra client-side kode. Ret ikke en AI-agent mod en produktionsdatabase. Det er ikke eksotiske sikkerhedsforanstaltninger — det er baseline for ethvert system, der håndterer rigtige brugerdata. AI-kodning ændrer ikke den baseline. Det gør det bare nemmere at overse.

Konklusionen

AI-kodningsværktøjer er genuint nyttige. De introducerer også omkostninger, der er reelle, forudsigelige og næsten aldrig nævnt i marketingmaterialet.

De teams, der leverer hurtigst, er ikke dem, der bruger AI til alt. Det er dem, der bruger det strategisk — der, hvor speed-up'en er reel, mens de beskytter de dele af systemet, hvor korrekthed betyder mere end hastighed.

Hvis du bygger et MVP på Vibe Hosting: brug AI-værktøjer til at bevæge dig hurtigt på de dele, der kan ændres. Brug dem forsigtigt på de dele, der skal være rigtige. Og hvis du ikke er sikker på, hvilke dele der er hvilke — det er sandsynligvis dit næste spørgsmål.