Fra prototype til produktion: Derfor betyder "vibe coding" mere arbejde, ikke mindre

For nylig så jeg en startup-grundlægger præsentere hendes nye webapp. Hun havde bygget hele molevitten over en weekend med AI-værktøjer. Ingen datalogi-uddannelse, ingen bootcamp. Bare en god idé og nogle velovervejede prompts.

Login, et dashboard, datahåndtering. Alt sammen fungerede.

Da hun spurgte, om jeg kunne hjælpe hende med at frigive den til rigtige brugere, gik det op for mig, hvor skoen trykker.

Prototypen virkede, fordi hun var alene

Problemet var simpelt: prototypen var bygget til én bruger. Hendes egen.

Så snart vi forsøgte at tilføje en anden person, begyndte fejlene at dukke op. Databasen havde ingen migrationsstrategier, så en rollback ville betyde tab af data. Der var ingen tests, hvilket gjorde enhver ændring til en risikofyldt affære. Og deployment var en manuel proces uden dokumentation.

Hendes weekendprojekt var en fremragende proof of concept. Det var ikke produktionsklar software.

Og det er præcis det, som hele "vibe coding"-debatten overser.

Hastigheden er reel – men den måler det forkerte

Jeg stiller altid det samme spørgsmål, når jeg ser AI-genereret kode: Kan dette sikkert merges ind i vores codebase?

Ikke "kører det". Ikke "fungerede demoen". Kan det merges uden at skabe problemer senere?

Det ord "sikkert" betyder en hel del. Det betyder, at en kollega kan gennemgå koden og forstå den. Det betyder, at tests verificerer adfærd, ikke bare at koden ikke crasher. Det betyder, at rollback er mulig uden datatab. Det betyder, at ændringen er small enough to understand.

Når du måler succes under prototyping, måler du tid til første fungerende version. Det er en fin metric for discovery. Men så snart softwaren bevæger sig ud til flere brugere, skifter målingen. Nu handler det om tid til sikker merge. Og det inkluderer review-tid, testkvalitet, deploymentsrisiko og fremtidlig vedligeholdelsesbyrde.

En erfaren software engineer tænker på hele denne livscyklus fra start. En vibe coder opdager problemerne senere – når de er dyrere at løse.

Code generation er ikke det samme som code ownership

Her er skiftet, som mange overser. Når AI genererer din kode, er outputtet ikke dit arbejde endnu. Det er et udgangspunkt, der skal transformeres til noget, du reelt set ejer.

Ownership betyder flere ting:

• Du kan forklare enhver meningsfuld beslutning i ændringen
• Du ved, hvorfor hver fil eksisterer, og hvad den gør
• Du har holdt ændringen præcis, som den behøvede at være
• Du har skrevet tests, der fanger rigtige bugs, ikke bare dækker linjer
• Du har overvejet rollback-muligheder

Dette er arbejdet, som AI ikke kan gøre for dig. AI genererer. Du beslutter. Og "beslutte" betyder, at du har tænkt over alternativer, vejet tradeoffs, og forstået konsekvenserne.

Review-problemet, ingen taler om

Noget, der bekymrer mig mere og mere: AI-genereret kode ændrer review-ligningen fundamentalt.

Når en menneskelig udvikler skriver kode, findes der typisk en beslutningssti. Du kan være uenig i deres valg, men i det mindste findes der valg. Du kan spørge, hvorfor de brugte den abstraktion, hvorfor valideringen bor der, hvorfor de valgte det bibliotek.

Med AI-genereret kode er nogle af disse "beslutninger" ikke beslutninger overhovedet. De er completions. Modellen valgte et mønster, fordi det var statistisk sandsynligt – ikke fordi det var det rigtige fit til dit problem. Og hvis forfatteren ikke har konverteret den completion til ejet arbejde, bliver review en langt hårdere opgave.

Du kan ikke spørge modellen, hvorfor den valgte den tilgang. Du kan ikke spørge forfatteren, hvis de ikke reelt set ved det.

Derfor er den vigtigste skill i AI-assisted development-æraen ikke prompting. Det er evnen til at tage genereret output og gøre det til kode, du forstår dybt nok til at eje, forklare og vedligeholde.

Hvad dette betyder for din virksomhed

Hvis du bygger en prototype for at teste en idé, er vibe coding en legitim tilgang. Speed of learning matters, når du stadig validerer antagelser.

Men på et tidspunkt skal den genererede kode passes gennem filteret hos en, der tænker som en engineer. Ikke for at gatekeep. Ikke for at bremse. Men for at sikre, at det der sendes til produktion, er kode der kan forstås, vedligeholdes og stoles på af et team.

Vi ser dette mønster konstant hos NameOcean. Startups der bevæger sig hurtigt med AI-værktøjer for at validere idéer, og så rammer en mur, når de skal skalere. De gode bringer engineering-hjælp ind på det tidspunkt. De dårlige bliver ved med at stable features oven på en codebase, som ingen reelt forstår.

Målet er ikke at undgå AI-assisted development. Målet er at være ærlig om, hvor arbejdet starter, og hvor det slutter. AI kan generere kode. Du skal engineering software.

Kort sagt

Vibe coding er en fantastisk start. Det er en måde at teste idéer hurtigt, lære hvad der er muligt, og bevæge sig fra koncept til noget håndgribeligt uden måneders traditionel udvikling.

Men software engineering handler om hele livscyklussen. Det handler om kode, som dit team kan gennemgå, vedligeholde og stole på, når ting går galt kl. 2 om natten. Det handler om ændringer, der er small enough to understand og rollback hvis nødvendigt. Det handler om at tage ansvar for beslutninger – selv når de beslutninger blev informeret af AI-forslag.

De bedste udviklere, jeg kender, bruger AI-værktøjer massivt. De gør det bare med åbne øjne. De ved, at genereret kode er råmateriale, ikke færdigt produkt. Og de ved, at på et tidspunkt skal nogen lave det engineering-arbejde, der gør forskellen mellem en cool demo og software, du faktisk kan shippe.

Så ja, vibe code løs. Byg hurtigt, eksperimentér frit, og brug alle værktøjer du har. Bare vid, hvornår det er tid til at skifte fra vibe til engineering. Din fremtidige self – og dit fremtidige team – vil takke dig for det.