När "vibe coding" inte räcker längre

Förra veckan fick jag se en fascinerande grej. En kompis till en kompis hade byggt en fullt fungerande webbtjänst på tre dagar. Ingen datavetenskaplig examen, inget bootcamp, bara desperation och bra prompts.

Login, dashboard, databas – allt fungerade.

Sen ville de lansera den för riktiga användare.

Det var då saker gick sönder.

Vad som händer när fler använder din "prototyp"

Problemet var enkelt: hon var ensam användare. När vi la till en andra person började random buggar dyka upp. Databasen saknade migrationsstrategier – en rollback hade betytt databasdöd. Inga tester. Noll dokumentation. Deployment var ett manuellt skript som bara hon förstod.

Weekend-projektet var en kanonidé. Det var inte produktionsklar mjukvara.

Och det är precis den här diskrepansen som "vibe coding"-entusiasterna duckar för. Ja, verktygen är imponerande. Ja, hastigheten är verklig. Men det finns en enorm skillnad mellan att generera kod och att engineeringa software. En skillnad som inte spelar någon roll förrän du sitter med en incident klockan 03.

Frågan som faktiskt spelar roll

När jag ser AI-genererad kod ställer jag en enda fråga:

Kan den här koden mergeas in i en shared codebase utan att någon får panik?

Inte "fungerar den?". Inte "gick demon igenom?". Safe to merge.

Det ordet betyder allt. Koden går att granska av någon som inte skrev den. Testerna verifierar beteende, inte bara att applikationen inte krashar. Rollback är möjligt utan dataförlust. Ändringen är tillräckligt avgränsad för att förstå och förklara.

När vibe coders mäter framgång mäter de tid till första fungerande version. Det är ett vettigt mått för prototyping. Men så fort koden lever i en delad miljö slutar den metriken vara användbar. Nu handlar det om tid till safe merge – och det inkluderar review-kostnad, testkvalitet, deployment-risk, koordinations-overhead, och framtida underhålls-börda.

En mjukvaruingenjör tänker på den hela cykeln från start. En vibe coder upptäcker de här bekymren senare, när de kostar mer att lösa.

Generera vs. äga

Här sker en subtil men kritisk skiftning. När AI genererar din kod är outputen inte ditt arbete ännu. Det är ett utkast som behöver transformeras till något du faktiskt äger.

Att äga sin kod betyder:

• Du kan förklara varje meningsfullt beslut i ändringen
• Du förstår varför varje fil existerar och vad den gör
• Du har begränsat ändringen till exakt det som behövdes
• Du har skrivit (eller verifierat) tester som fångar riktiga buggar
• Du har funderat på rollback-vägen

Det här är arbetet som AI inte kan göra åt dig. AI genererar. Du bestämmer. Och "bestämmer" innebär att du har tänkt på alternativ, vägt tradeoffar, och förstått konsekvenserna.

När jag kollar på AI-genererad kod som inte är ordentligt ägd ser jag ofta samma grejer. Ändringar som är för stora för att modellen genererade mer än nödvändigt. Dependencies utan tydlig justification. Tester som ser ut att ha skrivits för att stilla en coverage-tool snarare än för att fånga riktiga buggar. Boilerplate som bara finns för att modellen defaultar till scaffolding istället för enkelhet.

Inget av det här är AI:ns fel. Det är resultatet av en författare som behandlade generated output som färdig produkt istället för råmaterial.

Recensionsproblemet ingen pratar om

Något som håller mig vaken: AI-genererad kod förändrar review-ekvationen.

När en mänsklig ingenjör skriver kod finns det vanligtvis en beslutstrajectory. Du kanske håller inte med om deras val, men det finns i alla fall val. Du kan fråga varför de använde den abstraktionen, varför valideringen lever där, varför de valde det biblioteket. Svaren kan vara "tänkte inte på det" eller "lät rimligt", men det finns i alla fall en person att fråga.

Med AI-genererad kod är vissa av de där "besluten" inga beslut alls. De är completions. Modellen valde ett mönster för att det var statistiskt sannolikt, inte för att det var rätt för ditt specifika problem. Och om författaren inte har konverterat den completionen till ägt arbete blir reviewen en mycket svårare uppgift.

Du kan inte fråga modellen varför den valde det tillvägagångssättet. Du kan inte fråga författaren varför de gjorde det valet om de egentligen inte vet. Så reviewen surfar antingen upp problem genom smärtsam trial and error, eller så händer den inte alls.

Det är därför jag tror att den viktigaste kompetensen i AI-assisterad utvecklingseran inte är prompting. Det är förmågan att ta generated output och förvandla den till kod som du förstår tillräckligt djupt för att äga, förklara och underhålla.

Vad det betyder för ditt team

Om du bygger en prototyp för att testa en idé är vibe coding en legitim approach. Hastighet på learning matters när du fortfarande validerar antaganden. Använd verktygen, move fast, bygg något att visa folk.

Men om den prototypen ska bli en riktig produkt behöver koden någon gång passera filtret hos någon som tänker som en ingenjör. Inte för att gatekeepa. Inte för att sakta ner. Utan för att säkerställa att det som faktiskt skeppas är kod som kan förstås, underhållas och litas på av ett team.

På NameOcean ser vi det här mönstret hela tiden. Startups som rör sig snabbt med AI-verktyg för att validera sina idéer, sen slår i en vägg när de behöver skala. De duktiga drar in engineering-hjälp i det läget. De mindre duktiga fortsätter stapla features på en codebase som ingen egentligen förstår.

Målet är inte att undvika AI-assisterad utveckling. Målet är att vara ärlig om var arbetet börjar och var det slutar. AI kan generera kod. Du måste engineeringa mjukvara.

Bottom line

Vibe coding är en fantastisk startpunkt. Det är ett sätt att testa idéer snabbt, lära sig vad som är möjligt, och gå från koncept till något konkret utan månader av traditionell utveckling.

Men software engineering handlar om hela livscykeln. Det handlar om kod som ditt team kan granska, underhålla och lita på när saker går fel klockan 02. Det handlar om ändringar som är tillräckligt smala för att förstå och rollbacka vid behov. Det handlar om att ta ansvar för beslut, även när de besluten var informerade av AI-förslag.

De bästa utvecklarna jag känner använder AI-verktyg flitigt. De gör det bara med öppna ögon. De vet att genererad kod är råmaterial, inte färdig produkt. Och de vet att någongon måste göra engineering-jobbet som gör skillnaden mellan en cool demo och mjukvara du faktiskt kan skeppa.

Så ja, vibe code på. Bygg snabbt, experimentera fritt, använd varje verktyg som finns. Men vet när det är dags att skifta från vibe till engineering. Din framtida själv, och ditt framtida team, kommer att tacka dig.