Vibe coding innebär att du beskriver vad du vill ha i vanligt språk och tar emot det modellen producerar, utan att läsa det noga. För en prototyp, ett skript eller ett verktyg byggt på en kväll är det ett genuint bra sätt att arbeta. Jag använder det själv så.
Problemen börjar när det du vibe-kodat går i produktion och börjar förvara andra människors data. Inte för att koden är dålig — den är ofta prydlig, idiomatisk och välnamngiven. Problemet är det ingen skrev ner.
En modell svarar på frågan du ställde
Du ber om ett bokningsformulär och får ett bokningsformulär. Det validerar e-postadressen. Det blir förmodligen snyggare än det jag hade skrivit för hand.
Vad det inte gör är att ställa de frågor som avgör om saken överlever kontakt med riktiga användare. Vad händer om två personer bokar den sista tiden samma sekund? Om betalleverantören får timeout efter att ha dragit pengarna men innan din kod får veta det? Vem får se den här bokningen — kunden, vilken inloggad användare som helst, vem som helst med länken? När kunden ber dig radera sina uppgifter, vad mer måste raderas med dem, och vad måste enligt lag sparas?
Det är inte programmeringsfrågor. Det är beslut om din verksamhet, och modellen kan inte fatta dem eftersom den aldrig fått de fakta som skulle behövas. Den producerar något rimligt för var och en, tyst, och går vidare. Koden kompilerar. Formuläret fungerar när du testar det. Beslutet har ändå inte fattats av någon.
Demot fungerar alltid
Det är den specifika fällan, och den fångar även erfarna människor.
En vibe-kodad funktion testas som den byggdes: en person, en webbläsare, en lycklig väg, ingen belastning, ingen motståndare. Under de förhållandena går nästan vad som helst igenom. Felen bor exakt i de förhållanden du inte tänkte på att skapa — samtidighet, partiella avbrott, fientlig indata, den andra kunden, den tiotusende raden, användaren som inte längre är inloggad men vars token fortfarande fungerar.
Återkopplingsslingan ljuger alltså för dig. Du släpper, det fungerar, du släpper igen snabbare. Självförtroendet växer precis medan den ogranskade ytan växer. Inget säger emot förrän något gör det, offentligt.
Sex saker som konsekvent saknas
Auktorisering, till skillnad från autentisering. Modeller är bra på inloggning. De är betydligt svagare på "den här användaren får läsa just den här raden". Den överlägset vanligaste sårbarheten i vibe-kodad programvara är en slutpunkt som kontrollerar att du är inloggad och aldrig kontrollerar vem du är.
Allt som måste stämma under samtidighet. Lagersaldon, platsbokningar, fakturanummer, kontosaldon. Kod som uppenbart stämmer läst uppifrån och ner är ofta fel när två kopior kör samtidigt.
Felbeteendet hos varje externt anrop. Varje tredjepart du är beroende av kommer att vara otillgänglig någon gång. Om det ska stoppa din kund är ett verksamhetsbeslut. Genererad kod fattar det av misstag, oftast genom att krascha.
Data du inte har råd att förlora. Migreringar som tar bort kolumner, raderingar utan mjuk radering, ingen säkerhetskopia du faktiskt återställt från. Ingen märker något förrän den dag det spelar roll, och den dagen är det oåterkalleligt, inte obekvämt.
Administrationsgränssnittet. Vibe coding producerar de skärmar du beskrev. Du beskrev de kundvända, eftersom det är dem du föreställer dig. Sedan lever din personal åtta timmar om dagen i det som blev över.
Sammanhang mellan funktioner. Varje session börjar om från noll. Tio funktioner byggda i tio sessioner ger dig tio konventioner, tre sätt att hantera datum, två autentiseringsmönster och inget gemensamt ordförråd. Var för sig utmärkta. Som system omöjliga att underhålla — även för nästa modell du sätter på dem.
Vad det faktiskt kostar
Argumentet för vibe coding är hastighet, och hastigheten är verklig. Det som skjuts upp är kostnaden för förståelse, och den kostnaden försvinner inte — den betalas senare, av den som måste ändra systemet.
Att ändra programvara säkert kräver någon som kan förutse vad en ändring kommer att gå sönder. Den personen bygger sin modell av systemet genom att ha fattat besluten. Har ingen fattat besluten har ingen modellen, och varje efterföljande ändring är en gissning med en driftsättning fastklistrad.
Jag kallas in i sådana projekt regelbundet. Räddningen är nästan aldrig en omskrivning — koden går oftast att rädda. Det som tar tid är att rekonstruera avsikten: läsa varje väg för att lista ut vad systemet skulle göra, eftersom ingen kan berätta det för mig, inte ens den som släppte det.
Vad jag faktiskt tycker
AI är den största produktivitetsökning mitt yrke sett och jag skulle inte arbeta utan den. Det är ett utmärkt instrument i händerna på någon som kan läsa resultatet kritiskt och vet vilka frågor som inte ställdes.
Den ersätter inte den personen. Den gör den personen snabbare. Omdömet om vad ditt system aldrig får ha fel om är inte en programmeringsuppgift, och det är precis den del du faktiskt betalar för.
Använd den till prototyper, interna skript, engångssaker, första utkastet av vad som helst. Till systemet din verksamhet står på, ha någon som förstår det från början till slut — oavsett om de skrev det eller granskade det rad för rad.