Derfor er ikke all kode skapt like

For noen dager siden viste en gründer meg en fungerende webapplikasjon hun hadde bygget i løpet av en helg med AI-verktøy. Ingen informatikkutdannelse, ingen kode-bootcamp – bare en god idé og et presist prompt. Ærlig talt: imponerende. Login-system, et dashboard, datalagring som faktisk fungerte. Alt på under 72 timer.

Så ba hun meg om hjelp til å shippe det til ekte brukere.

Det var der ting ble interessant.

Prototypen fungerte – for én bruker

Protypen var fantastisk fordi hun var den eneste brukeren. Den minste vi prøvde å legge til en person nummer to, dukket det opp concurrency-bugs. Databasen hadde ingen schema migrations, så en rollback ville betydd datatap. Det var ingen tester, noe som gjorde enhver refactoring til å ligne på å defusere en bomb blindfoldet. Og deploy-prosessen var manuell med null dokumentasjon.

Helgeprosjektet hennes var et glimrende proof of concept. Det var ikke produksjonsklar programvare.

Dette er gapet som "vibe coding"-diskusjonen stadig bommer på. Verktøyene er virkelige. Farten er virkelig. Demokratiseringen av programvareutvikling er genuint spennende. Men det er en forskjell mellom å generere kode og å engineeringe programvare. Og den forskjellen betyr mer enn de fleste skjønner – helt til de sitter med en 3 AM-incident.

Metrikken som faktisk teller

Her er spørsmålet jeg stadig stiller når jeg ser AI-generert kode: kan dette trygt merges inn i en delt kodebase?

Ikke "kjører det". Ikke "funket demonstrasjonen". Trygt å merge. Ordet "trygt" bærer mye vekt. Det betyr at koden kan reviewes av noen som ikke skrev den. Det betyr at testene verifiserer adferd, ikke bare at koden ikke kræsjer. Det betyr at rollback er mulig uten datatap. Det betyr at endringen er smal nok til å forstå og forklare.

Når en vibe coder måler suksess, måler de gjerne tid til første fungerende versjon. Det er en nyttig metrikk for discovery og prototyping. Men når programvaren kommer inn i et delt miljø, slutter den metrikken å være nyttig. Nå måler du tid til trygg merge, og det inkluderer review-kostnad, testkvalitet, deploy-risiko, koordinasjons-overhead, og fremtidlig vedlikeholdsbyrde.

En software engineer tenker på hele denne livssyklusen fra starten av. En vibe coder oppdager ofte disse bekymringene senere – når de koster mer å adressere.

Kodegenerering kontra kodeeierskap

Det skjer en subtil, men kritisk forskyvning når AI genererer koden din. Outputen er ennå ikke ditt arbeid. Det er et utgangspunkt som må transformeres til noe du faktisk eier.

Eierskap betyr flere ting. Du kan forklare enhver meningsfull beslutning i endringen. Du forstår hvorfor hver fil eksisterer og hva den gjør. Du har begrenset endringen til akkurat det som trengs, uten ekstra boilerplate eller urelatert opprydding. Du har skrevet eller verifisert tester som sjekker adferd, ikke bare dekningsgrad. Du har vurdert rollback-stien.

Dette er arbeidet AI ikke kan gjøre for deg. AI genererer. Du bestemmer. Og "bestemme" innebærer at du har tenkt på alternativer, veid avveininger, og forstått konsekvensene.

Når jeg ser AI-generert kode som ikke er skikkelig eid, ser jeg ofte de samme problemene. Endringer som er for store fordi modellen genererte mer enn nødvendig. Pakker lagt til uten klar begrunnelse. Tester som ser ut til å være skrevet for å tilfredsstille et dekningsverktøy heller enn å fange reelle bugs. Boilerplate som eksisterer fordi modellen defaulter til scaffolding heller enn enkelhet.

Ingen av disse er AIs feil. De er resultatet av en forfatter som behandlet generert output som fremgang heller enn råmateriale.

Review-problemet ingen snakker om

Her er noe som holder meg våken om natten: AI-generert kode endrer review-likningen.

Når en human engineer skriver kode, er det vanligvis en beslutningssti. Du er kanskje uenig i valgene deres, men i det minste finnes det valg. Du kan spørre hvorfor de brukte den abstraksjonen, hvorfor valideringen lever der, hvorfor de valgte det biblioteket. Svarene kan være "jeg tenkte ikke over det" eller "virket fornuftig den gangen," men i det minste er det en person å spørre.

Med AI-generert kode er noen av disse "beslutningene" ikke beslutninger i det hele tatt. De er completions. Modellen valgte et mønster fordi det var statistisk sannsynlig, ikke fordi det var riktig fit for ditt problem. Og hvis forfatteren ikke har konvertert den completionen til eid arbeid, blir reviewen et mye hardere problem.

Du kan ikke spørre modellen hvorfor den valgte den tilnærmingen. Du kan ikke spørre forfatteren hvorfor de gjorde den beslutningen hvis de egentlig ikke vet. Så reviewen enten avdekker problemer gjennom smertefull trial and error, eller den skjer ikke i det hele tatt.

Dette er hvorfor jeg tror den viktigste ferdigheten i AI-assistert utviklingsæraen ikke er prompting. Det er evnen til å ta generert output og gjøre den om til kode du forstår dypt nok til å eie, forklare, og vedlikeholde.

Hva dette betyr for teamet ditt

Hvis du bygger en prototype for å teste en idé, er vibe coding en legitim tilnærming. Fart på læring betyr noe når du fremdeles validerer antakelser. Bruk verktøyene, beveg deg raskt, og bygg noe å vise folk.

Men hvis den prototypen skal bli et reelt produkt, på et tidspunkt må den genererte koden passere gjennom et filter til noen som tenker som en engineer. Ikke for å være gatekeeper. Ikke for å bremse ting. Men for å sikre at det som shippes er kode som kan forstås, vedlikeholdes, og stoles på av et team.

På NameOcean ser vi dette mønsteret hele tiden. Startups som beveger seg raskt med AI-verktøy for å validere idéene sine, deretter treffer en mur når de trenger å skalere. De gode bringer inn engineering-hjelp på det tidspunktet. De dårlige blir bare ved å stable features på en kodebase som ingen egentlig forstår.

Målet er ikke å unngå AI-assistert utvikling. Målet er å være ærlig om hvor arbeidet starter og hvor det slutter. AI kan generere kode. Du må engineeringe programvare.

Konklusjonen

Vibe coding er et fantastisk utgangspunkt. Det er en måte å teste idéer raskt, lære hva som er mulig, og bevege seg fra konsept til noe konkret uten måneder med tradisjonell utvikling.

Men software engineering handler om hele livssyklusen. Det handler om kode som teamet ditt kan reviewe, vedlikeholde, og stole på når ting går galt klokken 2 AM. Det handler om endringer som er smale nok til å forstå og rollback hvis nødvendig. Det handler om å ta ansvar for beslutninger, selv når de beslutningene ble informert av AI-forslag.

De beste utviklerne jeg kjenner bruker AI-verktøy mye. De gjør det bare med åpne øyne. De vet at generert kode er råmateriale, ikke ferdig produkt. Og de vet at på et tidspunkt må noen gjøre engineering-arbeidet som utgjør forskjellen mellom en kul demo og programvare du faktisk kan shippe.

Så ja, vibe code bort. Bygg raskt, eksperimenter fritt, og bruk alle verktøy tilgjengelig. Bare vis når det er tid for å skifte fra vibe til engineering. Fremtidige versjoner av deg selv – og fremtidige teamet ditt – kommer til å være takknemlige.