FeatureLoop — это тест, который проверяет не «решил ли агент задачу с первого раза», а сколько повторных указаний ему нужно, чтобы довести программу до рабочего состояния. Задача растёт по ступеням: сначала просьба, потом новые требования, потом жалобы «не работает». На каждой ступени проверяются и новое, и всё, что уже было сделано раньше.
Главная находка для практика: агент плохо чинит то, что сломалось, и забывает про старые требования. Вы пишете «коннектор остался на месте при перетаскивании», агент правит именно это. Симптом уходит, но рядом ломается другое, а раньше работавшая часть уезжает в тупик. Одна правка редко возвращает всё в рабочее состояние. И ещё: агент часто «проверяет» не то, что видит пользователь, а удобный внутренний кусок.
Исследователи прогнали 12 сильных моделей через три способа выдачи задачи: сразу всё ТЗ, требования по частям, требования по частям + отчёты об ошибках. Лучше всего оказался третий способ, а выдача всего ТЗ целиком — худший. При этом после жалобы на сбой полностью вылечивается лишь малая доля случаев.
Схема метода
ШАГ 1: Берут реальный репозиторий и цель разработки → разбивают на ступени (от 2 до 8)
ШАГ 2: Агент получает первую просьбу → делает реализацию в том же рабочем каталоге
ШАГ 3: Проверка тестами → если что-то не работает, агенту присылают жалобу (completion feedback)
ШАГ 4: Если всё работает, присылают следующее требование (evolution feedback)
ШАГ 5: После каждой ступени проверяют новое + все прежние требования + исходное поведение проекта
Три сценария выдачи одной и той же задачи: Full (всё сразу), Evo (по частям), Evo+Comp (по частям и с жалобами). Агента не обучали и не донастраивали, это способ измерить.
Пример применения
Сначала про границы. Бенчмарк не даёт готового промпта и не проверял никакой инструмент. Он показывает, как ведут себя агенты при долгой работе над одной программой. Выводы работают для долгих задач на несколько шагов; для разового скрипта на 20 строк они избыточны.
Задача: Вы дорабатываете Telegram-бота записи в салон красоты на Python (Claude Code). Вы просите: «Добавь выбор мастера». Потом: «Теперь учитывай график мастера». Потом: «Отмена записи освобождает слот». Бот падает на отмене. Вы пишете: «отмена не работает» — агент чинит отмену, а выбор мастера внезапно ломается.
Промпт (отчёт об ошибке, составленный с учётом находок статьи):
Отчёт об ошибке. Сценарий: клиент записывается к мастеру Анне на 15:00 и затем нажимает «Отменить запись».
Ожидаю: запись удаляется, слот 15:00 у Анны снова свободен.
Фактически: бот отвечает «Ошибка», слот остаётся занят.
Исправь и затем проверь ВСЮ накопленную функциональность через настоящий вход бота (обработчик сообщений), а не отдельные функции:
1. Выбор мастера.
2. График мастера.
3. Отмена записи.
Запусти каждый сценарий и покажи вывод. Если что-то из прежних пунктов сломалось из-за правки — исправь, повтори проверку и не заканчивай, пока все три не пройдут.
Результат: Агент исправит отмену, затем по очереди прогонит все три сценария и покажет вывод каждого. Если правка сломала прежнее поведение, он должен заметить это в своей проверке, а не оставить на пользователя.
Почему это работает
Слабость модели. Агент чинит то, на что указали, и считает работу законченной, когда симптом исчез. Он редко проверяет остальное сам. Часто проверка оказывается «параллельной»: вспомогательная функция работает, а настоящая точка входа осталась со старым поведением.
Сильная сторона. Если агенту чётко названы сценарий, ожидание и фактический результат, он находит и исправляет проблему. Он также неплохо выполняет требования, поданные порциями: новое поведение с первого раза реализуется в большинстве случаев.
Как это используют. Находки статьи подсказывают, где ставить подпорки: подавать требования порциями, формулировать жалобы как проверяемый сценарий, а условие завершения задавать как «все активные требования проходят», а не «исчез последний симптом». Прямо эта связка в статье не проверялась как приём, поэтому считай её рабочей гипотезой.
Рычаги управления: - Размер порции требований → меньше для запутанных проектов, чтобы агент не терял связи. - Условие остановки → «все прежние сценарии проходят» вместо «починено то, что я назвал». - Точка проверки → требуй запускать через публичный вход (бот, эндпоинт, интерфейс), а не через внутреннюю функцию. - Число попыток → после двух безуспешных правок остановись и начни разбор заново, а не давай ещё одну жалобу.
Шаблон промпта
В статье нет готового промпта. Ниже шаблон, собранный по её выводам (проверка всего накопленного, проверка через публичный вход), а не авторский метод.
Мы дорабатываем {проект} по шагам. Накопленные требования, которые должны работать всегда:
{список_прежних_требований}
Новая задача или жалоба:
- Сценарий: {что делаю}
- Ожидаю: {ожидаемый результат}
- Фактически: {что происходит}
Правила работы:
1. Сначала повтори проблему и покажи, что она воспроизводится.
2. Исправь причину, а не симптом.
3. Проверь не внутренние функции, а настоящий вход: {точка_входа}.
4. Прогони ВСЕ накопленные требования и покажи вывод по каждому.
5. Если что-то сломалось из-за правки, исправь и повтори пункт 4. Заверши только когда проходят все.
6. В конце перечисли: что исправлено, что проверено, что не удалось проверить.
Подставляй {проект}, {список_прежних_требований} (по одной строке на функцию), {точка_входа} (бот, URL, команда).
🚀 Быстрый старт — вставь в чат:
Вот шаблон для доработок через агента. Адаптируй под мой проект: [твой проект].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие функции уже должны работать и как запускать настоящий вход — потому что именно «весь накопленный список» и «публичная точка проверки» и защищают от поломки старого и от проверки не того. Она возьмёт структуру правил и подстроит под твой проект.
Ограничения
⚠️ Это измерение, а не лечение: статья не проверяла никакой промпт или инструкцию. Все выводы о том, как работать, — наши гипотезы по её данным.
⚠️ Один способ запуска: все модели работали через Claude Code, а жалобы формировал фиксированный генератор, не живой человек. Реальные жалобы бывают сумбурнее.
⚠️ Малая выборка задач: 61 задача из 34 репозиториев. Для каждой отдельной модели различия в пару задач могут быть шумом.
⚠️ Корректировок было не больше двух на ступень: что будет при трёх-четырёх, не знаем.
⚠️ Тесты измеряют заранее заданное поведение: если вы просите агента что-то, чего нет в таких тестах, результат может быть иным.
Как исследовали
Исследователи из Tencent и CUHK собрали 61 задачу из 34 открытых репозиториев на пяти языках (Go, Rust, JavaScript, TypeScript, Python). Каждую задачу взяли из реальных запросов пользователей и разложили на 2–8 ступеней. К каждой ступени написали проверки отдельно от эталонного решения, чтобы тесты не копировали готовый патч. Затем людей-проверяющих попросили прогнать задачи с четырьмя моделями и исправить недочёты.
Дальше 12 моделей запустили в трёх сценариях, всего 2196 прогонов. Результат: полная доля успеха — 40,3% при выдаче всего ТЗ сразу, 51,6% при выдаче по частям и 64,1% при выдаче по частям с жалобами. Лучшая модель довела до конца 72,1% задач.
Самое показательное: после первого провала в рабочее состояние в пределах двух правок возвращается лишь 15,4% сбойных состояний. Даже когда конкретная жалоба устранена, в 20,9% случаев остаётся нарушенным другое требование. А 11,4% уже работавшего позже ломается.
Разбор неудачных прогонов показал причину: в 75,3% случаев агент пропустил проверку на пути пользователя или проверил вспомогательный кусок вместо настоящего входа. На задачах, которые не решила ни одна модель, 32,4% ошибок — рассогласованное общее состояние (реестр, хранилище, обработчики жизненного цикла не сходятся). На задачах, которые хоть кто-то решил, таких всего 2,6%.
Удивило то, что итоговый балл скрывает разные стили работы: две модели с одинаковым результатом различаются тем, что одна чаще исправляет сломанное, а другая лучше сохраняет работающее.
Адаптации и экстраполяции
🔧 Техника: добавить в файл инструкций агента правило завершения → агент не бросает работу после первого прохождения
«Работа закончена только тогда, когда проходят все пункты списка требований, а не только последний. Если правка ломает прежний пункт — исправь».
🔧 Техника: отчёт об ошибке в три строки → меньше недопонимания
Каждый раз формулируй жалобу как «Сценарий / Ожидаю / Фактически». Статья показывает, что локальное исправление ещё не гарантирует полного, но ясный сценарий даёт агенту точку, которую он может проверить.
Экстраполяция: перед выдачей новой порции требований попроси агента перечислить все прежние требования и подтвердить, что они ещё проходят. Это дешёвая страховка от тихой поломки.
Ресурсы
FeatureLoop: Benchmarking Coding Agents under Evolving Requirements. Авторы: Jia Feng, Alyssa Wu, Cuiyun Gao, Yunlong Wang, Songyuanyi Lu, Zhichao Hu (Hunyuan Team, Tencent; Chinese University of Hong Kong). Использованная среда: Claude Code. Связанные бенчмарки: SWE-bench и его расширения.