Почему ваш AI-агент плодит хаос, а не код (и при чём тут фаза луны)
Когда я в очередной раз запустил оркестр агентов, чтобы быстро собрать клиентское приложение, главная боль заключалась не в том, что модель не умеет программировать. С этим LLM справляются давно. Настоящая проблема — архитектурный дрейф, который незаметно разъедает проект изнутри.
Машина воспринимает каждый диалог как изолированный фрагмент смысла. Ответ зависит от последовательности токенов, фазы луны, цвета клавиатуры и знака зодиака. Даже при низкой температуре одна и та же просьба может быть понята по-разному. Пока вы работаете в одном файле — мир прост. Но когда проект разрастается до пяти докеров в кластере, сотни роутингов, пятисот компонентов и трёх десятков таблиц, модель начинает теряться в хитросплетениях. Вам приходится следить за этим разнородным массивом: достаточно использовать синоним в промпте, и агент дорисует лишнюю страницу, модалку или целый дублирующий сервис — просто из желания угодить, даже если настроены линтинг, тесты и документация.
Именно это случилось в моём проекте. Я доверился LLM — и вместо 12 эндпоинтов получил сотню, вместо нескольких сущностей развелось 23, а на фронте нашлось 56 неиспользуемых компонентов. API-маршруты /me, /users/me, /api/v1/me вели к одному и тому же ресурсу; после миграции events → activities фронтенд догонял бэк четырьмя заплатками подряд. База данных обросла 27 миграционными файлами почти на 3000 строк, а таблицы вроде user_contents и event_attendees существовали только сами для себя. Дрейф проявлялся во всём: дублировались схемы, устаревала документация, а ручные fetch() обходили сгенерированный API-слой.
Я быстро понял, что это не единичный случай. По данным ряда исследований 2024–2026 годов, зависимость кода от формулировок оказывается критической. При семантически эквивалентных промптах структурно различный код генерируется в значительном проценте случаев. Если в запросе мелькают синонимы или несогласованные термины (скажем, «юзер», «клиент», «аккаунт» для одной сущности), вероятность разрастания системы кратно увеличивается.
Отдельный пласт — влияние «неинженерных» промптов. Когда в индустрию приходят люди без технического бэкграунда, пишут с ошибками или смешивают языки, модель начинает перестраховываться, что ведет к избыточности кода. Даже добавление вежливых оборотов, как показывают наблюдения, может увеличивать число создаваемых файлов — модель бессознательно воспроизводит паттерны развёрнутых ответов из обучающих данных.
Глобальная статистика (по данным сервисов мониторинга AI-кода) подтверждает масштаб: в проектах до 10 файлов дрейф составляет около 6%, на 50–100 файлах — уже 19%, а при >500 файлов 28–35% кодовой базы — это «дрейфовый шум». Причём 60% шума порождено всего 15% самых неоднозначных промптов. Разрыв между опытными разработчиками и новичками (14% против 29%) почти исчезает, если в проекте применяются строгие шаблоны запросов и автоматическая генерация из единой спецификации.
Вывод очевиден: дрейф — не персональная неаккуратность, а фундаментальное свойство стохастических моделей, помноженное на хаос человеческих формулировок. Единственный способ жить с этим — перестать надеяться на идеальные промпты и встроить автоматический контроль прямо в процесс разработки. О том, как я это сделал и что из этого вышло, — во второй части.
Когда я в очередной раз запустил оркестр агентов, чтобы быстро собрать клиентское приложение, главная боль заключалась не в том, что модель не умеет программировать. С этим LLM справляются давно. Настоящая проблема — архитектурный дрейф, который незаметно разъедает проект изнутри.
Машина воспринимает каждый диалог как изолированный фрагмент смысла. Ответ зависит от последовательности токенов, фазы луны, цвета клавиатуры и знака зодиака. Даже при низкой температуре одна и та же просьба может быть понята по-разному. Пока вы работаете в одном файле — мир прост. Но когда проект разрастается до пяти докеров в кластере, сотни роутингов, пятисот компонентов и трёх десятков таблиц, модель начинает теряться в хитросплетениях. Вам приходится следить за этим разнородным массивом: достаточно использовать синоним в промпте, и агент дорисует лишнюю страницу, модалку или целый дублирующий сервис — просто из желания угодить, даже если настроены линтинг, тесты и документация.
Именно это случилось в моём проекте. Я доверился LLM — и вместо 12 эндпоинтов получил сотню, вместо нескольких сущностей развелось 23, а на фронте нашлось 56 неиспользуемых компонентов. API-маршруты /me, /users/me, /api/v1/me вели к одному и тому же ресурсу; после миграции events → activities фронтенд догонял бэк четырьмя заплатками подряд. База данных обросла 27 миграционными файлами почти на 3000 строк, а таблицы вроде user_contents и event_attendees существовали только сами для себя. Дрейф проявлялся во всём: дублировались схемы, устаревала документация, а ручные fetch() обходили сгенерированный API-слой.
Я быстро понял, что это не единичный случай. По данным ряда исследований 2024–2026 годов, зависимость кода от формулировок оказывается критической. При семантически эквивалентных промптах структурно различный код генерируется в значительном проценте случаев. Если в запросе мелькают синонимы или несогласованные термины (скажем, «юзер», «клиент», «аккаунт» для одной сущности), вероятность разрастания системы кратно увеличивается.
Отдельный пласт — влияние «неинженерных» промптов. Когда в индустрию приходят люди без технического бэкграунда, пишут с ошибками или смешивают языки, модель начинает перестраховываться, что ведет к избыточности кода. Даже добавление вежливых оборотов, как показывают наблюдения, может увеличивать число создаваемых файлов — модель бессознательно воспроизводит паттерны развёрнутых ответов из обучающих данных.
Глобальная статистика (по данным сервисов мониторинга AI-кода) подтверждает масштаб: в проектах до 10 файлов дрейф составляет около 6%, на 50–100 файлах — уже 19%, а при >500 файлов 28–35% кодовой базы — это «дрейфовый шум». Причём 60% шума порождено всего 15% самых неоднозначных промптов. Разрыв между опытными разработчиками и новичками (14% против 29%) почти исчезает, если в проекте применяются строгие шаблоны запросов и автоматическая генерация из единой спецификации.
Вывод очевиден: дрейф — не персональная неаккуратность, а фундаментальное свойство стохастических моделей, помноженное на хаос человеческих формулировок. Единственный способ жить с этим — перестать надеяться на идеальные промпты и встроить автоматический контроль прямо в процесс разработки. О том, как я это сделал и что из этого вышло, — во второй части.