Одна строчка в промпте: почему ИИ-агент срывает задачу

Агент не отказался работать – он вас послушался

Субботнее чтение в этом месяце у меня вышло специфическое: по сути, протокол вскрытия. Ребята из Faros.ai взяли шесть кодинг-агентов, прогнали по одинаковым 100 задачам из SWE-bench Pro и считали не «прошли тесты или нет», а по рубрике: 1858 проверяемых требований на каждую модель, 11 148 вердиктов, и к каждому провалу – записанная причина. Около 4000 провалов с объяснениями.

Потом объяснения сгруппировали. Самая толстая кучка на всех шести агентах – 247 случаев – звучит примерно так: агент прочитал инструкцию слишком буквально. И речь не про изощрённую формулировку из постановки. Речь про служебную строчку обвязки: «DO NOT MODIFY: Tests, configuration...». Тесты не трогать.

А задача при этом требовала тесты дописать.

Меня это развеселило и задело одновременно. Двадцать лет я слышу от тимлидов вариации на тему «хорошо бы исполнитель не додумывал, а делал ровно то, что написано». Вот, сбылось. Исполнитель делает ровно то, что написано, не устаёт и не спорит. Выяснилось только, что узким местом были не исполнители.

Джун в такой ситуации встаёт и идёт спрашивать: «Слушай, в шапке написано тесты не трогать, а в задаче – добавить проверку, как быть?» Он тратит ваши пятнадцать минут и спасает вам полдня. Агент не приходит. Он разрешает конфликт молча, выбирает формулировку покатегоричнее – ту, что написана капсом, – и сдаёт результат с уверенным отчётом о проделанной работе.

Что показало вскрытие: 4000 проваленных требований и один виноватый абзац

Ценность работы Faros не в цифре 247, а в методе. Обычный бенчмарк выдаёт на задачу один бит: прошло или нет. Из бита не узнать, агент не разобрался в предметной области, потерял контекст или честно выполнил противоречивое указание. Рубрика даёт вердикт по каждому требованию: те ли файлы тронуты, соблюдена ли спецификация, не ослаблены ли тесты, уцелело ли поведение.

Разложите причины по полочкам – и наверху окажется не «модель не осилила алгоритм». Наверху окажется коммуникация.

Рядом лежит ещё одна работа – анализ 20 574 реальных сессий работы с кодинг-агентами из 1639 репозиториев. Там смотрели на моменты, когда разработчик агента одёргивает. Две цифры оттуда я бы держал в голове: 90,5% таких эпизодов стоят команде не сломанного прода, а времени и доверия, и лишь в 9,33% случаев видно, что расхождение вообще разрешилось, причём почти всегда – после явного пинка от человека. Сам агент к вам не придёт.

Дело не в модели: почему апгрейд не лечит противоречивую постановку

Самое неудобное в разборе Faros: топовая причина провалов одинакова у самой слабой и у самой сильной модели в выборке. Умная модель просто исполняет ваше противоречие увереннее и аккуратнее.

Исследование обвязки агентов, вышедшее 17 сентября, подтверждает то же самое с инженерной стороны. Авторы зафиксировали цикл исполнения и крутили компоненты по отдельности: планирование, набор инструментов, управление контекстом. 176 сопоставимых конфигураций, четыре модели, SWE-Bench Verified и Terminal-Bench 2.1. Один результат отрезвляет особенно: преимущество управляемого контекста над неуправляемым на SWE-Bench падает с 35,7 процентных пункта при окне в 32k токенов до 2,7 пункта при 128k. Половина «магии промптинга» прошлого года, выходит, просто компенсировала тесное окно – и обесценилась сама собой, как только окна выросли.

Моя позиция: в 2026 году выбор модели для типовой разработки решает меньше, чем качество постановки и обвязки. Сначала вычитайте задачу, потом меняйте модель.

Когда я неправ: если у вас две-три задачи в квартал и всё делает один человек, у которого весь контекст в голове, никакие шаблоны не нужны. Противоречие он поймает сам за пять минут. Беда начинается ровно тогда, когда постановку пишет один, принимает второй, а исполняет третий – и третий не умеет переспрашивать.

Три фразы из наших шаблонов, которые агент понимает не так, как вы

Мы в CRT после этих разборов сели перечитывать собственные шаблоны постановки для агентных задач. Улов вышел неприятный.

«Не меняй существующее поведение». Человек читает это как «не ломай то, что к задаче не относится». Агент читает как «любой диф, меняющий наблюдаемое поведение, запрещён» – и выкручивает задачу так, чтобы формально ничего не поменялось.

«Минимальные изменения». Прекрасная фраза для ревью и ядовитая для постановки. Минимальные по строкам? По файлам? По риску? Агент оптимизирует то, что легче померить, – строки. И вместо нормального рефакторинга вы получаете заплатку в одну строку и вежливый комментарий, почему так можно.

«Не трогай тесты и конфиги». Классика, ровно как у Faros. Фраза родилась из здравого желания: чтобы исполнитель не подгонял зелёный прогон под свой код. Она же запрещает дописать тест на новое поведение.

Отдельно стоит «сделай по аналогии с соседним модулем». Человек имеет в виду стиль и структуру. Агент вполне может унаследовать заодно и багу из соседнего модуля – по аналогии же велели.

Что мы у себя выкинули из инструкций и что оставили

Первая попытка у нас была ленивая: сняли запрет на изменение тестов. Стало хуже. Агент полез в тесты там, где не просили, и пара прогонов позеленела не потому, что код починился. Тот самый размен, про который Faros писали в отчёте про рост объёма кода и рост дефектов заодно с ним.

Заработало разделение запрета по слоям. Существующие тесты, которые проверяют текущее поведение, менять нельзя – и написано именно так, а не «тесты не трогать». Новые тесты на изменённое поведение обязательны, они входят в определение готовности задачи. Конфиги окружения – отдельной строкой, потому что это про безопасность, а не про качество.

Второе, что оставили и убирать не собираемся, – человек, который перед запуском агента читает постановку глазами и ищет в ней взаимоисключающие требования. Скучно, ненаучно, работает. У нас это часть роли AI Software Engineer: один инженер ведёт задачу от формулировки до запуска и отвечает за неё целиком, в том числе за то, что агенту дали непротиворечивый текст. Логика та же, что в QA: поймать противоречие в требованиях дешевле, чем в релизе.

И третье, почти бытовое. Мы перестали копировать шапку промпта из проекта в проект. Именно унаследованный боилерплейт, который никто давно не перечитывает, и дал в исследовании самый жирный кластер провалов. Ваш собственный шаблон постановки – тоже легаси. И протухает он точно так же.

Вместо морали

Проверьте в понедельник одну вещь: откройте шаблон, из которого ваша команда копирует постановки для агентов, и найдите в нём фразу, которую никто не писал специально – она просто переехала из прошлого проекта. Скорее всего, она и есть ваш главный поставщик сорванных задач. А если хочется, чтобы за непротиворечивость постановки и за результат отвечал один человек, а не переписка в чате, – это наша роль AI Software Engineer.