AI-kodingverktøy: Hva markedet ikke forteller deg

Seks måneder etter lansering ble et vibe-codet produkt solgt til Wix for 80 millioner dollar. Fristelsen er stor til å konkludere at AI-verktøy bare er en god deal. Sannheten er mer nyansert – og langt mer interessant: Verktøyene fungerer godt på én type oppgaver og dårlig på en annen. Teamene som forstår forskjellen er de som leverer raskere uten å bygge opp skjult teknisk gjeld.

Følelsen som lurer deg

En fersk METR-studie lot erfarne utviklere løse reelle problemer i sine egne store kodebaser. Forskerne målte faktisk tid med og uten AI-hjelp. Før arbeidet startet anslo deltakerne at AI-verktøy gjorde dem omtrent 24 prosent raskere. Etterpå mente de 20 prosent. Den faktiske målingen viste at de var 19 prosent tregere med AI-assistanse.

Det gapet mellom opplevd og virkelig hastighet er det viktigste funnet i AI-forskningen. AI-hjelp gjør selve skrivingen raskere og gjennomgangen tregere. Vi mennesker er usedvanlig dårlige på å merke gjennomgangskostnaden fordi den føles som vanlig arbeid. De 15 minuttene du sparte på strukturering ser ut som en seier. De 25 minuttene du brukte på å feilsøke resultatet som var "nesten rett" føles ikke som et tap – det føles som jobben din.

Der hastigheten faktisk er reel

Forskningen peker tydelig mot én kategori: ny kode på ukjent område. GitHubs kontrollerte studie viste at utviklere bygde en webserver fra bunnen av 55 prosent raskere med Copilot. Feltstudier hos flere selskaper fant 26 prosent flere fullførte oppgaver, med juniorutviklere som fikk 27-39 prosent mer output på kortvarige oppgaver. McKinseys laboratoriearbeid viser at dokumentasjon og grønnfelt-kode kommer frem på omtrent halvparten av tiden.

Det er MVP-profilen. Et blankt prosjekt, en stack du lærer, boilerplate som stort sett kopierer seg selv, eller en funksjon du kan definere i en kort prompt. På det arbeidet leverer verktøyene akkurat det markedsføringen sier. Trikset er å innse at det ikke er hele programvarutviklingen.

Der slowingen sniker seg inn

METRs slowdown skjedde akkurat der du ville forventet: Erfarne utviklere som vedlikeholdt kodebaser de selv hadde skrevet i år. Modellen produserte plausible svar på et system den ikke forstod, utvikleren brukte tid på å vurdere om det var korrekt, og den vurderingen kostet mer enn bare å skrive funksjonen selv.

På skala er det her team havner i trøbbel. En startup som lener seg hardt på AI-koding for å shippe MVP-en sin, finner product-market fit, begynner å vokse – og oppdager tre måneder senere at "koden som fungerer" inneholder radnivå-sikkerhetssjekker som er kommentert ut, et admin-panel tilgjengelig for enhver autentisert bruker, og API-nøkler som endte opp i klientkoden. AI-en skrev fort. AI-en introduserte også en sikkerhetsgjennomgang som ingen hadde planlagt.

Faros AI-forskning, som målte over 10.000 utviklere på ekte team, fant at AI-assistanse faktisk gjorde team tregere i 20-40 prosent av scenarioene – spesielt i kodebaser over 100.000 linjer der kontekstvinduet ikke kan holde hele bildet. Det er brownfield-problemet, og det er der de fleste etablerte team befinner seg mest av tiden.

Sikkerhetsregningen ingen snakker om

Hver uke kommer en ny historie: En startup sin AI-genererte kode eksponerte brukerdata, eller en AI-assistert deploy lot en databaseport stå åpen, eller prompt injection fant veien inn i et produksjonssystem. Dette er ikke eksotiske edge cases. Dette er forutsigbare resultater av å peke et verktøy optimalisert for plausibel kode mot sikkerhetskritiske oppgaver uten at en sikkerhetsekspert ser på resultatet.

Mønsteret er konsekvent. AI-kodingsverktøy er trent på offentlig tilgjengelig kode, som inneholder mye kode med kjente sårbarheter, feilkonfigurerte tillatelser og hardkodede hemmeligheter. Når du ber et slikt verktøy bygge et brukerautentiseringssystem eller en betalingsintegrasjon, får du ofte en plausibel versjon av hvordan det ser ut – som kanskje eller kanskje ikke er en sikker versjon.

For startups som beveger seg raskt, er dette den kritiske risikoen. Du bygger ikke bare en MVP; du bygger et omdømme og en compliance-overflate. Et datalekkasje i ditt første år er ikke et teknisk problem. Det er et problem som avslutter selskapet.

Den praktiske rammen

Forskningen peker mot en klar operasjonell modell:

Bruk AI aggressivt på grønnfelt-arbeid. Nye prosjekter, prototyper, strukturer, ukjente stacks og godt definerte features er der speed-upen er reel og stor. Dette er mesteparten av det som får en MVP live, og dette er der disse verktøyene tjener inn abonnementsprisen.

Bruk AI selektivt på brownfield-arbeid. I en kodebase du kan godt, eller på alt som berører autentisering, betalinger eller brukerdata, behandle AI-output som et første utkast som trenger en sikkerhetsgjennomgang. Tiden du budsjetterer for den gjennomgangen er den virkelige kostnaden av verktøyet på det arbeidet. Ikke la "føles raskere"-signalet overtale deg til å hoppe over det.

Ship smått, med tester. Ustabiliteten i AI-output viser seg mest i store, komplekse endringer. Små inkrementelle endringer med ekte testdekning fanger opp subtilfeilene som består gjennomgangen og forårsaker hendelser i produksjon. Dette er god praksis generelt, men det blir kritisk når AI er med i bildet.

Herdefør før brukerne rører det. Slå på radnivå-sikkerhetssjekker. Fjern hemmeligheter fra klientkode. Ikke pek en AI-agent mot en produksjonsdatabase. Dette er ikke eksotiske sikkerhetstiltak – dette er baseline for ethvert system som håndterer ekte brukerdata. AI-koding forandrer ikke den baseline; det gjør det bare lettere å gå glipp av den.

Konklusjonen

AI-kodingsverktøy er genuint nyttige. De introduserer også kostnader som er virkelige, forutsigbare og så godt som aldri nevnt i markedsføringsmateriellet. Teamene som leverer raskest er ikke de som bruker AI på alt – de er de som bruker det strategisk, der speed-upen er reel, mens de beskytter delene av systemet der korrekthet betyr mer enn hastighet.

Hvis du bygger en MVP på Vibe Hosting, bruk AI-verktøy til å bevege deg raskt på delene som kan endres. Bruk dem forsiktig på delene som må være rett. Og hvis du ikke er sikker på hvilke som er hvilke, er det sannsynligvis ditt neste spørsmål.