В пилотах с coding agents первый сбой часто не в модели. Агент уже умеет собрать diff, запустить тесты и написать аккуратное резюме. Сбой появляется позже, когда команда смотрит на результат и не может быстро понять, можно ли это принимать.

Проблема обычно не в скорости генерации. Проблема во входе.

Ticket рассчитан на человека, который живет внутри команды. Он помнит разговоры, знает ownership, держит в голове прошлые инциденты и неявные границы. Агент такого слоя не имеет. Если важный контекст не положили в задачу явно, он достраивает его сам.

На review такой PR быстро теряет аккуратный вид. Формально есть diff, тесты и описание, но дальше всплывает другое: изменение задело не тот слой, обошло security boundary, добавило абстракцию без владельца, не учло rollback или решило задачу так, что решение нельзя доказать.

Поэтому я бы менял не только инструмент, а саму единицу работы.

Вместо ticket нужен intent. Он фиксирует, зачем задача существует, какой outcome нужен, что нельзя менять, какие риски важны, какие проверки обязательны и где агент должен остановиться.

К intent добавляется context pack: релевантные файлы, прошлые решения, контракты, примеры поведения, тестовые ожидания, ограничения доступа и definition of done. Это не документация ради документации. Это рабочая поверхность, без которой агент начинает гадать.

Сам запуск тоже должен быть оформлен как run. Отдельная ветка или sandbox, ограниченные инструменты, запрет на секреты и production, понятный лимит итераций, журнал действий. Доверие без границ превращает review в расследование.

После run нужен evidence bundle. Человек должен видеть не только diff, но и причины выбранного подхода, assumptions, добавленные тесты, пройденные проверки, непроверенные зоны, остаточный риск и способ отката.

Review при этом не исчезает. Он становится более явным. Человек меньше выполняет механические шаги руками, но сильнее отвечает за решения: принять ли intent, согласиться ли с trade-off, дать ли security exception, делать ли merge и release.

Слабый ticket с агентом не становится сильнее. Он просто быстрее превращается в сомнительный diff.

Если нет тестов, агент быстрее создает изменения, которые нельзя доказать. Если нет правил доступа, он расширяет риск. Если нет ownership, команда получает больше PR, но не больше ответственности.

Поэтому внедрение агентов стоит начинать не с выбора IDE. Практичнее взять несколько повторяемых классов работы: bug fix, небольшая feature, test coverage, refactor, dependency update, incident follow-up, onboarding в незнакомый код. Для каждого класса отдельно определить, где помогает human-led AI-assisted режим, где достаточно agent-drafted human-approved, а где можно дать agent run в sandbox.

После нескольких таких запусков становится видно, где агент реально полезен, а где команда пока не готова. Иногда первый шаг - не coding agent, а нормальный context pack. Иногда - генерация тестов и evidence bundle. Иногда - codebase onboarding. Иногда честный вывод проще: рано, потому что нет branch protection, ownership, тестов или правил работы с данными.

AI-native development для меня не про то, что разработчики чаще используют AI. Это процесс, где работа заранее проектируется для связки человек, агент, инструменты, проверки и память системы.

Старые ticket, PR и review остаются. Но в прежнем виде они слишком слабо описывают работу, которую дол жен безопасно выполнять агент.