Hvorfor ut-av-boksen AI-frustrerer utviklere — og hva du kan gjøre med det

Med de fleste teknologier er det slik at jo lenger du bruker dem, jo mer rolig kommer du til å stole på dem. Med AI-verktøy er det motsatt: i sin årlige undersøkelse av mer enn 49 000 utviklere, registrerte Stack Overflow en økning i bruk til 84 % samtidig som tilliten til nøyaktigheten av disse verktøyene sank fra 40 % til 29 % på løpet av ett år.

Dette er en effekt som er kjent for meg. Vår egen første erfaring med AI-verktøy i utvikling hadde lite til felles med den positive effekten av raskere arbeid og mindre slit som teknikkpressen skrev om. Våre utviklere ble skuffet: AI-produserte middelmådig kode som tok lang tid å gjennomgå og til slutt måtte skrives om. Teamet forventet at AI skulle spare tid, men fikk i stedet ekstra arbeid. Så ikke lenge etter de første forsøkene på å integrere AI-verktøy i den daglige arbeidsflyten, gikk teamet tilbake til å arbeide på samme måte som de alltid hadde.

I dag akselerer de samme verktøyene både skriving av kode og gjennomgang av den for våre utviklere — ikke fordi vi fant en bedre modell, men fordi vi endret måten vi arbeider med den på. Her er hva som hjalp oss å komme dit.

Hvorfor AI-skriven kode frustrerer utviklere

AI bygger på en enorm mengde offentlig kode fra hele internettet, og denne koden er sjelden eksemplarisk: dens kvalitet er gjennomsnittlig, og modellen reproducerer dette gjennomsnittet.

Men “gjennomsnitt” er ikke taket for hva som er mulig — det er bare hva modellen produserer til den kjenner prosjektet ditt: konvensjonene, kodestrukturen, arkitekturbeslutningene. I en undersøkelse av over 600 utviklere, fant Qodo ut at blant de som var misfornøyde med kvaliteten på AI-koden, tilskrev 44 % det spesifikt til mangelen på kontekst. Det er det som holder utgangen fast på et middelmådig nivå.

Det gode nyheten er at konteksten AI mottar, er omtrent den eneste variabelen et team har fullstendig kontroll over. Hvordan godt verktøyet forstår prosjektet, avhenger ikke av modellen, men av hva du mater den med.

Den andre grunnen er mental — selve arbeidets natur endrer seg. Når AI skriver mesteparten av koden, er utviklerens hovedhandling ikke lenger å skrive, men å sjekke hva som er generert: lese noen andres løsning, vurdere alternativene, bestemme hva som er klart til å bli levert. Dette er en annen ferdighet enn å skrive kode selv, og for noen som elsker å skrive, kommer det ikke lett.

I sin 2025 Octoverse-rapport, beskriver GitHub nøyaktig denne skiftningen: utviklerne som har kommet lengst med AI, kaller seg ikke lenger “forfattere av kode” og blir mer til “kreative direktører”, hvor den viktigste ferdigheten er å styre og verifisere. Men veien til denne rollen går gjennom feil og frustrasjon, til en person ser gevinsten i sitt eget arbeid.

Hva gjør AI til et fungerende verktøy

Da vårt team først begynte å bruke AI, arbeidet noen utviklere med Claude Code, andre prøvde OpenAI Codex, GitHub Copilot eller Gemini CLI, og hvert verktøy ga et annet resultat. Så da vi satte oss fore å bringe orden i måten teamet arbeidet med AI, var det første vi gjorde å velge ett enkelt verktøy.

Dette er ikke bare vår praksis. Se historien om teamet i Linear: til tidlig i 2026 fulgte de en “la hver arbeide på sin måte”-prinsipp, og i januar sluttet ledelsen å følge denne tilnærmingen og flyttet alle utviklere til en felles måte å arbeide på — å snevre valget til to AI-verktøy og be utviklerne om å skrive kode bare med dem, i stedet for for hånd. Ifølge selskapet, økte gjennomsnittlig produktivitet allerede neste måned med 30 % i slått sammen PR-er og med 33 % i oppgaver lukket per ingeniør.

Det er sagt, et felles verktøy alene forbedrer ikke koden — det må konfigureres: sette opp regler, noe som ligner en regel.md, som forklarer hvordan man skriver kode — hvilke tilnærminger å følge, hva å unngå. Deretter kommer tilpassede ferdigheter for oppgavene som er typiske for prosjektet ditt, så du ikke må forklare det samme flere ganger. Og til slutt er det verdt å peke agenten mot din eksisterende kodebase: den analyserer hvordan prosjektet er skrevet og produserer ny kode i samme stil, i stedet for en generisk en. Jo mer kontekst verktøyet mottar, jo mindre må du skrive om for hånd etterpå.

Men det hardeste er ikke teknisk. Skiftet fra forfatter av koden til dens evaluator skjer ikke av seg selv — den overgangen trenger hjelp. Den mest direkte ruten er opplæring og sertifisering. I vårt tilfelle, for eksempel, går ti utviklere gjennom et partnerprogram med verktøyleverandøren, mens en person ansvarlig for tilpasning arbeider sammen med dem, og forklarer hvorfor verktøyet produserte et bestemt resultat og hvordan man kan fikse det.

En gang teamet arbeider på en koordinert måte, er det en flaskenhalshals som gjenstår — gjennomgang — og det er verdt å forsterke med AI. Agenten går gjennom hver pull-forespørsel først og tar på seg det åpenbare: rutinemessige feil, stil, gjentakelser, sikkerhetshull. Den menneskelige gjennomgåeren ser ikke lenger på alt udiscriminerende, bare på arkitekturen og de kritiske beslutningene. Effekten er merkbar, selv innen selskapene som bygger disse verktøyene: i Anthropic, etter å ha introdusert en slik agent, økte andelen pull-forespørsler som mottok substantiell gjennomgang fra 16 % til 54 %, og ingeniørene var uenige med mindre enn 1 % av dens kommentarer.

For oss forkortet dette en gjennomgangssyklus som tidligere strakk seg over to eller tre dager over flere runder, og det løftet den rutinemessige arbeidet av våre senior ingeniører, og lot dem fokusere på de virkelig vanskelige punktene. En gang verktøyet til slutt begynte å produsere resultater som ikke trengte å bli omskrevet, dukket tillit til det opp.

Hvor tillit til AI-verktøy betaler seg

Først og fremst — i skriving av kode: når verktøyet kjenner prosjektet og agenten håndterer den første gjennomgangen, skriver teamet mer og bedre i samme tidsrom. I vårt tilfelle akselererte AI-verktøyene arbeidet med omtrent 30–40 %.

Ut over det har AI gjort det enklere å komme i gang. Når en ny person slutter seg til et prosjekt, må noen erfaren vanligvis besvare mange spørsmål om hvordan prosjektets kode er satt sammen. Nå tar agenten på seg den rollen: hvis prosjektet er godt dokumentert, retter nykommeren opp til 95 % av disse spørsmålene til den, i stedet for til kolleger.

Det er en lignende historie med dokumentasjon: en grov arkitektonisk utkast som en gang tok timer å skrive, er nå, for det meste, skrevet av agenten selv — ifølge våre estimater, omtrent 80 % av utkastet, hvis du gir den nok kontekst. Hva som er igjen for mennesket, er det som ikke er i repositoriet — beslutningene, kompromissene, ekspertisen.

Like viktig er å være ærlig om grensene for hva AI kan gjøre, fordi det er overvurderte forventninger som fører til skuffelse fra begynnelsen av. AI tar ikke på seg samsvar — en menneske godkjenner medisinske eller finansielle data, og selskapet, ikke modellen, bærer ansvaret for en lekkasje. Det akselerer ikke integrasjoner med partnere, hvor dusinvis av timer går med i samtaler og koordinering.

Ut-av-boksen AI er virkelig irritasjon — men bare når det brukes som en ferdig løsning. Hele forskjellen mellom frustrasjon og gevinst ligger i hva du bygger rundt det: en felles standard, prosjektets kontekst og utviklerens nye rolle.