Vibekodning, efter smekmånaden
· 6 min read · Filippo Spinella · AI, Coding, Agents, Developer Tools
Vibe-kodning är ett av de uttryck som verkar födda till att bli hatade och sedan sakta blir användbara.
Först låter det som: Jag tror inte, jag frågar AI:n, jag accepterar det som kommer ut, fortsätt. Ett glatt sätt att producera teknisk skuld med musikalisk bakgrund.
Men det vore för lätt att avfärda det så. Sanningen är att vibe-kodning har snappat upp en verklig sak: programmering med en modell förändrar förhållandet mellan idé och prototyp.
Först fick man en tanke och sedan en lång klättring. Nu har man ofta en tanke och en halvtimme senare rör sig något på skärmen. Det är svårt att inte bli förförd av det.
Den intressanta frågan, 2026, är inte om vibekodning är sann. Det är det. Frågan är: vad händer efter smekmånaden?
Prototypen har blivit ekonomisk
Detta är den viktigaste delen.
AI-verktyg har sänkt den känslomässiga kostnaden för att komma igång. Förut, om du ville prova en idé, var du redan tvungen att lägga ner arbetet: välj stack, skapa projekt, kom ihåg boilerplate, skriv layout, koppla API:er, bråka med tråkiga detaljer.
Nu kan du säga: ge mig en första version.
Och en första version kommer.
Inte alltid vacker. Inte alltid korrekt. Ofta sköra. Men det kommer. Och när den kommer förändras konversationen. Du bråkar inte längre i ett vakuum. Du rör något.
Detta är mycket kraftfullt för designers, grundare, produktchefer, seniora utvecklare som är trötta på att skriva om ställningar, nyfikna människor som inte skulle ha öppnat en redaktör tidigare.
Vibe-kodning är hype eftersom det ger fler människor den fysiska känslan av programvaran som skapas.
Problemet är att programvaran lever vidare
Den del som memen säger minst är dagen efter.
Prototypen måste läsas. Rätta. Testad. Utplacerad. Säkrad. Fick det av någon annan. Ansluten till riktig data. Tillgänglig. Bibehålls när ett beroende förändras.
Här slår ren vibekodning väggen.
En modell kan generera mycket kod snabbt, men kod är inget värde i sig. Det är ett löfte om beteende. Och ett löfte måste verifieras.
Risken med vibe-kodning är inte att skriva ful kod. Vi har alltid gjort det även utan AI. Risken är att förlora känslan av ägande: "modellen gjorde det" blir en ursäkt för att inte förstå tillräckligt.
Men körtiden accepterar inte ursäkter. Om koden körs i produktion är den din.
Från vibekodning till agentteknik
Den mogna versionen av vibe-kodning är att inte sluta använda agenter. Det är att använda dem med en mer seriös cykel.
Inte: det genererar allt och vi hoppas.
Men:
- beskriv avsikten;
- låt generera ett utkast;
- be ombudet att förklara planen;
- gör små skillnader;
- lanseringstester;
- göra recensioner;
- korrekt;
- först då gå med.
Den här saken förtjänar ett annat namn. Jag gillar agentteknik, även om det låter lite högtidligt. Det innebär att man använder agenter inte som spelautomater, utan som kollaboratörer inom en ingenjörsprocess.
Poängen är att inte ta energi från vibekodning. Det ger henne spår.
Där det fungerar utmärkt
Vibe-kodning fungerar när felkostnaden är låg och värdet av utforskning är högt.
Exempel:
- gränssnittsprototyper;
- personliga verktyg;
- interna instrumentpaneler;
- små spel;
- engångsmanus;
- API-skanningar;
- proof of concept;
- mekaniska refaktorer med bra tester;
- tekniskt innehåll som ska omvandlas till demos.
I dessa fall är hastigheten poängen. Du vill se om idén har ben. Du vill ta reda på det du inte förstod. Du vill komma till ett konkret samtal.
Vibe-kodning är perfekt för att få formen att växa fram.
Där det blir farligt
Det blir farligt när systemet får konsekvenser och ingen saktar ner.
Betalningar, personuppgifter, autentisering, behörigheter, infrastruktur, databasmigreringar, känslig äldre kod, efterlevnad, produktion. Här räcker inte stämningen till. Vi behöver rigor.
Det betyder inte att AI inte kan hjälpa. Faktum är att det kan hjälpa mycket. Men det måste fungera inom snäva ramar: gren, sandlåda, test, lint, recension, funktionsflagga, rollback.
Frasen som ska tatueras på monitorn är enkel: ju snabbare agenten är, desto mer läsbar måste processen vara.
Om du inte kan förklara vad som har förändrats har du inte accelererat. Du flyttade bara skulden från tid till förståelse.
Utvecklarens nya roll
Det mest intressanta är att utvecklarens jobb inte försvinner. Ändra densitet.
Mindre tid på boilerplate. Mer tid på avsikt, nedbrytning, granskning, integration, testning, gränser.
Utvecklaren blir en slags teknisk redaktör. Inte i den lata bemärkelsen "korrekturläsning". I den starka meningen: det avgör vad som måste finnas, vad som måste skäras, vad som är förenligt med systemet, vad som förtjänar förtroende.
En bra redaktör tar inte allt de får. Han skriver inte ens om det hela av stolthet. Känner igen bra material, för det till form, skyddar läsaren.
Med agenter är läsaren också den framtida underhållaren. Ofta är det du på tre veckor.
Mönstret jag ser växa fram
Det hälsosammaste mönstret är detta:
- mänsklig: avsikt, begränsningar, smak, ansvar;
- agent: varianter, byggnadsställningar, sökning, lokala modifieringar, repetitiva tester;
- Infrastruktur: sandlåda, CI, spårning, behörigheter, distribution;
- team: granskning, ägande, standarder.
När en av dessa bitar saknas blir något deformerat.
Endast mänsklig: långsam, ofta fast i repetitivt arbete.
Endast agent: snabb, men utan situerade omdöme.
Bara infrastruktur: Elegant process för att producera värdelösa saker.
Endast team: mycket ordnade möten kring en prototyp som aldrig kommer fram.
Det bästa händer när bitarna pratar med varandra.
En liten checklista
Innan jag låter en vibe-kodad prototyp växa, skulle jag ställa dessa frågor till mig själv:
- förstår jag strukturen i koden?
- finns det tester för kritiskt beteende?
- vet jag vilka filer agenten rörde?
- har jag tagit bort kod som genererats men inte använts?
- har några hemligheter, tokens eller falska data hamnat på fel ställe?
- respekteras minimitillgängligheten?
- har driftsättningen återställning?
- kan någon mer än jag behålla den?
Om svaret är nej på för många frågor är det inte ett misslyckande. Det är bara en prototyp som behöver förbli en prototyp lite längre.
Min läsning
Vibe-kodning är ett högljutt ord för en öm sak: glädjen av att se en idé ta form innan rädsla stoppar den.
Jag vill inte slänga den. Det vore snobbigt. Många bra saker föds så här, halvt snett och levande.
Men den återstående programvaran behöver mer. Det behöver förståelse, testning, ägande, infrastruktur, gränser. Det behöver någon säga: coolt, nu ska vi göra det på riktigt.
Kanske handlar framtiden inte om att välja mellan "seriöst" programmering och "vibe"-programmering. Kanske är det att lära sig att växla: utforska lätt, sedan konsolidera med respekt.
Den mänskliga delen finns där. Vet när du ska springa och när du ska sitta och läsa skillnaden.