Тезис для команды: AI-агент может закрывать рутинные части разработки, но не заменяет владельца задачи. Он не знает скрытых договоренностей, политических ограничений продукта, истории инцидентов и того, какие компромиссы уже запрещены командой. Поэтому вопрос не в том, можно ли дать агенту задачу. Вопрос в том, какие границы, тесты, права доступа и ревью нужны, чтобы результат не стал красивой, но ненадежной автоматизацией.
Почему кейсы про замену джуна быстро ломаются
Популярная история на vc.ru ценна не тем, что доказывает победу человека или машины. Она показывает типовой цикл завышенных ожиданий: агент быстро делает видимую часть работы, команда радуется скорости, а затем всплывают края - контекст, качество, поддержка, согласование, тесты, ответственность за баги. Джун в хорошей команде не просто печатает код. Он учится правилам продукта, задает неудобные вопросы, получает обратную связь и постепенно превращается в носителя контекста.
AI-агент контекст не выращивает сам. Его нужно кормить задачей, репозиторием, ограничениями, политиками безопасности и критериями приемки. Если этого нет, агент оптимизирует под ближайший ответ. Он может выбрать устаревшую библиотеку, проигнорировать миграцию, изменить публичный контракт или написать тест, который проверяет реализацию вместо поведения. Скорость при этом будет реальной, но экономия окажется мнимой.
Риск-менеджмент вместо восторга
NIST AI RMF предлагает смотреть на AI-системы через управление рисками, доверие и оценку воздействия. Для разработки это переводится в простые инженерные вопросы: где агент может менять код, какие секреты он видит, какие команды ему разрешены, как проверяется результат, кто принимает решение о merge. Чем ближе агент к продакшену, тем меньше должно быть неявных прав и тем больше нужна трассировка действий.
| Зона | Риск | Контроль |
|---|---|---|
| Права доступа | Агент видит секреты или меняет не тот модуль. | Изолированная среда, минимум токенов, ограниченный write scope. |
| Требования | Задача решена формально, но не продуктово. | Критерии приемки и запрет на скрытые изменения контрактов. |
| Код | Патч компилируется, но ломает поведение. | Тесты поведения, code review, ручной просмотр миграций. |
| Документация | Результат невозможно сопровождать. | Краткая запись причин решений и известных ограничений. |
Где агент действительно полезен
Сильные сценарии начинаются там, где задача хорошо ограничена: обновить однотипные тесты, найти повторяющийся паттерн, подготовить миграцию по заданной схеме, собрать список мест использования, написать черновик документации по уже принятому решению. Агент хорош как ускоритель, когда команда знает, что считает правильным результатом. Он слаб как автономный владелец неопределенности, если никто не сформулировал цель и риски.
- Давайте агенту маленький участок ответственности, а не весь продуктовый эпик.
- Перед запуском фиксируйте, какие файлы можно менять и какие нельзя.
- Требуйте тесты к изменению, но проверяйте, что тесты не повторяют ошибочную реализацию.
- Не принимайте патч без человека, который понимает доменную цель.
Как оценивать результат
Метрика «агент написал код быстрее» недостаточна. Нужны другие вопросы: сократилось ли время до проверенного merge, стало ли меньше дефектов, понятно ли сопровождать решение через месяц, не вырос ли риск доступа к данным. Если агент ускоряет черновик, но ревью занимает вдвое больше времени, процесс не стал лучше. Если агент берет рутину, а разработчик тратит время на архитектуру и проверку, инструмент начинает приносить реальную пользу.
Когда агенту нельзя давать автономность
Есть зоны, где автономность должна быть минимальной: платежи, персональные данные, миграции базы, права доступа, удаление файлов, безопасность, юридические тексты и изменения, влияющие на публичные договоры с пользователем. В таких задачах агент может подготовить черновик или список проверок, но не должен самостоятельно принимать финальное решение. Чем выше цена ошибки, тем важнее разделить генерацию варианта и утверждение результата.
Отдельный риск - убедительный стиль. Агент может объяснить патч так, будто учел все ограничения, хотя на деле он не видел часть контекста. Поэтому ревью должно проверять не только diff, но и предпосылки: откуда взялось решение, какие альтернативы отброшены, какие тесты доказывают поведение, нет ли скрытого изменения данных. Если команда принимает ответы агента как отчет эксперта, она переносит ответственность на инструмент, который ответственности не несет.
Полезный формат внедрения - журнал агентных задач. В нем фиксируются цель, разрешенные файлы, источники контекста, команды проверки, найденные риски и человек, который принял результат. Такой журнал не бюрократия ради бюрократии. Он помогает через месяц понять, почему решение появилось, какие ограничения были известны и где нужно быть осторожнее при следующем изменении.
Редакционный вывод Postered: AI-агенты должны входить в разработку как инструмент с журналом, правами и контрольными точками, а не как замена инженерной ответственности. Команда выигрывает не тогда, когда человек исчезает из процесса, а когда человек перестает делать механическую работу и лучше контролирует смысл результата.
Комментарии
Загружаем обсуждение.