Семнадцать тысяч строк и ощущение выполненной работы
Попросили agent Droid воссоздать GDAL с нуля — команду для обработки геоданных, над которой проект работает с 1998 года. Два миллиона строк C/C++ наверху, шестьсот тысяч достижимых через командную строку. Более двухсот форматов растра и вектора. Агент мог запускать референсную программу сколько угодно, но не мог заглядывать в её исходник.
Droid написал 17 000 строк C++. Воспроизвёл 36 процентов поведения. Код был крепкий, основные пути работали. Но большая часть программы отсутствовала.
Агент не исчерпал время. Не исчерпал бюджет. Он остановился, потому что, по его собственной оценке, он закончил.
Это, возможно, самая точная модель человеческого прокрастинатора, которую когда-либо создавали: делает работу до момента, когда лично тебе кажется, что хватит, и останавливается. Проблема в том, что «лично тебе кажется» и «работа сделана» — разные вещи. Для человека это отмазка. Для агента, обрабатывающего миллионы строк, это системная ошибка.
Стандарт завершения, написанный до начала работы
Factory Research проверили ту же задачу в другом режиме. Вместо одного агента — система с разделёнными ролями. Перед любой реализацией одна роль строит исполняемый стандарт завершения: собственный отчёт о том, что должна делать переделка и какие доказательства это подтвердят. Реализация затем проверяется против этого стандарта.
Этот запуск вырос до 115 000 строк и достиг 90 процентов поведенческого паритета с референсом.
Важная деталь: то, что получилось, — собственная программа агента. Она не напоминает оригинал ни формой, ни размером. Это не баг. Это то, что происходит, когда задача решается заново, а не копируется.
Результат не был исключением. На 24 задачах ProgramBench та же система подняла 7-Zip с 54 до 95 процентов, DuckDB — с 34 до 80, pandoc — с 39,5 до 84,2. Несколько воссозданий достигли верхних девяноста.
Почему агент бросает на полпути
Coding-агенты обычно проверяют свою работу по ходу дела. Реализуют кусок, пишут несколько проверок, смотрят на результат, решают — продолжать или нет. Для небольшой задачи это работает: задача, реализация и доказательство умещаются в один взгляд.
Крупные задачи приходится декомпозировать. По мере того как агент доходит до каждого куска, он также решает, какой объём доказательств считать достаточным. Эти проверки наследуют масштаб работы, которая их произвела. Они могут подтвердить всё, что агент догадался построить, но исключают функции, взаимодействия или ограничения, которые агент не представил.
Агент может делать последовательный, локально корректный прогресс и остановиться с отсутствующей большей частью результата. Проблема не в том, что он не мог реализовать остальное. Он никогда не составил полный учёт того, что осталось.
Формула, которую люди используют, но о которой забывают
Отделить требования от доказательств — не новость. Безопасно-критические проекты используют трассируемость требований и независимую верификацию. Стандартизирующие органы публикуют conformance-наборы. Продуктовые команды пишут приёмочные тесты.
Что необычно — это вести и поддерживать комплексный стандарт для каждого проекта. Большинство команд поэтому валидируют инкрементально и полагаются на review, продуктовый фидбэк и непрерывность людей, которые в курсе.
Агенты меняют обе стороны этого компромисса. Они могут производить работу быстрее, чем люди её проверяют, делая неформальный надзор bottleneck. Но ту же ёмкость можно применить к самому стандарту: инвентаризация результата, построение проверок, перезапуск их по мере изменения артефакта.
Результаты, которые стоит читать медленно
Factory Research привели конкретные цифры для GDAL в системном запуске: 115 000 строк против 17 000, 5 450 файловых правок против 603, 196,9 часов wall time против 15, 3 миллиарда кредитов против 216 миллионов.
Каждое число здесь — один запуск. Ничего не повторялось для усреднения.
На некоторых задачах разрыв ещё драматичнее: ffmpeg — с 10,7 до 40,3 процента, gromacs — с 15,1 до 30,6. Это не мелкий прирост. Это переход от «я слышал об этой функции» к «я реализовал эту функцию, вот доказательство».
Шесть ячеек в панели Fable — запуски Opus, заменяющие Fable, которые были заблокированы по соображениям безопасности. 141 из 144 ячеек оценены. Три системных запуска были прерваны и не получили оценку.
Что это значит для реальных задач
Одиночный агент не был лишён навыка. Ему не хватало стандарта завершения. Независимый стандарт, написанный той же моделью, довёл реализацию до гораздо более высокого поведенческого паритета с референсом.
ProgramBench придал этому стандарту конкретную форму: инвентарь и взвешенная выборка, восстановленная из black-box референса. Другие задачи рисуют свой стандарт из других источников. Продуктовая задача может опираться на утверждённые пользовательские флоу и дизайны. Миграция — на систему, которую заменяют.
Что обобщается на реальную работу, — это потребность во внешнем, исполняемом стандарте завершения. Выведенном из результата до того, как реализация сузит внимание. Обновляемом до тех пор, пока работа не встретит его.
Factory Research встраивают эту структуру в следующее поколение Missions.
Краткий ответ
Factory Research показала, что одиночный coding-агент останавливается при 36% поведенческого паритета на задаче воссоздания GDAL, потому что сам решает, когда работа закончена. Multi-role система с отдельной ролью, которая строит стандарт завершения до начала реализации, подняла паритет до 90% на GDAL, с 54 до 95% на 7-Zip, с 34 до 80% на DuckDB. Модель не меняется. Меняется наличие внешнего, исполняемого стандарта завершения, выведенного из результата до начала работы.