Vibecoding är inte AI-assisterad utveckling

Jag har programmerat i fyrtio år. Jag skriver inte längre kod själv.

Den meningen får folk att anta att jag har slutat med hantverket. Det har jag inte. Vad jag fortfarande har kvar är den del som tog fyrtio år att bygga upp: en djup förståelse för hur datorer faktiskt fungerar, programmering, säkerhet, operativsystem, nätverk och hårdvara. Koden var aldrig poängen. Koden var mediet. I dag är mitt medium en prompt, och den underliggande förståelsen har inte förändrats alls.

Det är därför den rådande trenden att stämpla varje utvecklare som använder AI som en vibecoder är värd att bemöta. Det reducerar två helt olika aktiviteter till ett enda ord.

Tre epoker av samma yrke

I den första epoken skrev man allt. Varje fil, varje funktion, varje konstruktor och varje variabel. Man knappade in precis allt. Att skriva tog tid och felsökning tog ännu längre tid, man läste koden rad för rad tills man hittade felet, eller lade in print-satser tills maskinen talade om var det gjorde ont.

Sedan kom moderna utvecklingsmiljöer (IDE) och allt gick betydligt snabbare: auto-komplettering, refaktorisering, hoppa till definition, riktiga debuggers med brytpunkter och minnesinsyn. Men lägg märke till vad som faktiskt ändrades. Du skrev fortfarande merparten av koden själv. Din IDE tog bort friktionen från själva skrivandet och gjorde det hanterbart att hitta buggar. Den tog inte bort kravet på att du faktiskt visste vad du byggde.

Nu har vi Claude Code, Cursor och resten. Vem som helst kan bygga en app. Du beskriver något och fungerande programvara dyker upp. Det ser bra ut, genuint bra, ofta bättre än vad de flesta av oss producerade för hand på ett första utkast. Alla känner sig som utvecklare.

Varje epok har skalat bort ett lager av manuellt rutinarbete. Inte en enda av dem har tagit bort behovet av förståelse. Det är den delen som misstolkas just nu.

Vad vibecoding faktiskt levererar

Programmen är usla.

Inte usla på skärmen. De ser fantastiska ut i en demo. Men de är usla under huven: ingen datamodell värd namnet, autentisering påklistrad i efterhand, API-nycklar och hemligheter synliga i klientkoden, obefintlig felhantering i kritiska anrop, applikationstillstånd utspritt över fem olika komponenter som alla tror att de äger datan, och ett beroendeträd som ingen någonsin har granskat. Det fungerar fram tills det möter en riktig användare, riktig belastning eller en verklig angripare.

Det här är ingen kritik mot verktygen. Verktygen gjorde exakt vad de blev ombedda att göra. Det är just det som är problemet, instruktionerna var för dåliga.

Skillnaden ligger i specifikationen

Här går den verkliga skiljelinjen, och den har ingenting att göra med om du knappar in koden själv eller inte.

En vibecoder säger: "lägg till en knapp."

En utvecklare specificerar: vilken vy, var i layouten, vad den läser ifrån, vad den skriver till, vad som visas under laddning, vad som händer när anropet misslyckas, vem som har behörighet att klicka på den, vad som sker om någon dubbelklickar, och hur det ser ut när listan bakom är tom.

Samma verktyg. Samma modell. Två helt olika resultat, eftersom i det första fallet måste AI:n gissa, och en gissande språkmodell returnerar det statistiska genomsnittet av allt den någonsin har sett.

Generisk kod. Och generisk kod är precis den kod som inte passar in i ert system, bryter mot era invariansregler och i det tysta blir incidenten ni tvingas felsöka om tre veckor.

Vad de gamla vanorna egentligen tränade upp

Utvecklaren som tillbringade åratal i vim eller emacs med att skriva varje rad för hand är inte värdefull på grund av skrivhastigheten. Den personen är värdefull för att den vet vad som måste specificeras. Den vet att hanteringen av felscenarier är själva designen. Den vet vad maskinen gör under ytan: att ett anrop korsar ett nätverk, att nätverk är opålitliga, att minne är ändligt, att en process kan dö mitt i en skrivning och att allt som når klienten är offentligt.

Du kan inte prompta dig till den förståelsen. Du kan bara prompta utifrån den.

Varför begreppet är bakvänt

Att kalla varje AI-användande utvecklare för vibecoder är inte bara oprecist, det är helt bakvänt. De ingenjörer som får ut mest av dessa verktyg är nästan alltid de med djupast erfarenhet från tiden före AI. De styr istället för att fråga. De läser vad som kommer tillbaka. De känner igen svaret som låter rimligt men är felaktigt, vilket är den enskilt viktigaste förmågan i denna tid, eftersom en språkmodells självsäkerhet inte har något samband med dess korrekthet.

Den som enbart vibecodar kan inte granska resultatet, eftersom granskningen kräver den kunskap som kodgenereringen var tänkt att ersätta. De driftsätter det som kompilerar och ser snyggt ut. Det handlar inte om lathet, utan om en saknad återkopplingsloop. Inget talar om att koden är trasig förrän den möter verklig produktion.

Rättvisa åt vibecoding

Det har en legitim plats: prototyper, interna hjälpmedel, engångsskript, att testa en idé innan man lägger budget på den, och att låta personer som inte är programmerare bygga det lilla verktyg de behöver istället för att vänta sex månader i en utvecklingskö. Det har ett verkligt värde och jag har inget intresse av att vara grindvakt.

Problemet är ett kategorimisstag: att ta något som byggts helt utan specifikation och granskning, och sätta det framför kunder på det öppna internet med ansvar för andra människors data.

Hur AI-assisterad utveckling faktiskt ser ut

• Arkitekturen fastslås från start. Systemets grundstruktur bestäms innan någon kod skrivs, av någon som har byggt liknande system tidigare.
• Tydliga restriktioner. Detta språk, denna ramverksversion, detta mönster, dessa systemgränser. Varje restriktion du lämnar osagd är ett slantslantsbeslut du har delegerat till slumpen.
• Små steg där varje ändring granskas. Läs diffen, inte bara slutresultatet på skärmen. Resultatet ser alltid snyggt ut.
• Avvisa kod som fungerar men är fel för systemet. Detta är det svåraste, eftersom fungerande kod är väldigt övertygande.
• Säkerhetsmodellen bestäms innan funktionen byggs, inte efter säkerhetsgranskningen.
• Ta ansvar för slutresultatet, för verktyget varken kan eller kommer att göra det.

Det är samma ingenjörsmässiga omdöme som det alltid har varit, tillämpat en nivå högre upp i abstraktionskedjan.

Frågan folk ständigt ställer

Branschen fortsätter fråga om AI kommer att ersätta utvecklare. Fel fråga. Den har redan ersatt själva knappandet, på samma sätt som utvecklingsmiljön ersatte att slå upp syntax i en tjock manual. Vad den inte har ersatt, och vad som i själva verket har blivit betydligt mer värdefullt, är att veta vad man bygger och varför.

Efter fyrtio år skriver jag inte längre kod själv.

Jag bygger fortfarande programvara.