Защо кодът от AI изисква човешка проверка (и това е напълно нормално)

Софтуерното развитие влиза в нова ера. Инструменти като Claude и ChatGPT ускоряват процеса от идея до готов код – от седмици на дни. Опиши функция, приеми промените, коригирай и пусни. Това радикално повишава темпото.

Но има капан.

Преди време прегледах код от такъв бърз проект – вътрешен инструмент, не критичен, но типичен за 2024 г. Не намерих нищо драматично като "AI полудя". Проблемите бяха банални: около 28 грешки, главно свързани със сигурността. Повечето – класически уязвимости от OWASP Top 10, известни отдавна.

Това не е атака срещу AI. Става дума за скоростта, която изпреварва мисленето за архитектура и предотвратява проблеми.

Проблемът не е в AI, а в въпросите, които не зададохте

Кодът изглеждаше солиден. Архитектурата беше логична, компонентите – добре разделени, библиотеките – разумни. Ако го пишдах сам за уикенд, нямаше да се отличи на пръв поглед.

Разликата е в основите. AI отлично изпълнява поръчката. Кажете "напиши система за потребители" – ще я получите. Но няма да попита: кой има достъп? кои данни са критични? къде е автентикацията? какво става при директен атака?

AI строи функции. Не проектира сигурност, която да ви остави да спите спокойно.

Конкретен случай: админ функция без защита

Представете си serverless функция за админ задачи – създаване на потребители, ресет на пароли, изтриване на акаунти. Екипът правилно държи ключовете на сървъра, без да ги излага в браузъра.

Функцията нямаше никаква проверка за достъп.

Не слаба, не грешна – нула. Всеки с DevTools, URL и POST заявка можеше да създаде админ, да смени пароли или да изтрие базата.

Frontend-ът криеше бутона от неадмини – изглеждаше сигурно. Но UI защита е илюзия. Това е класически bypass на авторизация от 2003 г. AI не го забеляза, защото поръчката беше "функция за админи да създават потребители". Тя го прави – и за всички останали, щом не сте уточнили.

AI не чете мисли. Не знае какво сте пропуснали.

Базата данни, сигурна на теория

Друг чести случай. Базата ви поддържа row-level security (RLS) – ограничаване на редове по идентичност. Идеално за API ключ в JavaScript.

Екипът поиска multi-user поддръжка. AI създаде миграции с нови таблици и RLS. Перфектно.

Но петте стари таблици с реални данни? Игнорирани. Миграцията не провери, не активира, не спомена.

Пуснете на чиста среда – новите таблици са заключени, старите – отворени за всеки с връзка и endpoint.

AI реши точната задача. Не попита дали искате пълна сигурност.

Какво значи това за практиката ви

Не отказвайте AI. Скоростта е ключова. Но добавете отговорност: опитни хора да преглеждат архитектурата, не само синтаксиса.

Ето какво работи:

Създайте чеклист за сигурност преди старт. Попитайте: кой вика този endpoint? какво става без права? данните публични ли са? всички таблици с RLS?

Senior разработчици правят threat modeling. Не четат ред по ред. AI генерира код, хората – сигурност.

Уточнявайте автентикация в поръчките. Не "user management endpoint", а "endpoint за админи с login, опиши предположенията за auth".

Тествайте авторизация отделно. Проверете що non-users не могат да правят.

Основният модел, който трябва да знаете

AI не пише небезопасен код. Той прави точно каквото поискайте – и игнорира пропуснатото. Това е плюс: не измисля изисквания. Но отговорността е ваша. AI изпълнява дизайна ви, не го мисли.

В случая ми човек каза "този endpoint иска auth". Поправката отне минути. Стар уязвимост срещна нов workflow – и спечели, защото имаше опитен поглед.

Формулата за бъдещето: AI за скорост, хора за архитектура. И двете са задължителни.

Искате да избегнете тези капани? В NameOcean виждаме стартъпи да се давят в технически дълг от бързо пушнати функции. Нашата cloud hosting платформа включва готова сигурност – rate limiting, API key мениджмънт, audit logs. Работи автоматично, без да питате. Едно по-малко притеснение при висок темп.