DeepCode: как ИИ научился собирать репозиторий по статье

За последний год LLM-агенты для программирования действительно научились кое-чему новому: они теперь справляются с тестами, запуском команд и относительно длинными сценариями. Но как только вы усложните задачу, предлагая агенту «запилить репозиторий к статье», то быстро встретите суровую реальность. В статье много важных деталей, но они разбросаны по разделам, а итоговый проект — это десятки файлов, зависимостей, скриптов и мелких костылей, в то время как контекст LLM ограничен.

В статье DeepCode: Open Agentic Coding ученые предлагают рассматривать проблему по другому: как задачу по управлению информационным потоком. Если пропускная способность канала узкая (т.е. если контекст маленький), нельзя же вечно пихать туда и текст статьи, и историю переписки, и все, что было исписано ранее. В один прекрасный момент важные ограничения теряются (внутри шума) — агент начинает себе противоречить (интерфейсы не совпадают, входы в функции и команды разные, файлы считают то, чего уже нет в наличии, а пайплайны просто не запускаются).

Давайте тащить меньше и лучше управлять знаниями

DeepCode — самостоятельный фреймворк, делящий разработку на три крупные стадии, и внутри каждой делает так, чтобы выкроить побольше контекста без ущерба смыслу.

Система начинает с разбиения статьи в краткий, но формализованный саммери. Документ делится на куски по подзаголовкам и в дальнейшем не «скармливается всецело» LLM, а подгружается локально: например, когда нужно вспомнить элементы архитектуры, формулы, детализацию процесса обучения или оценки результатов. Внутри работают две роли: одна отвечает за сбор высокоуровневой информации (что вообще пытались повторить, на какие компоненты обращаем внимание), вторая — за вытягивание низкоуровневых деталей. Далее это соединяется и получается blueprint — конечный источник правды, с которым мы формируем то, что нужно.

Дальше начинается процесс генерации репозиториев, и тут авторы предпринимают довольно простое, но с другой стороны гениальное решение: вместо поддержки постоянно увеличивающегося промпта (в котором для написания каждой новой функции или файла ты просто таскаешь весь предыдущий код), они ведут Code Memory — некий слепок того, что есть в проекте. Это карточка с полями: назначение модуля, его интерфейс и связи с другими компонентами. Когда пишется очередной файл, агент подтягивает только релевантные записи памяти, а не использует километровый текст в промте.

CodeRAG. В реальности статьи зачастую не объясняют то, как правильно делать какой-то даталоадер, логирование, конфиги, запуск экспериментов, воспроизводимость, сохранение чекпоинтов и другие моменты. DeepCode может по необходимости подтягивать из сторонних репозиториев по мере релевантности известные патттерны, и использовать их в промпте если это помогает.

А затем, чтобы сделать репозиторий действительно рабочим, DeepCode запускает статический анализ, чтобы убедиться, что ничего не забыто и всё соответствует проекту. Он пытается запустить проект в "песочнице", после чего он продолжает устранять недочёты, которые возникают в ходе исполнения (зависимости, имена, аргументы запуска, несовпадающие входы/выходы и тд).

Как это работает: сравнение с агентами и людьми

Тестировалось всё это дело на PaperBench Code-Dev: 20 статей ICML, где нужно «с нуля» собрать репозиторий и скрипт воспроизведения.

Судя по описанию авторов, DeepCode набирает 73.5 ± 2.8 метрики replication score — это сильно лучше любых прошлых LLM–агентов (около 43 было в лучших предыдущих работах), и лучше узко заточенного на такую тематику пайплайна PaperCoder (около 51 там).

Cравнение с коммерческими агентами для кода на подмножестве из пяти статей: DeepCode в среднем 0.854, при том что Cursor и Claude Code около 0.58, а Codex вообще около 0.40.

Причём DeepCode использует ровно тот же модельный бэкенд, что и часть решений из сравнений, и значит прирост результата обусловлен именно архитектурой управления информацией, а не просто другой нейронкой.

А на маленьком подмножестве из трёх статей DeepCode в среднем даже (внезапно) превосходит группу экспертов уровня PhD (у экспертов — 72.4, а у DeepCode в среднем 75.9).

Что именно дало прирост: память, поиск кода и финальная проверка

Авторы доводят до нас идею, что дело именно в CodeMem: наивная стратегия «скользящего окна, когда старый контекст просто вытесняется, приводит к тому, что определения часто оказываются вытеснены раньше времени. Структурированная память сохраняет все интерфейсы, контракты и зависимости компактно, и за счет этого файлы более согласованы между собой.

С CodeRAG, ситуация еще интереснее: мы видим незначительное увеличение результата для сильных рассуждающих моделей и заметное увеличение у легких моделей. Добавление третьей финальной проверки модели дает еще несколько процентов. Именно эти последние проценты превращают почти работающий код в практически жизнеспособный проект.

Почему это важно для науки и разработки

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

Для науки это особенно важно, потому что воспроизводимость результатов — это не просто про удобство, а способ быстро проверить очередную идею учёного и дать ему фидбек. На перспективу неплохо бы иметь динамическое планирование, чтобы blueprint можно было обновлять в реальном времени, а не только на старте итераций.

📜 Полная статья

💾 Код

***

Если вам интересна тема ИИ, подписывайтесь на мой Telegram-канал — там я регулярно делюсь инсайтами по внедрению ИИ в бизнес, запуску ИИ-стартапов и объясняю, как работают все эти ИИ-чудеса.