В последнее время наблюдаю занятный феномен: люди, которые никогда не проходили полный SDLC, внезапно стали “AI-разработчиками” и продают системы уровня enterprise по ценникам, от которых у любого архитектора дергается глаз.

Самый показательный кейс — “сделаем вам Auth/IAM за 100 млн рублей”. - Без ролевой модели. - Без описания потоков. - Без threat model. Но зато “с AI” … быстро и качественно и меньшей командой (один за троих и все за одного).

Проблема здесь не в AI. Проблема в полном отсутствии инженерного мышления. Где ломается “AI-разработка”. Если разложить любой нормальный проект по SDLC, становится очевидно: - Нет требований (functional / non-functional). - Нет спецификации. - Нет модели домена. - Нет контрактов между компонентами. - Нет понимания жизненного цикла системы.

Но зато есть ВСЕМОГУЩИЙ (нет) prompt ИЛИ “Но у нас же не просто prompt, у нас агент”. И вот здесь начинается подмена понятий. Сейчас часто в ответ на критику звучит: - у нас Claude Code - у нас MCP - у нас агентная модель - у нас есть planning / research / architecture skills И в этом случае создаётся ощущение, что это уже почти полноценная замена инженерному процессу. Но, слава Богу, это не так - инженеры все еще нужны.

Агентная система — это прежде всего оркестратор генерации, а не источник требований. Она может: 1. декомпозировать задачи 2. строить план 3. итерироваться 4. генерировать архитектурные варианты Но при всем вышеперечисленном она делает это внутри заданного контекста. ОЧЕВИДНО: если контекст плохой — результат масштабирует плохой контекст.

Где проходит граница

Даже самый продвинутый сетап (MCP + skills + multi-agent loop) не решает ключевые вопросы: – Кто зафиксировал требования? – Где описана модель домена? – Кто определил инварианты системы? – Где формализованы контракты? – Как валидируется корректность решений?

Да, агент может “придумать” архитектуру, но он не может гарантировать, что данная генерация: – соответствует бизнесу – покрывает все сценарии – не содержит критических допущений Выходит, что мы так или иначе приходим к выводу: "Без спецификации даже самый продвинутый сетап оптимизирует лишь гипотезу, а не реальность.

Почему это критично

Agent-driven разработка хорошо работает, когда: 1. есть чёткий spec 2. есть ограничения 3. есть критерии качества 4. есть критерии приемки 5. есть, в конце концов, ОБРАЗ РЕЗУЛЬТАТА

В этом случае AI-инструмент может существенно ускорить итерации разработки, помогает исследовать пространство решений (при этом порой даже снижает стоимость ошибок в рамках валидации гипотез). Но если этого нет — происходит другое: агент начинает “галлюцинировать архитектуру”, которая выглядит правдоподобно, но при этом не имеет инженерной основы. И чем мощнее инструмент — тем быстрее это масштабируется в сторону неконтролируемого технического долга и гигантского ТСО.

Возвращаясь к кейсу с IAM

Можно собрать multi-agent pipeline, который сгенерирует вам сервисы, продумает API и даже набросает RBAC (а если повезет даже замахнется на АВАС). Но без явной спецификации роли будут неполными, а edge-case’ы вы просто пропустите. Ваши security assumptions будут неправдоподобны, а интеграции хрупкие. И это всё не потому, что AI плохой. Все это может случиться потому, что система не была спроектирована — она была сгенерирована.

ИМХО - Реальное место AI и агентов AI + агенты — это сильнейший инструмент, если использовать его правильно: 💡 Spec → агент → реализация 💡 Spec → агент → проверка гипотез 💡 Spec → агент → ускорение SDLC

Но ни в коем случае : агент → “как-нибудь само сложится в систему”

Вывод Современные AI-инструменты действительно эволюционировали от вайб-кодинга из prompt’ов к мощным агентным системам с планированием и навыками (например GSD для Clauude Code). Но все это не отменяет базового факта: инженерия начинается не с генерации, а с формализации и если у вас нет спецификации — ни Claude, ни MCP, ни 100 агентов не превратят это в работающую систему… они просто помогут быстрее прийти к сложной, дорогой и плохо управляемой ошибке.

#ии #ai #нейросети #разработка #sdlc #архитектура #qa #mcp #