Защо vibe coding има скрит проблем (и какво можем да направим)

Нека бъдем честни: vibe coding е невероятно нещо. Описваш какво искаш, гледаш агента да го изгради, виждаш тестовете да минават, пускаш в production. Усещането е почти магично.

Докато не дойде 3 часа през нощта.

Тогава идват OOM killer-ът, затворените file descriptors или сривът при първите реални потребители. Кодът е бил напълно коректен — решил е задачата точно както е описана. Просто е предположил, че разполага с безкрайна памет и безкрайни ресурси. Защото нищо в заявката ти не е казало обратното.

Невидимите предположения

Това е най-коварната част от vibe coding, за която никой не говори на конференциите. Когато пишеш код сам, носиш модели за ограничения навсякъде. Знаеш, че лаптопът ти има 16GB RAM. Знаеш лимитите на production сървъра. Знаеш, че 400GB CSV не се зарежда в паметта.

Но когато AI пише кода, тези ограничения не съществуват. AI вижда „зареди файла, сортирай го, запиши резултата" и мисли: страхотно, ще заредя всичко. Работи перфектно в тестовете. Защото тестовият файл е 50KB.

Дори code review не помага. Заподозрените редове изглеждат напълно нормално. Няма red flags при търсене на логически грешки — защото такива няма. Бъгът не е в логиката; той е в невидимата кутия, в която логиката е проектирана да се побере.

Ами ако компилаторът знаеше?

Тук става интересно. Един разработчик на име Nicolas Grislain експериментира с провокативна идея: какво ако ресурсните ограничения бяха типове, а не коментари?

Вместо да се надяваме AI кодът да уважава лимитите за памет, какво ако компилаторът буквално отказваше да компилира код, който ги нарушава? Какво ако „тази функция никога не държи повече от 100 записа в паметта" и „тази програма никога не отваря повече от 3 файла едновременно" бяха факти, проверени от компилатора, а не молитви по време на code review?

Това не е просто теоретично разсъждение. Експериментът използва Lean 4 — да, същият Lean, който направи вълни във формалната математика — за да кодира ресурсни бюджети директно в типовете на функциите. Компилаторът става одитор на ресурси, автоматично проверяващ дали кодът остава в рамките на лимитите преди изобщо да се изпълни.

Ресурсите като част от типа

Основната идея е изненадващо елегантна: прекарваш броячи на ресурси през системата от типове. Вместо да следиш „колко файла са отворени" като runtime променлива, която може да бъде пренебрегната, типовата система го следи като phantom параметър, който трябва да се балансира.

Когато отваряш файл, типовата сигнатура отразява промяната: влизаш във функцията с N отворени файла, излизаш с N+1. Когато го затвориш, връщаш се от N+1 на N. Компилаторът следи това на всяка стъпка и буквално не можеш да компилираш код, който отваря файл без да го затвори, или отваря повече файлове от определения лимит.

С паметта е подобно, но с уговорка. Записите не се реят свободно в паметта — те живеят в ограничен пуул с фиксиран брой слотове. Не държиш обект Event; държиш референция към този пуул. Типът следи колко живи референции съществуват във всеки момент, а заделянето изисква доказателство, че има място.

Магията се случва на входната точка: програмата трябва да започне с нула използвани ресурси и да завърши с нула. Не можеш да изпускаш handles или refs. Не можеш да надвишаваш лимитите. Компилаторът просто няма да те остави.

Защо е важно за vibe coding

Този подход променя как мислим за писането на prompts за AI асистенти. Днес може да добавиш бележка като „внимавай с използването на памет" или „затваряй всички file handles" — надявайки се AI да обърне внимание. С ресурсно-запознати типове, задаваш ограниченията формално и имплементацията трябва да се преорганизира, за да ги удовлетвори.

AI получава първо неограничената версия. Тестовете минават. След това включваш лимитите. Компилаторът веднага отхвърля имплементацията. AI трябва да преструктурира подхода си — може би да обработва файла на части вместо да го зарежда изцяло, или да използва connection pool вместо да отваря файлове директно.

Имплементацията не просто случайно работи; тя доказуемо работи в рамките на бюджета.

Практическата реалност

Нека сме ясни: това не е production-ready инструмент за повечето екипи засега. Подходът с Lean 4 изисква значителна настройка и има overhead в мисленето в термини на индексирани типове. Но подlying insight-ът е ценен независимо от имплементацията.

При vibe coding не просто възлагаш писането на код — възлагаш и mental model-а на системата си. AI асистентът ти не знае production средата ти. Не знае, че контейнерът ти има 512MB RAM. Не знае, че Linux kernel-ът ти лимитира file descriptors на 1024.

Докато нямаме по-добри начини да кодираме тези ограничения, имаме няколко практически опции:

1. Бъди експлицитен в prompts — „Входният файл може да съдържа до 10 милиона реда" е по-добро от „обработвай големи файлове ефективно"

2. Тествай с production-размер данни — Ако training данните ти са миниатюрни, AI няма да научи resource модели

3. Използвай bounded APIs — Архитектура, която естествено лимитира използването на ресурси (connection pools, streaming вместо зареждане) е по-трудна за злоупотреба

4. Следи за ресурсно-запознати инструменти — Индустрията започва да проучва начини да направи ограниченията експлицитни в AI-генериран код

Финални мисли

мръсната тайна на vibe coding не е, че пише бъгав код — а че пише код, който е коректен в невидимо пространство от ограничения. Това пространство включва лаптопа ти, тестовата ти среда и може би първите ти хиляда потребители. Определено не включва „production в мащаб."

Ресурсно-запознати типови системи като този Lean 4 експеримент сочат към бъдеще, където „коректен" означава повече от „логически правилен". Означава „доказуемо остава в границите, които реално съществуват."

Това е бъдеще, към което си струва да се стремим. Дотогава — пази тестовите си данни близо до production размер и може би добави допълнителна бележка в prompts-ите за тези file descriptor лимити.

Твоят future on-call self ще ти благодари.