Acceptance criteria для ИИ-агентов: что значит «тикет готов для агента»

ИИ-агент останавливается в момент, когда считает задачу выполненной. Какую бы финишную черту ни задавал тикет, это и есть черта, которую агент пересечёт, не больше и не меньше. С человеком-инженером расплывчатый критерий как-то усваивается сам: он спросит в Slack, додумает по контексту, или просто знает, что для этой фичи значит «быстро». Агент так по умолчанию не делает. Любая слабина в формулировке не рассасывается сама, она встраивается в код.

Что показывают собственные данные Atlassian

Atlassian измерила это напрямую, а не просто заявила: 83% ИИ-нативных тикетов в их выборке получили оценку 4 балла и выше из 5 по готовности для агента, против всего 6% у тикетов, написанных по старинке. Обычные тикеты в среднем набирали 2,72 из 5, и типичный пример, по их же формулировке, это «однострочное резюме и ссылка». Самый широкий разрыв между двумя группами оказался именно в явных acceptance criteria, впереди границ скоупа, контекста и связей между задачами.

Формулировка Atlassian о том, что делает тикет хорошим, стоит того, чтобы её запомнить: «хорошо написанный тикет это и есть цикл выполнения агента». Не документация намерения для человека, который потом её интерпретирует. Спецификация, по которой агент работает напрямую.

Почему «быстро» и «аккуратно» не переживают встречу с агентом

У критерия, построенного на прилагательном, нет встроенной проверки. «Страница должна грузиться быстро» не даёт агенту условия pass/fail, которое можно сверить с собственным результатом, поэтому он либо угадывает порог, либо считает пункт выполненным, потому что никто не возразил. Починка механическая: заменить прилагательное на число, которое на самом деле имелось в виду. «Быстро» превращается в «рендерится меньше чем за 200 мс на p95». «Обрабатывает большие файлы» превращается в «обрабатывает CSV на 50 000 строк без таймаута». Число всегда было у кого-то в голове. Записать его, вот что делает критерий проверяемым кем-то ещё, кроме этого человека.

Формат Given/When/Then работает по той же причине, по которой он работает для QA-тестирования человеком: каждый критерий становится сценарием с наблюдаемым результатом, а не описанием ощущения, которое должна вызывать фича.

Провал, к которому агенты склонны, а люди в основном нет

Столкнувшись с неоднозначной спецификацией, человек-инженер по умолчанию обычно осторожничает: спросит или соберёт заведомо безопасную версию. Дефолт агента ближе к оптимизму: он строит happy path и считает задачу выполненной, потому что ничто в тикете не просило его подумать, что происходит при неправильном вводе, отказе сети или пустом списке. Тикету для агента нужен минимум один критерий про обработку ошибок и один про граничный случай, явно прописанный, а не подразумеваемый фразой «обрабатывать ошибки корректно». Подразумеваемое и есть ровно та часть, которая не переживает встречу с реальностью.

Где это связано с тем, что реально значит «готово»

Это практическая, тикет-уровневая версия различия, которое этот сайт в другом месте считает каноничным: заявление это то, что агент говорит, что сделал, доказательство это то, что позволяет кому-то ещё проверить, правда ли это. Проверяемый acceptance criterion это то, что вообще делает доказательство возможным. «Быстро» не с чем сверить, поэтому нет ничего, что можно приложить как доказательство, кроме слов самого агента. «Меньше 200 мс на p95, подтверждено нагрузочным тестом в CI» это конкретный артефакт, на который ревьюер или сам трекер может указать.

Чек-лист перед передачей тикета

• Каждый критерий это проверяемое условие, а не прилагательное. Если не можете сказать, что будет считаться провалом, значит критерий ещё не готов.
• Минимум один критерий покрывает ошибку и один граничный случай, прописанные явно, а не предполагаемые.
• Скоуп ограничен с обеих сторон: что входит и что явно не входит, чтобы агент незаметно не расширил задачу.
• Контекст, который человек достал бы из памяти (какой сервис это владеет, как выглядит существующий паттерн), записан, а не считается само собой разумеющимся.

Это не больше работы, чем написать хороший тикет для внимательного человека-подрядчика, который никогда раньше не работал с вашей командой. Это просто перестаёт быть опциональным в тот момент, когда читающий не может задать уточняющий вопрос в коридоре.