Vibe coding: Magin som slutar vid midnatt

Låt mig vara ärlig: vibe coding förändrar spelet. Du beskriver vad du vill ha, ser agenten bygga det, tittar på hur testerna grönsnar, och shippar. Det känns som magi — tills det gör det.

Det "tills" dyker oftast upp runt tre på natten. Din app startar fint, hanterar några förfrågningar perfekt, och blir sedan skoningslöst avlivad av en OOM-reaper. Eller så öppnar den tiotusen filhandtag och kollapsar. Eller så kör den felfritt på din testdata och rasar samman när riktiga användare dyker upp.

Koden var korrekt. Den löste problemet exakt som specificerat. Den antog bara oändligt minne och oändliga filhandtag — för inget i din prompt sa något annat.

Den tysta mördaren: Osagda antaganden

Det här är det luriga med vibe coding som ingen pratar om på konferenser. När du skriver kod själv bär du mentala modeller av begränsningar överallt. Du vet att du kör på en laptop med 16GB RAM. Du vet att produktionsservern har gränser för filhandtag. Du vet att den där 400GB CSV-filen inte är något du bara kan ladda in i minnet.

Men när en AI skriver din kod existerar inte de begränsningarna. AI:n ser "ladda filen, sortera den, skriv resultatet" och tänker: perfekt, jag laddar hela. Det fungerar fint i testning. Testfilen är 50KB.

Kodgranskningar fångar inte det här heller. De skyldiga raderna ser helt rimliga ut. Ingenting väcker någon flagga när du letar efter logiska fel — för det finns inga. Buggen sitter inte i logiken; den sitter i den osynliga box som logiken var designad för att passa in i.

Tänk om kompilatorn faktiskt visste?

Här blir det intressant. En utvecklare vid namn Nicolas Grislain har experimenterat med en provocerande idé: vad om resursbegränsningar var typer, inte kommentarer?

Istället för att hoppas att din AI-genererade kod respekterar minnesgränser — vad om kompilatorn bokstavligen vägrade kompilera kod som bröt mot dem? Vad om "den här funktionen håller aldrig mer än 100 poster i minnet" och "det här programmet har aldrig fler än 3 filer öppna samtidigt" var fakta som kompilatorn verifierade, inte böner du viskar under kodgranskningen?

Det här är inte bara teoretiskt fnulande. Experimentet använder Lean 4 — ja, samma Lean som skapat rubriker i formell matematik — för att koda resursbudgetar direkt in i funktionstyper. Kompilatorn blir en resursrevisor som automatiskt kontrollerar att din kod håller sig inom gränserna innan den någonsin kör.

Att få resurser att räknas

Kärntricket är förvånansvärt elegant: trä resursräkningar genom typsystemet. Istället för att spåra "hur många filer är öppna" som en runtime-variabel som kanske ignoreras, spårar typsystemet det som en fantomparameter som måste balansera.

När du öppnar en fil reflekterar typsignaturen förändringen: du går in i funktionen med N filer öppna och går ut med N+1. När du stänger den går du från N+1 tillbaka till N. Kompilatorn spårar detta vid varje steg, och du kan bokstavligen inte kompilera kod som öppnar en fil utan att stänga den, eller öppnar fler filer än en definierad gräns.

Minne fungerar liknande, men med en twist. Poster flyter inte fritt i minnet — de lever i en begränsad pool med ett fast antal platser. Du håller inte ett Event-objekt; du håller en referens till den poolen. Typen spårar hur många levande referenser som finns vid varje ögonblick, och allokering kräver bevis på att det finns plats.

Magin händer vid entry point: programmet måste starta med noll resurser i användning och sluta med noll. Du kan inte läcka handtag eller referenser. Du kan inte överskrida gränser. Kompilatorn tillåter det helt enkelt inte.

Varför det här spelar roll för Vibe Coding

Den här approachen förändrar hur vi tänker kring att prompta AI-assistenter. Idag lägger du kanske till en anteckning som "var försiktig med minnesanvändning" eller "stäng alla filhandtag" — och hoppas att AI:n bryr sig. Med resursmedvetna typer specificerar du begränsningar formellt, och implementationen måste organisera om sig för att uppfylla dem.

AI:n får den obegränsade versionen först. Tester passerar. Sedan aktiverar du gränserna. Kompilatorn avvisar omedelbart implementationen. AI:n måste restruktuera sin approach — kanske processa filen i chunkar istället för att ladda allt på en gång, eller använda en connection pool istället för att öppna filer direkt.

Implementationen fungerar inte bara av en slump; den bevisas fungera inom budgeten.

Den praktiska verkligheten

Låt mig vara tydlig: det här är inte produktionsredo verktyg för de flesta team ännu. Lean 4-approachen kräver betydande setup, och det finns overhead i att tänka i termer av indexerade typer. Men den underliggande insikten är värdefull oavsett implementation.

När du vibe-kodar outsourcar du inte bara kodskrivandet utan den mentala modellen av ditt system. Din AI-assistent känner inte till din produktionsmiljö. Den vet inte att din container har 512MB RAM. Den vet inte att din Linux-kärna capar filhandtag vid 1024.

Tills vi har bättre sätt att koda dessa begränsningar har vi några pragmatiska alternativ:

1. Var explicit i prompts — "Indatafilen kan innehålla upp till 10 miljoner rader" slår "hantera stora filer effektivt"

2. Testa med produktionsskalig data — Om din träningsdata är pytteliten kommer din AI aldrig lära sig resursmönster

3. Använd begränsade API:er — Arkitektur som naturligt begränsar resursanvändning (connection pools, streaming istället för att ladda) är svårare att missbruka

4. Håll utkik efter resursmedvetna verktyg — Branschen börjar utforska sätt att göra begränsningar explicita i AI-genererad kod

Bottom Line

Vibe codings smutsiga hemlighet är inte att den skriver buggy kod — det är att den skriver kod som är korrekt inom ett osynligt begränsningsutrymme. Det utrymmet råkar inkludera din laptop, din testmiljö, och kanske dina första tusen användare. Det inkluderar definitivt inte "produktion i skala."

Resursmedvetna typsystem som det här Lean 4-experimentet pekar mot en framtid där "korrekt" betyder mer än "logiskt rätt." Det betyder "bevisat hålla sig inom de gränser som faktiskt existerar."

Det är en framtid värd att bygga mot. Tills dess, håll din testdata nära produktionsstorlek, och lägg gärna till en extra anteckning i dina prompts om de där filhandtagsgränserna.

Ditt framtida on-call-jag kommer att tacka dig.