AI-агенты в реальном проекте: почему промпта недостаточно и что должно быть
Что на самом деле изменилось в разговоре про AI в разработке
Последние полтора-два года вокруг AI-инструментов для программистов сформировалась устойчивая мантра: «AI написал мне функцию». Она работала как маркер прогресса — от удивления к хайпу, от хайпа к демо, от демо к слайдам на конференциях. Но в практической среде этот нарратив начинает трещать по швам.
Реальный переход, который фиксирует инженерное сообщество, выглядит иначе: от стадии «вау, AI написал мне функцию» к стадии «AI написал мне функцию… а теперь объясните, почему прод лёг». Это не обесценивание технологии, а признание того, что она начала доходить до настоящей инженерной эксплуатации.
На демо-уровне AI-агенты действительно демонстрируют впечатляющие результаты: понятная задача, чистый репозиторий, аккуратно подготовленный контекст, работающие тесты, корректно выданные права. Проблема в том, что это среда, созданная вместе с агентом и специально подготовленная под него. Как только агент попадает в обычный проект, условия резко меняются.
Как выглядит обычный проект для AI-агента
Разрыв между демо-средой и реальным проектом — это не просто разница в сложности кода. Это разница в типе хаоса, с которым сталкивается агент. Вот типичный портрет среды, в которой AI-агент оказывается после первого же онбординга:
- Документация устарела. README не обновлялся два года, архитектурные схемы не соответствуют реальному состоянию системы, а ключевые решения живут в чатах или презентациях.
- Бизнес-логика распределена по людям. Половина важных правил находится в голове у конкретного сотрудника. Формализовать их никто не удосужился, потому что «и так работает».
- Тесты существуют номинально. Часть тестов «временно отключена», часть нестабильна, часть покрывает только самые простые сценарии. Пайплайн не является надёжным критерием качества.
- CI/CD нестабелен. Сборки иногда красные по причинам, не связанным с изменениями в коде. Это создаёт фоновый шум, в котором агент не может отличить свою ошибку от системного сбоя.
- Стоимость токенов не моделировалась. Команда не понимала, во что обходится агентное взаимодействие, пока не получила первые счета. Оказалось, что цена контекста и повторных попыток — это не те же цифры, что при ручном использовании AI-чата.
В таких условиях интеллект агента перестаёт быть главным фактором успеха. На первый план выходит качество среды, в которой он работает, и способность команды формализовать то, что она пытается автоматизировать.
Почему вопрос «заменит ли AI разработчиков» стал неактуальным
Публичная дискуссия вокруг AI в инженерии долго вращалась вокруг бинарной оппозиции: либо замена, либо не замена. Этот вопрос удобен для заголовков и телевизионных дискуссий, но практически бесполезен для команды, которая пытается понять, что делать в ближайшие три-шесть месяцев.
Гораздо продуктивнее другой вопрос: какой станет разработка, если часть действий действительно можно отдавать агентам, но ответственность за систему останется у людей? Это смещение фокуса с технологии на организацию работы. Оно подразумевает, что:
- Агент — это не субститут инженера, а инструмент, требующий оператора с инженерной культурой.
- Автоматизация имеет смысл только там, где процесс хотя бы минимально формализован.
- Стоимость агентной работы — не только лицензия, но и стоимость токенов, время на ревью результата, стоимость ошибок в продакшене.
- Человек остаётся ответственным за архитектурные решения, качество данных и последствия деплоя.
Именно под этот сдвиг мышления в индустрии начинают формироваться прикладные конференции и профессиональные встречи, где фокус смещен с демок на реальный цикл разработки.
Что обсуждают на практике: темы, которые заменили демо-показы
Если присмотреться к программе профильных мероприятий вроде Agentic Dev Conf, которую 3 июля проводят в Москве организаторы HighLoad, становится заметно, что содержание разговора изменилось. Вместо «посмотрите, что умеет модель» выходит на первый план инженерная инфраструктура агентного процесса:
- Context engineering — как готовить, структурировать и ограничивать контекст, чтобы агент работал в реальном проекте, а не в стерильной песочнице.
- Ревью агентного кода — кто и как проверяет результат, какие практики ревью отличаются от ревью человеческого кода, где возникают слепые зоны.
- Тесты для агентных сценариев — как строить тестовую среду, которая реально ловит ошибки агента, а не просто существует для галочки.
- CI/CD с участием агентов — как встроить агентные шаги в пайплайн так, чтобы не превратить его в генератор нестабильных красных сборок.
- Стоимость токенов — как считать, моделировать и оптимизировать стоимость агентного взаимодействия, особенно в долгоживущих проектах.
- MCP и архитектура агентных систем — как подключать агентов к реальным инструментам, базам данных и сервисам без превращения системы в неподдерживаемый зоопарк.
- Сбои и изменение ролей инженеров — как перераспределяются обязанности в команде, где часть рутинных операций отдана агентам.
Состав экспертов, которые выступают с такими докладами, подтверждает прикладной характер обсуждения: это люди с реальным опытом внедрения, а не только исследователи или евангелисты.
Как подготовить проект к работе с AI-агентом: практический минимум
Прежде чем ожидать от AI-агента стабильного результата в реальном проекте, полезно проверить, готова ли среда. Ниже — компактная таблица, которая помогает быстро оценить разрыв между демо-условиями и реальностью.
| Аспект | Демо-среда | Типичный реальный проект | Что нужно сделать перед запуском агента |
|---|---|---|---|
| Документация | Актуальная, структурированная | Устаревшая, разрозненная | Обновить README, зафиксировать ключевые архитектурные решения |
| Бизнес-логика | Формализована в коде и тестах | Частично в головах у команды | Выделить критические правила, описать их в виде спецификаций или тестов |
| Тесты | Покрывают основные сценарии | Отключены, нестабильны, неинформативны | Восстановить зелёный пайплайн, добавить тесты на крайние случаи |
| CI/CD | Стабильный, предсказуемый | Нестабильный, шумный | Убрать флаки, настроить агентные шаги как отдельный слой |
| Стоимость токенов | Игнорируется или не моделируется | Не посчитана | Запустить пилот, собрать метрики, сравнить с ручной работой |
| Права и доступ | Выданы полностью | Ограничены, неформализованы | Определить минимально необходимый набор прав, оформить их явно |
Чек-лист: готов ли проект к запуску AI-агента
Если команда хочет понять, стоит ли сейчас вкладываться в агентную автоматизацию, можно использовать короткий список проверок:
- [ ] Есть актуальное описание архитектуры и ключевых ограничений системы.
- [ ] Критическая бизнес-логика зафиксирована в коде или тестах, а не только в памяти сотрудников.
- [ ] Пайплайн тестов стабильно зелёный и отражает реальное качество.
- [ ] Стоимость токенов и инфраструктуры оценена хотя бы грубо.
- [ ] Определены зоны ответственности: что агент может менять сам, а что требует ревью.
- [ ] Команда понимает, какие именно действия она пытается автоматизировать, и может объяснить их словами.
- [ ] Есть план отката или ручного вмешательства при сбоях агента.
Что делать дальше: от хайпа к инженерной культуре
Главный вывод, который можно извлечь из текущего состояния индустрии, прост: AI-агенты не работают в вакууме. Они эффективны только там, где команда уже занимается инженерной культурой — пусть бы минимальной. Формализация процессов, актуальная документация, стабильный CI, понятная стоимость — это не «зрелость процесса» ради сертификации, а необходимое условие для того, чтобы агент не стал генератором скрытых ошибок.
Если команда ещё не готова к этому, внедрение агента с высокой вероятностью превратится в дорогой эксперимент, который закончится возвратом к ручной работе и разочарованию. Если команда готова — агент становится ускорителем уже существующих практик, а не заменой им.
Поэтому следующий шаг — не выбор модели или платформы, а честная оценка готовности собственного проекта. И только после этого — пилот с метриками, ревью и ограниченной зоной ответственности.
