Vibe coding: a varázslat vége

Lassan be kell látnunk: a vibe coding tényleg átírta a szabályokat. Leírod, mire van szükséged, figyeled, ahogy az AI megírja, látod, ahogy a tesztek zöldre váltanak, és máris kész vagy. Tökéletesen működik — egészen addig, amíg nem működik.

Az a bizonyos "egészen addig" általában hajnali háromkor érkezik. Az alkalmazásod szépen indul, szépen kezeli az első néhány kérést, aztán a semmiből leöli egy OOM reaper. Vagy kinyit tíz ezer fájlleírót és összeomlik. Vagy hibátlanul fut a tesztadatodon, és darabokra esik, amikor igazi felhasználók érkeznek.

A kód tökéletes volt. Pontosan megoldotta a feladatot, ahogy kérted. Csak épp végtelen memóriát és végtelen fájlleírót feltételezett — mert a promptodban nem szerepelt más.

A csendes gyilkos: kimondatlan feltételezések

Ez a vibe coding legszigorúbb része, amit senki sem hangsúlyoz a konferenciákon. Amikor saját magad írod a kódot, a korlátok végig ott vannak a fejeden. Tudod, hogy egy 16GB RAM-os laptopon futsz. Tudod, hogy a production szervernek vannak fájlleíró-korlátai. Tudod, hogy azt a 400GB-os CSV-t nem lehet csak úgy betölteni a memóriába.

De amikor egy AI írja a kódot, ezek a korlátok egyszerűen nem léteznek. Az AI azt látja, hogy "töltsd be a fájlt, rendezd, írd ki az eredményt" — és gondol egyet: betöltöm az egészet. Teszten tökéletesen működik. A tesztfájl 50KB volt.

A code review sem fogja elkapni. A gyanús sorok abszolút értelmesnek tűnnek. Semmi nem riaszt el, amikor logikai hibákat keresel — mert nincsenek logikai hibák. A probléma nem a logikában van; a láthatatlan dobozban van, amire a logikát tervezték.

És ha a compiler tudná?

Itt kezdődik az érdekes rész. Nicolas Grislain fejlesztő egy provokatív ötlettel kísérletezik: mi lenne, ha az erőforrás-korlátok típusok lennének, nem megjegyzések?

Ahelyett, hogy reménykednél, hogy az AI-generált kód tiszteletben tartja a memóriakorlátokat, mi lenne, ha a compiler egyszerűen megtagadná a fordítást, ha az megsérti őket? Mi lenne, ha a "ez a függvény soha nem tart a memóriában 100 rekordnál többet" és a "ez a program egyszerre sosem nyit ki 3 fájlnál többet" a compiler által ellenőrzött tények lennének, nem imák, amiket a code review közben mormolsz?

Ez nem csak elméleti ködölés. A kísérlet Lean 4-et használ — igen, azt a Leant, ami a formális matematikában hódít — hogy az erőforrás-költségvetést közvetlenül a függvénytípusokba kódolja. A compiler erőforrás-auditorrá válik, automatikusan ellenőrizve, hogy a kód a futás előtt belül marad-e a korlátokon.

Az erőforrások számon tartása

A lényeg meglepően elegáns: az erőforrás-számlálókat végigvezeted a típusrendszeren. Ahelyett, hogy "hány fájl van nyitva" egy futásidejű változó lenne, amit simán figyelmen kívül lehet hagyni, a típusrendszer nyomon követi ezt egy fantom-paraméterként, aminek egyensúlyban kell lennie.

Amikor megnyitsz egy fájlt, a típusaláírás tükrözi a változást: belépsz N fájllal, kilépsz N+1-gyel. Amikor bezárod, visszament N+1-ről N-re. A compiler minden lépésnél követi ezt, és egyszerűen nem tudsz lefordítani olyan kódot, ami fájlt nyit ki bezárás nélkül, vagy túllépi a megadott limitet.

A memória hasonlóan működik, de van egy csavar. A rekordok nem lebegnek szabadon a memóriában — egy kötött méretű poolban élnek, fix számú hellyel. Nem egy Event objektumot tartasz; hanem egy referenciát a poolba. A típus nyomon követi, hány élő referencia van bármely pillanatban, és az allocációhoz bizonyíték kell, hogy van hely.

A varázslat az entry pointon történik: a programnak nulla erőforráshasználattal kell indulnia és nulla-val kell endsselnie. Nem szivároghatnak handle-ok vagy referenciák. Nem lépheted túl a limiteket. A compiler egyszerűen nem engedi.

Miért fontos ez a vibe codingnál?

Ez a megközelítés alapjaiban változtatja meg, ahogy az AI asszisztenseket promptoljuk. Ma talán odavetsz valamit: "legyél óvatos a memóriahasználattal" vagy "zárd be az összes fájlleírót" — remélve, hogy az AI odafigyel. Az erőforrás-tudatos típusokkal formálisan adod meg a korlátokat, és az implementációnak át kell szerveznie magát, hogy megfeleljen nekik.

Az AI először a korlátok nélküli verziót kapja meg. A tesztek átmennek. Aztán bekapcsolod a limiteket. A compiler azonnal elutasítja az implementációt. Az AI-nak át kell strukturálnia a megközelítését — talán chunkenként dolgozza fel a fájlt ahelyett, hogy egyszerre töltené be, vagy kapcsolati poolt használ a közvetlen fájlmegnyitás helyett.

Az implementáció nem csak úgy "működik"; bizonyíthatóan a költségvetésen belül működik.

A valóság

Legyünk tiszták: ez még nem production-ready eszköz a legtöbb csapatnak. A Lean 4 megközelítés jelentős felállást igényel, és van overhead az indexed típusokban való gondolkodásban. De az alapvető belátás az implementációtól függetlenül értékes.

Vibe coding közben nem csak a kódírást outsourcedzd, hanem a rendszered mentális modelljét is. Az AI asszisztensed nem ismeri a production környezetedet. Nem tudja, hogy a containernek csak 512MB RAM-ja van. Nem tudja, hogy a Linux kernel 1024-re korlátozza a fájlleírókat.

Amíg nem lesz jobb módunk ezeket a korlátokat kódolni, van néhány gyakorlatias opció:

1. Légy kifejező a promptjaidban — "A bemeneti fájl akár 10 millió sort is tartalmazhat" jobb, mint a "kezelj nagy fájlokat hatékonyan"

2. Tesztelj production méretű adatokkal — Ha a képzési adat apró, az AI nem tanul erőforrás-mintákat

3. Használj kötött API-kat — Az az architektúra, ami természetesen korlátozza az erőforráshasználatot (connection poolok, streaming betöltés helyett), nehezebben használható rosszul

4. Figyeld az erőforrás-tudatos eszközöket — Az iparág elkezdett felfedezni módokat, hogyan tegye a korlátokat expliciten láthatóvá az AI-generált kódban

A lényeg

A vibe coding piszkos titka nem az, hogy hibás kódot ír — hanem hogy olyan kódot ír, ami egy láthatatlan korlát-térben helyes. Az a tér tartalmazza a laptopodat, a tesztkörnyezetedet, talán az első ezer felhasználódat. De biztosan nem tartalmazza a "production méretezésben futás"-t.

Az erőforrás-tudatos típusrendszerek, mint ez a Lean 4 kísérlet, egy jövő felé mutatnak, ahol a "helyes" többet jelent, mint "logikailag igaz". Ez azt jelenti: "bizonyítottan a valós korlátokon belül marad".

Ez egy jövő, amit érdemes építeni. Addig is: tartsd közel a tesztadatokat a production mérethez, és talán adj egy extra megjegyzést a promptjaidba azokról a fájlleíró-limitációkról.

A jövőbeli on-call énod hálás lesz.