Скритият данък върху AI-кода: Къде "vibe coding" се проваля

Искам да ви разкажа за разговор миналата седмица с един стартъп основател. Той пращаше нови функции с невероятна скорост — три пъти по-бързо от предишната му компания. „Използваме vibe coding за всичко", каза той с гордост. После спомена, че системата му за авторизация е била експлоатирана два пъти през последния месец.

Връзката не е случайна.

Капана на скоростта

Ето неприятната истина, за която никой не говори на тези AI конференции за разработчици: невероятният тласък в скоростта идва с измерим данък върху дефектите. Проучванията последователно показват, че около 45% от кода, генериран с AI, съдържа проблеми със сигурността. Не дребни проблеми — реални, експлоатируеми недостатъци, които могат да изложат потребителски данни, да заобиколят авторизацията или да създадат пътища за атака.

Механизмът не е, че AI произвежда лош код. Механизмът е, че vibe coding премахва вратите, които хващат лошия код.

Когато подадете заявка към AI агент и пуснете резултата в продукция без да го прочетете внимателно, вие заобикаляте целия си SDLC. Без преглед на спецификациите. Без одит на сигурността. Без проверка на покритието с тестове. Без документация. Премахвате точно онези контролни точки, които съществуват, за да защитават потребителите и репутацията ви.

Къде AI греши (предвидимо)

Ето какво прави това особено опасно: AI не се проваля случајно. Дефектите се концентрират точно на грешните места.

Уязвимости от тип cross-site scripting се появяват 2,74 пъти по-често в сравнение с код, написан от хора. Логически грешки се срещат 1,75 пъти над базовото ниво. Това не са естетически проблеми или въпроси за справяне с гранични случаи — това са уязвимостите, които имат значение за авторизацията, обработката на плащания и всяка система, която работи с недоверени потребителски данни.

Независима телеметрия за сигурността потвърждава модела. Индустриалните доклади вече приписват нарастващия брой уязвимости директно на засиленото използване на генеративен AI в процесите на разработка. Сериозността на тези уязвимости също се увеличава.

Трите свойства, които го правят опасно

Това не е просто за индивидуални грешки. Проблемът се натрупва заради това как AI агентите работят фундаментално:

Скоростта надминава прегледа. Агент може да генерира хиляда реда код за секунди. Човек-рецензент не може да провери този код смислено със същата скорост. Това създава структурен натиск да се пропусне стъпката за преглед.

Недетерминизмът прави възпроизвеждането невъзможно. Една и съща заявка може да произведе различни резултати. Онази грешка, която забелязахте? Успех да възпроизведете точно коя версия на кода я е причинила. Това прави дебъгването подвижна цел и следите за одит — ненадеждни.

Ценовият натиск насърчава преки пътища. AI токените струват пари. Стартирането на изчерпателни тестове струва повече токени. Икономическият стимул тласка към намаляване на верификацията — обратното на това, което сигурността изисква.

Реални щети, реални примери

Може би си мислите, че това е теоретично. Не е.

Изследователи по сигурността са документирали злонамерен софтуер, генериран с AI, с критични грешки в имплементацията — код, който е трябвало да бъде опасен, но се проваля при основна криптографска имплементация. Още по-притеснително: разработчици с добри намерения са пуснали production рамки с уязвимости за заобикаляне на авторизацията, в чието генериране са помогнали AI инструменти. И в двата случая провалът не е от злонамереност или некомпетентност — а от третиране на AI изхода като готов за продукция без нормалната верификационна линия.

Средният път

Не казвам да не използвате AI инструменти за писане на код. Това би било като да съветваш разработчиците през 2015 г. да избягват GitHub, защото хостването на код може да позволи лоши практики. Печалбите в производителността са реални и технологията няма да изчезне.

Но трябва да сме честни къде се изместват тесните места.

Печалбата в пропускателна способност от AI коденето е истинска. Но тя премества тясното място от писане към проверка. Ако не отчитате това изместване, натрупвате технически дълг по-бързо, отколкото пускате нови функции.

Ето как изглежда това на практика:

Отнасяйте се към AI като към бърз стажант, не като към старши инженер. Младши разработчик може бързо да генерира код. Старши разработчик може да ви каже защо този код е безопасен за пускане. AI инструментите са отлични в първото. За второто ви трябват хора.

Приложете PR договор. Всяко pull request трябва да документира: Какво е било намерението? Какво доказателство доказва, че работи? Какъв е рисковият слой? Използван ли е AI за генериране на това, и ако да — къде? Това налага отчетността, която vibe coding премахва.

Децентрализирайте критичните проверки за сигурност. Не разчитайте на middleware за авторизация като единствена врата. Имплементирайте проверки за права директно в route handlers. Изнесете логиката за сигурност от единични точки на провал, които AI инструментите могат неусетно да конфигурират погрешно.

Запазете vibe coding за подходящи контексти. Скелетиране на CLI? Прототипиране на UI? Изследване на подходи за оптимизация преди ангажимент към архитектура? Перфектни случаи на употреба. Пускане директно в production с обработка на недоверен input? Там ви трябва спецификационно-базирана разработка с порти за преглед.

Инвестирайте в моделиране на заплахи преди merge. Всеки кодов път, който обработва недоверен input, се нуждае от човешки преглед на моделите на заплахи, преди да достигне production. Не по избор. Не пропускаемо, когато изоставате от срокове.

Истинското правило

Линията между „безопасно за vibe" и „трябва да се инженерства" не е рязка. Тя се измества с подобряването на моделите и с нарастването на сложността на системата ви. Правилото не може да бъде „никога не използвай AI за кодене". Правилото трябва да бъде: „знай в кой режим си и поставяй порти според залозите".

Но ето къде всички са съгласни: веднъж щом бъгът ви може да навреди на друг човек, prompt-and-ship е регрес. Веднъж щом кодът ви обработва реални пари, реални лични данни или реални решения за безопасност, печалбите в скорост от vibe coding не могат да оправдаят премахването на верификационната инфраструктура, която защитава потребителите ви.

Разработчиците и екипите, които пускат AI-генериран код отговорно, не се движат по-бавно. Те се движат с осъзнатост къде сега се намира тясното място за проверка — и бюджетират за него честно.

Вашите потребители разчитат на вас да хванете това, което AI пропуска.