TL;DR
Исследование FeatureArc проверяет, что происходит, когда агент-программист наращивает одну функцию по этапам: «сделай запись на урок», потом «добавь оплату», потом «добавь переносы». Каждое новое ТЗ ложится на код, который агент написал сам. Между этапами никто не говорит ему, прошёл ли предыдущий этап. Метод в статье один: скрытые проверки после каждого этапа плюс итоговая проверка всей функции. Агент об этих проверках ничего не знает.
Главная находка: ранняя ошибка остаётся в коде и тянет за собой следующие этапы. Первый этап проходит примерно 63% агентов, а функция целиком работает у 28%. После проваленного этапа следующий проходит лишь в 23% случаев, после успешного — в 70%. При этом старый код ломается редко (3% случаев). Проблема в другом: в 95% случаев агент не замечает, что предыдущий этап был сделан неверно. Его самопроверки смотрят на текущий этап и почти не возвращаются назад.
Из этого следует правило: не отдавай агенту цепочку расширений вслепую. Нужна контрольная точка между этапами: человек или сам агент по явной команде перепроверяет прошлые требования. Авторы эту меру отдельно не проверяли, это вывод из их данных.
Схема метода
Так устроен тест у авторов:
ШАГ 1: Агент получает код и ТЗ этапа 1 → пишет реализацию
КОНТРОЛЬ: скрытые тесты проверяют (а) новое поведение, (б) что старое не сломано
→ агенту результат НЕ сообщают, откат НЕ делают
ШАГ 2: Агент получает ТЗ этапа 2 → строит поверх СВОЕГО кода (та же сессия)
КОНТРОЛЬ: те же проверки
...
ШАГ N: последний этап
ИТОГ: проверка всей функции целиком на финальном коде
Уровни делегирования, которые вводят авторы:
L1: пользователь говорит агенту, КАК исправить провалившийся этап
L2: пользователь указывает, КАКОЕ поведение не работает
L3: пользователь говорит только «прошёл / не прошёл»
L4: пользователь молчит о прошлых этапах и даёт только следующее ТЗ ← тестировали это
Пример применения
Метод авторов — бенчмарк, готовых промптов в статье нет. Ниже практическое применение вывода, достроенное по результатам, а не авторская техника.
Задача: Вы делаете в Claude Code телеграм-бота для онлайн-школы английского. Этап 1 — запись на урок. Этап 2 — оплата через ЮKassa. Этап 3 — напоминания и перенос урока. Раньше вы кидали три ТЗ подряд и в конце находили, что запись уже не учитывает оплату, а перенос создаёт дубли.
Промпт (перед каждым новым этапом, начиная со второго):
Перед этапом 2 («Оплата через ЮKassa») остановись и проверь этап 1.
1. Выпиши все критерии приёмки этапа 1 из моего ТЗ списком.
2. Для КАЖДОГО критерия запусти проверку (тест или ручной прогон) и покажи вывод команды.
Не пиши «должно работать». Только фактический результат.
3. Если хотя бы один критерий не выполнен — исправь, перезапусти проверку
и покажи, что теперь проходит. К этапу 2 не переходи.
4. Если всё выполнено — напиши «Этап 1: все критерии подтверждены»
и приступай к этапу 2.
После этапа 2 запусти проверки этапов 1 и 2 вместе. Это нужно,
чтобы оплата не сломала запись на урок.
Результат: Модель сначала перечислит критерии прошлого этапа. Затем покажет вывод проверок по каждому критерию. Если что-то не сходится, она исправит это до начала нового этапа. Только после этого перейдёт к оплате. В конце этапа вы получите общий прогон старых и новых проверок.
Почему это работает
Слабость LLM. Агент оценивает свою работу по тому, что проверяет сам. А проверяет он в основном текущую задачу. После провала этапа он почти никогда не возвращается к нему, потому что в его картине мира всё «зелёное». Новый этап строится на кривом фундаменте, и ошибка растёт: в большинстве проваленных поздних этапов (73%) виноват дефект, унаследованный от раньше.
Сильная сторона. Агент хорошо выполняет прямую конкретную команду: «выпиши критерии, запусти проверку, покажи вывод». Он умеет читать собственный код и гонять тесты. Не хватает ему не умения, а привычки возвращаться назад без запроса.
Как это использует контрольная точка. Вы превращаете «агент сам догадается проверить прошлое» в обязательный шаг в инструкции. Рычаги управления: - Глубина проверки. «Только прошлый этап» дешевле, «все этапы с первого» надёжнее при длинных цепочках. - Требование доказательства. «Покажи вывод команды» убирает фразу «вроде всё работает». - Критерии из ТЗ. Пусть агент выписывает их дословно. Авторы видели, что зелёные самотесты часто проверяют не то, что требовалось. - Кто проверяет. Это может быть сам агент, второй агент в новой сессии (свежий взгляд) или вы руками.
Шаблон промпта
Это шаблон на основе выводов статьи, а не авторский:
Мы наращиваем функцию «{функция}» по этапам. Сейчас переходим к этапу {номер}: «{название_этапа}».
<ПЕРЕД_НАЧАЛОМ>
1. Выпиши критерии приёмки всех завершённых этапов ({список_этапов}) списком.
2. Для каждого критерия запусти проверку и покажи фактический вывод.
3. Если критерий не выполнен: исправь, перезапусти, покажи результат.
К новому этапу не переходи, пока всё не подтверждено.
<НОВЫЙ_ЭТАП>
{ТЗ_этапа}
Интерфейсы, имена и сообщения об ошибках: {контракт}
<ПОСЛЕ_ЭТАПА>
Запусти проверки нового этапа И всех прошлых вместе.
Отчитайся таблицей: этап — критерий — результат.
Если что-то из прошлого сломалось, исправь до сдачи.
Что подставлять: {функция} — что наращиваете, {список_этапов} — этапы, уже сделанные, {ТЗ_этапа} — ваше описание поведения и критериев, {контракт} — названия функций, поля, тексты ошибок, чтобы проверки не гадали.
🚀 Быстрый старт — вставь в чат с агентом:
Вот шаблон контрольной точки между этапами. Адаптируй под мой проект: {опиши проект и этапы}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
Модель спросит, как запускать тесты в проекте, какие этапы уже сделаны и какие у них критерии приёмки. Эти данные нужны, чтобы проверка шла по вашим требованиям, а не по тому, что агент сам решил проверить.
Ограничения
⚠️ Это бенчмарк, а не проверенный приём: авторы измерили, как агенты проваливаются без обратной связи. Промежуточные проверки или промпты вроде нашего они не тестировали. Мера выведена из данных, не доказана экспериментом.
⚠️ Агент проверяет не то: авторы отдельно разбирали случаи, когда самотесты агента зелёные, а скрытые тесты падают. Агент мог выбрать неверные ожидания. Поэтому команда «запусти проверки» не гарантирует правильность. Критерии должны быть явно записаны в вашем ТЗ.
⚠️ Результаты зависят от связки модель + обвязка: сравнивали готовых агентов целиком, вклад модели и инструмента не разделён.
⚠️ Тест жёсткий: без обратной связи, без отката, одна сессия. В реальной работе вы обычно что-то проверяете, так что 28% — это нижняя граница, а не прогноз.
⚠️ Только код: вывод про многоэтапную разработку. Переносить на тексты или анализ данных можно по аналогии, но в статье этого нет.
⚠️ Текст статьи обрезан: подробные результаты по отдельным моделям и разбор причин в предоставленном фрагменте отсутствуют. Выводы опираются на аннотацию и введение.
Как исследовали
Идея была простой: настоящая функция растёт по частям, значит, тест должен быть таким же. Команда Tencent взяла истории реальных репозиториев (Python, TypeScript, Rust, Go) и вытащила из них цепочки коммитов, которые последовательно расширяют одну и ту же функцию. Для каждого этапа LLM-агенты написали ТЗ и контракт интерфейса, а старые тесты разделили на два вида. Первые проверяют новое поведение, вторые — что старое не сломано. После отбора и ручной проверки осталось 73 задачи, 263 этапа, 53 репозитория, от 2 до 10 этапов в цепочке.
Десять кодинг-агентов работали в одной сессии. Скрытые тесты запускались после каждого этапа, но агент про результаты не знал. Откатов не было, и бюджет составлял четыре часа на этап.
Удивило то, что новый код почти не ломает старый (3,3%). Главная беда не регрессии, а необнаруженные дефекты: после провала агент в 95% случаев не замечает ошибку. Даже лучший агент, проходящий первые этапы в 84% случаев, собирает целую функцию только в 49%. Для практики из этого следует: успех на одном этапе ничего не говорит о состоянии всей функции.
Траектории агентов разметили три LLM-судьи по общему кодбуку. Решение принималось большинством, спорные случаи разбирал первый автор. Свою разметку на выборке он проверял вслепую, совпадение с судьями было 89–100%.
Адаптации и экстраполяции
🔧 Техника: независимый проверяющий → свежий взгляд на старые этапы
Вместо самопроверки запускай ревью в новой сессии:
Ты принимаешь работу другого разработчика. Ниже ТЗ этапов 1–2 и код.
Не доверяй его заверениям. Для каждого критерия приёмки найди подтверждение в коде
или запусти проверку. Верни список: критерий — подтверждено / не подтверждено — чем.
Эффект: у проверяющего нет привычки «всё и так работает». Эту гипотезу статья не проверяла.
Экстраполяция: правило в CLAUDE.md / AGENTS.md
## Правила работы по этапам
- Прежде чем начать новый этап, перечисли критерии приёмки всех прошлых
и подтверди каждый запуском проверки с выводом в ответе.
- Не пиши «проверил», если не запускал команду.
- Если прошлый этап не проходит, чини его до начала нового.
- Финиш этапа = прогон новых и старых тестов вместе.
Так проверка встроена в постоянные инструкции и не зависит от того, вспомните ли вы напомнить.
Ресурсы
- FeatureArc: Benchmarking Coding Agents on Evolving Features — Yunlong Wang, Alyssa Wu, Cuiyun Gao, Jia Feng, Songyuanyi Lu, Zhichao Hu
- Hunyuan Team, Tencent; The Chinese University of Hong Kong
- Упомянутые инструменты: Claude Code (code.claude.com/docs/en/overview), Codex CLI (github.com/openai/codex)