Builderens playbook: Sådan gør du vibe code til software, der kan shippe

Der er en ny form for selvtillid i teams lige nu. Man kan beskrive et produkt i almindeligt sprog, få en demo til at køre på få timer og kalde det “done”. Det føles, som om shipping er løst.

Så kommer den første rigtige bruger. Auth lækker. Secrets ligger i et repo. Datamodellen kan ikke migreres. Logs er ubrugelige. Ingen kan forklare, hvor halvdelen af coden kommer fra. Demoen var hurtig, men leverancen er stadig langsom—bare på en mere kaotisk måde.

Fejlen er at tro, at problemet er “code generation”. Det er det ikke. Problemet er at omsætte genereret output til et produkt, der kan holde til mødet med kunder, auditorer og jeres egen on-call-rotation. Svaret er ikke flere prompts. Svaret er et software factory-mindset, hvor “factory” betyder gentagelige gates og tydeligt ansvar—ikke bureaukrati.

Derfor er idéen om, at software factories er på vej tilbage, interessant—særligt tanken om at kunne indsende en vibe-coded app til en service, der validerer, tester og masseproducerer den på en gentagelig måde, som beskrevet i Why software factories are back, and how they work in the age of AI. Uanset om du køber en platform eller bygger en intern version, er mønsteret det samme: Du stoler ikke på outputtet. Du stoler på processen.

1) Behandl vibe code som ubetroet input

Genereret code er ikke “dårlig”. Den er bare risiko uden prisskilt. Den lander uden det normale spor af designbeslutninger, tradeoffs og reviews, der gør et system vedligeholdbart.

Start derfor med en kontant policy:

• Alt, der kommer fra en AI, er ubetroet, indtil det har passeret gates. På samme måde som du håndterer inbound netværkstrafik, uploadede filer eller third-party packages.
• “Works on my machine” er ikke en tilstand. Den eneste tilstand, der betyder noget, er “passes the pipeline”.

Den framing gør to ting. For det første fjerner den skam fra samtalen—ingen behøver at forsvare coden. For det andet gør den næste skridt oplagt: Definér gates, og automatisér dem, til de bliver trivielle.

2) Byg gates, der kan håndhæves—ikke guidelines

De fleste teams har allerede “standarder”. Problemet er, at de er skrevet som et dokument og håndhævet som en opfordring. Vibe coding forstærker svagheden, fordi det fylder systemet med ændringer.

Det, du vil have, er et sæt gates, der håndhæves mekanisk. En ændring passerer—eller den gør ikke.

Minimumssættet af gates

• Tests: unit tests for logik, integration tests for grænseflader, og mindst én end-to-end test for den vigtigste user journey. Målet er ikke coverage som trofæ. Målet er hurtig detektion, når en refactor ændrer adfærd.
• Security: statisk analyse, dependency scanning og secrets detection. Kræv også en threat model for features, der rører identitet, betaling eller følsomme data. Hold det let, men gør det obligatorisk.
• Provenance: et build, der kan svare på: Hvilket commit skabte denne artifact, hvilke dependencies indgik, og hvem godkendte det. Hvis du ikke kan svare på de spørgsmål på få minutter, har du ikke en release process—du har et ritual.
• Observability: strukturerede logs, få centrale metrics og fornuftig error handling. Hvis du ikke kan se fejl, ender du med at debugge ved at gætte, og incident load vil stige.

Den vigtigste detalje: gates skal køre som default. En manuel checkbox skaber undtagelser, og undtagelser bliver det reelle system.

Jeg har skrevet mere om samme idé fra en anden vinkel i Default-On Agentic Coding Is a Release Pipeline Change, Not a Feature Toggle. Princippet er identisk: Du ændrer release-mekanismen—du tilføjer ikke et stykke legetøj.

3) Tegn ejerskabsgrænser, der kan holde til hastighed

AI øger throughput. Netop derfor bliver uklart ejerskab farligt. Når change volume stiger, bliver uklare grænser til “alle rørte det, ingen ejer det”.

En brugbar model er at skille det, der kan genereres fra det, der skal ejes.

Definér tre zoner

• Sandbox zone: prototyper, interne tools, throwaway spikes. Vibe coding er velkommen. Prisen for at tage fejl er lav. Adgang er begrænset. Data er syntetiske.
• Product zone: customer-facing code. Ændringer kræver hele gate-sættet. Det er her, du investerer i tests, migrationsdisciplin og observability.
• Control zone: identitet, billing, rettigheder, kernedata og alt, der kan skabe juridisk eller finansiel risiko. Denne code ændrer sig langsomt, med eksplicit review og rollback-planer.

Zonerne gør dig ikke langsommere. De forebygger en klassisk fejl, hvor den hurtigste vej bliver den eneste vej—og pludselig ligger prototype-genveje bag production auth.

Én intern regel hjælper: Kun en navngiven owner kan flytte code fra sandbox til product, og fra product til control. Ikke en komité. Et menneske, der er ansvarligt for konsekvenserne.

4) Gør “cost of change” synlig—og pris den ind i hver beslutning

Vibe coding føles som hastighed, fordi første version er billig. Fælden er, at anden og tredje version ofte bliver dyrere, fordi ingen investerede i det stillads, der gør ændringer sikre.

Du har brug for en cost-of-change-model, der er enkel nok til at bruge i ugentlige beslutninger.

En praktisk cost-of-change-model

• Build cost: tid til at implementere feature.
• Change cost: tid til at ændre den sikkert næste måned. Det domineres af testkvalitet, tydelige interfaces og data migration-design.
• Failure cost: tid brugt på debugging, incident response, kundesupport, omdømmeskade og rework under pres.

Den akkumulerende effekt kommer herfra: AI reducerer build cost, men kan øge change cost og failure cost, hvis du ikke investerer i gates og grænser. Hvis du kun fejrer build cost, optimerer du utilsigtet for skrøbelighed.

En enkel måde at håndhæve modellen på er at tilføje ét spørgsmål til håndtrykket mellem product og engineering: “Hvad er rollback- og testplanen?” Hvis svaret er uklart, kigger du ikke på en ændring, der kan shippes. Du kigger på en demo.

Det er også her, formalisering betaler sig. Ikke tunge specs, men nok præcision til at forhindre, at tvetydig adfærd bliver til tvetydighed i production. Jeg har beskrevet den tilgang i Formal Specs Are Incident Tools, Not Academic Proofs.

5) Gør factory’en til en service—og lad teams bevæge sig hurtigere

Det største leverage er at behandle release pipeline som et produkt. Det betyder, at den har brugere (jeres engineers), uptime-krav (build reliability) og en roadmap (hvilke gates der automatiseres næste gang).

Når du gør det rigtigt, opstår et nyt mønster:

• Teams genererer mere code.
• Pipelinen afviser dårlige ændringer tidligt.
• Fixes sker, mens konteksten stadig er frisk.
• Production bliver roligere, selv om throughput stiger.

I praksis ligner det en “factory”, der kan ingest’e et repo, køre validering, producere artifacts og skubbe deployable outputs—i tråd med idéen om en service, der kan validere og masseproducere vibe-coded apps gentageligt, som beskrevet i ZDNET-artiklen.

Én advarsel: Forveksl ikke automation med abdikation. Din pipeline kan køre checks, men den kan ikke beslutte, hvilken risiko der er acceptabel for din forretning. Det er stadig dit ansvar.

En erfaring fra virkeligheden: Hastighed uden gates er bare udskudt arbejde

Jeg har set et team genbygge den samme integration to gange i hurtig rækkefølge, fordi første version “virkede”, men ikke havde meningsfulde tests og ingen kontrakt ved grænsefladen. Hver ændring blev et regressionslotteri. Vi havde ikke et talentproblem. Vi havde et disciplinproblem. I det øjeblik vi indførte en reel gate for integration tests og bandt interface-ejerskab op på én person, stoppede churn.

Det er kernen: AI hjælper dig gerne med at producere første version af hvad som helst. Din fordel er at være den type builder, der kan producere den tiende version uden at drukne.

Afsluttende synspunkt: AI-hastighed er reel, men den akkumulerer kun bag constraints

De bedste teams vinder ikke ved at generere mere code. De vinder ved at gøre ændringer billige. Det kræver gates, der kan håndhæves, klare ejerskabsgrænser og en synlig cost-of-change-model, der viser den reelle pris på genveje.

Hvis du vil have ét konkret greb at starte med i dette kvartal: Vælg én produktoverflade, gør minimumssættet af gates ikke-forhandlingsbart, og gør pipelinen til den eneste vej til production. Du vil føle dig langsommere i en uge. Derefter opdager du, at du kan shippe hurtigere, fordi du ikke længere betaler renter på skrøbeligt arbejde.