Hemmeligheten vibe coding ikke forteller deg

La meg være ærlig: vibe coding er en game-changer. Du beskriver hva du vil ha, ser agenten bygge det, følger med på at testene blir grønne, og sender det ut. Det føles magisk — helt til det ikke gjør det.

Det "ikke magiske" punktet dukker som regel opp rundt klokken 03:00 om natta. Appen starter fint, håndterer noen få forespørsler elegant, og blir så brutalt drept av en OOM-reaper. Eller den åpner titusenvis av file descriptors og kollapser. Eller den kjører feilfritt på testdataene dine og smelter sammen når ekte brukere dukker opp.

Koden var korrekt. Den løste problemet nøyaktig som spesifisert. Den bare antok uendelig minne og uendelig mange filer — fordi ingenting i prompten din sa noe annet.

Den stille morderen: Underforståtte antakelser

Dette er den skumle biten ved vibe coding som ingen snakker om på konferanser. Når du skriver kode selv, har du mentale modeller av begrensninger med deg overalt. Du vet at du kjører på en laptop med 16GB RAM. Du vet at produksjonsserveren har begrensninger på filer. Du vet at den 400GB CSV-filen ikke er noe du bare kan laste inn i minnet.

Men når en AI skriver koden din, finnes ikke disse begrensningene. AIen ser "last fila, sorter den, skriv resultatet" og tenker: flott, jeg laster hele greia. Det funker perfekt i testing. Testfila er 50KB.

Kodegjennomganger fanger ikke dette heller. De aktuelle linjene ser helt fornuftige ut. Ingenting vekker mistanke når du leter etter logikkfeil — fordi det er ingen. Buggen sitter ikke i logikken; den sitter i den usynlige boksen logikken ble designet for å passe inn i.

Tenk om kompilatoren faktisk visste?

Her blir det interessant. En utvikler ved navn Nicolas Grislain har eksperimentert med en provoserende idé: hva om ressursbegrensninger var typer, ikke kommentarer?

Istedenfor å håpe at AI-generert kode respekterer minnegrenser, hva om kompilatoren bokstavelig nektet å kompilere kode som brøt dem? Hva om "denne funksjonen holder aldri mer enn 100 poster i minnet" og "dette programmet har aldri mer enn 3 filer åpne samtidig" var fakta kompilatoren verifiserte, ikke bønner du hvisker under kodegjennomgang?

Dette er ikke bare teoretisk vås. Eksperimentet bruker Lean 4 — ja, den samme Lean som har rast gjennom formell matematikk — til å kode ressursbudsjetter direkte inn i funksjonstyper. Kompilatoren blir en ressursrevisor som automatisk sjekker at koden din holder seg innenfor grenser før den noensinne kjører.

Å gjøre ressurser tellende

Kjernetrikset er overraskende elegant: før ressursantall gjennom typesystemet. Istedenfor å spore "hvor mange filer er åpne" som en runtime-variabel som kanskje blir ignorert, sporer typesystemet det som en phantom-parameter som må balansere.

Når du åpner en fil, reflekterer typesignaturen endringen: du går inn i funksjonen med N filer åpne og kommer ut med N+1. Når du lukker den, går du fra N+1 tilbake til N. Kompilatoren sporer dette ved hvert steg, og du kan bokstavelig talt ikke kompilere kode som åpner en fil uten å lukke den, eller åpner flere filer enn en definert grense.

Minne funker lignende, men med en twist. Poster flyter ikke fritt i minnet — de lever i en avgrenset pool med et fast antall plasser. Du holder ikke et Event-objekt; du holder en referanse til den poolen. Typen sporer hvor mange levende referanser som eksisterer til enhver tid, og allokering krever bevis for at det er plass.

Magiens skjer ved inngangspunktet: programmet må starte med null ressurser i bruk og ende med null. Du kan ikke lekke handles eller referanser. Du kan ikke overskride grenser. Kompilatoren lar deg rett og slett ikke.

Hvorfor dette betyr noe for Vibe Coding

Denne tilnærmingen transformerer hvordan vi tenker på å prompta AI-assistenter. I dag legger du kanskje til en note som "vær forsiktig med minnebruk" eller "lukk alle filer" — i håp om at AIen tar hensyn. Med ressursbevisste typer spesifiserer du begrensninger formelt, og implementasjonen må omorganisere seg for å oppfylle dem.

AIen får den ubegrensede versjonen først. Tester passerer. Så aktiverer du grensene. Kompilatoren avviser umiddelbart implementasjonen. AIen må restrukturere tilnærmingen — kanskje prosessere fila i chunks istedenfor å laste alt på en gang, eller bruke en connection pool istedenfor å åpne filer direkte.

Implementasjonen funker ikke bare tilfeldigvis; den er bevist å holde seg innenfor budsjettet.

Den praktiske virkeligheten

La meg være klar: dette er ikke produksjonsklart verktøy for de fleste team enda. Lean 4-tilnærmingen krever betydelig oppsett, og det er overhead i å tenke i indekserte typer. Men den underliggende innsikten er verdifull uansett implementasjon.

Når du driver med vibe coding, out sourcer du ikke bare kodewritingen, men den mentale modellen av systemet ditt. AI-assistenten din kjenner ikke produksjonsmiljøet ditt. Den vet ikke at containeren din har 512MB RAM. Den vet ikke at Linux-kjernen din begrenser file descriptors til 1024.

Inntil vi har bedre måter å kode disse begrensningene på, har vi noen pragmatiske alternativer:

1. Vær eksplisitt i prompter — "Inndatafila kan inneholde opptil 10 millioner rader" slår "håndter store filer effektivt"

2. Test med produksjonsskala-data — Hvis treningsdataene dine er små, vil ikke AIen lære ressursmønstre

3. Bruk avgrensede APIer — Arkitektur som naturlig begrenser ressursbruk (connection pools, streaming istedenfor lasting) er vanskeligere å misbruke

4. Følg med på ressursbevisst verktøy — Bransjen begynner å utforske måter å gjøre begrensninger eksplisitt i AI-generert kode

Konklusjonen

Vibe codings skitne hemmelighet er ikke at den skriver buggy kode — det er at den skriver kode som er korrekt innenfor et usynlig begrensningsrom. Det rommet inkluderer laptopen din, testmiljøet ditt, og kanskje de første tusen brukerne dine. Det inkluderer definitivt ikke "produksjon i stor skala."

Ressursbevisste typesystemer som dette Lean 4-eksperimentet peker mot en fremtid der "korrekt" betyr mer enn "logisk riktig." Det betyr "bevist å holde seg innenfor grensene som faktisk eksisterer."

Det er en fremtid verdt å strekke seg mot. Inntil da: hold testdataene nærme produksjonsstørrelse, og legg kanskje til en ekstra note i promptene dine om de der file descriptor-grensene.

Fremtidige deg på vakt vil sette pris på det.