Vibe coding har et skjult problem – og det er ikke de åbenlyse fejl

Lad os være ærlige: vibe coding er en game-changer. Du beskriver, hvad du vil have, ser agenten bygge det, tjekker at tests kører grønt, og shipper. Det føles som ren magi.

Indtil det ikke gør.

Den magi plejer at briste omkring kl. 3 om natten. Din app starter fint, håndterer de første requests elegant, og bliver så uprovokeret slået ihjel af en OOM-reaper. Eller den åbner titusindvis af file descriptors og bryder sammen. Eller den kører perfekt på dine testdata og smelter ned, når rigtige brugere dukker op.

Koden var korrekt. Den løste præcis det problem, du specificerede. Den antog bare uendelig hukommelse og uendelige file handles – fordi intet i din prompt sagde andet.

Den stille morder: ting vi glemmer at fortælle

Her ligger det tricky ved vibe coding, som ingen rigtig snakker om på konferencer. Når du skriver koden selv, har du hele tiden en mental model af begrænsninger med i billedet. Du ved, du kører på en laptop med 16GB RAM. Du ved, produktionsserveren har grænser for file descriptors. Du ved, at 400GB CSV-fil ikke lige er noget, du kan lægge i hukommelsen.

Men når en AI skriver din kode, findes de begrænsninger ikke. AI'en ser "læs filen, sorter den, skriv resultatet" og tænker: fedt, jeg læser hele filen. Det virker perfekt i test. Testfilen er 50KB.

Kodereviews fanger det heller ikke. De problematiske linjer ser fuldstændigt fornuftige ud. Intet får en rød flag, når du leder efter logiske fejl – for der er ingen. Fejlen ligger ikke i logikken; den ligger i den usynlige boks, logikken blev designet til at passe ind i.

Hvad hvis compileren kendte begrænsningerne?

Her bliver det interessant. En udvikler ved navn Nicolas Grislain har eksperimenteret med en provokerende idé: hvad hvis ressourcebegrænsninger var typer, ikke kommentarer?

I stedet for at håbe, at din AI-genererede kode respekterer hukommelsesgrænser, hvad hvis compileren bogstaveligt nægtede at kompilere kode, der overskred dem? Hvad hvis "denne funktion har aldrig mere end 100 records i hukommelsen ad gangen" og "dette program har aldrig mere end 3 filer åbne samtidig" var fakta, compileren verificerede – ikke bønner, du hvisker under kodereview?

Dette er ikke bare teoretisk vrøvl. Eksperimentet bruger Lean 4 – ja, samme Lean der har taget formel matematik med storm – til at kode ressourcebudgetter direkte ind i funktionstyper. Compileren bliver en ressource-revisor, der automatisk tjekker, at din kode holder sig inden for grænserne, før den nogensinde kører.

Få ressourcer til at tælle

Kernetricket er overraskende elegant: før ressourceoptællinger igennem typesystemet. I stedet for at holde styr på "hvor mange filer er åbne" som en runtime-variabel, der nemt kan blive ignoreret, tracker typesystemet det som en phantom parameter, der skal balancere.

Når du åbner en fil, afspejler type-signaturen ændringen: du går ind i funktionen med N filer åbne og kommer ud med N+1. Når du lukker den, går du fra N+1 tilbage til N. Compileren holder styr på dette ved hvert skridt, og du kan bogstaveligt ikke kompilere kode, der åbner en fil uden at lukke den – eller åbner filer over en defineret grænse.

Hukommelse fungerer lignende, men med en twist. Records flyder ikke frit rundt i hukommelsen – de bor i en afgrænset pool med et fast antal pladser. Du holder ikke et Event-objekt; du holder en reference ind i den pool. Typen holder styr på, hvor mange live-referencer der eksisterer på ethvert tidspunkt, og allocation kræver bevis for, at der er plads.

Magien sker ved entry point: programmet skal starte med nul ressourcer i brug og slutte med nul. Du kan ikke lække handles eller referencer. Du kan ikke overskride grænser. Compileren lader dig ganske enkelt ikke.

Hvorfor dette betyder noget for vibe coding

Denne tilgang transformerer, hvordan vi tænker om at promotte AI-assistenter. I dag ville du måske tilføje en note som "vær forsigtig med hukommelsesforbrug" eller "luk alle filehandles" – i håb om at AI'en lægger mærke til det. Med ressource-bevidste typer specificerer du begrænsninger formelt, og implementationen må reorganisere sig selv for at opfylde dem.

AI'en får den ubegrænsede version først. Tests kører grønt. Så aktiverer du grænserne. Compileren afviser straks implementationen. AI'en må omlægge sin tilgang – måske processere filen i chunks i stedet for at læse det hele på én gang, eller bruge en connection pool i stedet for at åbne filer direkte.

Implementationen ikke bare tilfældigvis virker; den beviseligt virker inden for budgettet.

Den praktiske virkelighed

Lad os være klare: dette er ikke produktionsklar teknologi for de fleste teams endnu. Lean 4-tilgangen kræver betydelig opsætning, og der er overhead i at tænke i indekserede typer. Men den underliggende indsigt er værdifuld uanset implementation.

Når du vibe coder, outsurcer du ikke kun kode-skrivningen – du outsurcer også den mentale model af dit system. Din AI-assistent kender ikke din produktionsenvironment. Den kender ikke, at din container har 512MB RAM. Den kender ikke, at din Linux-kerne sætter file descriptors ceiling ved 1024.

Indtil vi har bedre måder at kode disse begrænsninger ind, har vi et par pragmatiske muligheder:

1. Vær eksplicit i prompts – "Input-filen kan indeholde op til 10 millioner rækker" slår "håndtér store filer effektivt"

2. Test med produktionsskala data – Hvis dine træningsdata er mikroskopiske, lærer din AI aldrig ressource-mønstre

3. Brug bounded APIs – Arkitektur der naturligt begrænser ressourceforbrug (connection pools, streaming i stedet for at læse alt ind) er sværere at misbruge

4. Hold øje med ressource-bevidst værktøjer – Branchen begynder at udforske måder at gøre begrænsninger eksplicitte i AI-genereret kode

Konklusionen

Vibe codings beskidte hemmelighed er ikke, at den skriver buggy kode – det er, at den skriver kode, der er korrekt inden for et usynligt constraint-rum. Det rum inkluderer tilfældigvis din laptop, dit testmiljø og måske dine første tusind brugere. Det inkluderer absolut ikke "produktion i stor skala."

Ressource-bevidste typesystemer som dette Lean 4 eksperiment peger mod en fremtid, hvor "korrekt" betyder mere end "logisk rigtigt." Det betyder "bevist at holde sig inden for de grænser, der faktisk eksisterer."

Det er en fremtid værd at bygge imod. Indtil da: hold dine testdata tæt på produktionsstørrelse, og tilføj måske en ekstra note i dine prompts om de der file descriptor-grænser.

Din fremtidige on-call version af dig selv vil være taknemmelig.