Слабый ticket в обычной команде еще как-то выживает.

Разработчик приносит в него память команды: обсуждение в Slack, старый PR, знание модуля с правами доступа или биллингом, привычки ревьюера, имя человека, который точно будет против. Ticket может быть неполным, но человек часто достраивает его из окружающего слоя.

Агент этого слоя не несет.

Он берет ticket буквально, заполняет пустоты уверенным кодом и приносит чистый diff. На ревью это быстро перестает выглядеть аккуратно: не тот слой, забытая проверка прав, неочевидный владелец, нет пути отката, тесты проверяют успешный сценарий, а не реальный риск.

Поэтому первый AI-native процесс я бы строил не вокруг IDE и не вокруг выбора модели.

Я бы начал с точки передачи работы:

ticket -> intent -> context pack

Ticket говорит: “сделать CSV export”.

Intent отвечает на другие вопросы:

- зачем это изменение; - что должно измениться; - что нельзя трогать; - какой риск; - как проверяем; - кто принимает решение.

Context pack добавляет то, что раньше жило в голове разработчика:

- relevant files; - existing patterns; - contracts; - non-goals; - test command; - permission boundary; - acceptance rubric.

Это выглядит скучнее, чем показ агента, который сам собирает изменение.

Но именно здесь ломается большая часть агентной работы. Агент редко проваливается потому, что не умеет печатать код. Чаще он проваливается потому, что получил слабый интерфейс на входе и начал угадывать.

Старый Definition of Ready говорит:

- задача описана; - acceptance criteria есть; - приоритет понятен.

Для агентного процесса этого мало.

Новый DoR должен спрашивать:

- intent понятен? - контекст собран? - non-goals названы? - risk class назначен? - verification path известен? - permission profile задан? -human approver есть?

Такой пакет работает как защита от быстрой генерации неправильной работы.

Если команда хочет понять, с чего начинать внедрение AI, я бы не начинал с автономной реализации фич агентом. Я бы взял один повторяемый класс задач и проверил, как меняется работа, когда перед написанием кода появляется короткий intent и context pack.

Измерять можно простые вещи:

- сколько уточняющих вопросов после старта; - сколько rework из-за неверно понятой задачи; - сколько review ушло на восстановление контекста; - какие проверки пришлось добавить; - где агент начал гадать.

Только после этого имеет смысл расширять полномочия агента.

Сначала делаем работу готовой для агента.

Потом даем агентам больше прав.

Не наоборот.