
Большие языковые модели уверенно пишут функции и отдельные файлы, но теряются, когда нужно собрать проект целиком. На длинной дистанции естественный язык становится ненадежным: расплывчатые формулировки, несовпадающие интерфейсы, утечки зависимостей, рассыпавшаяся структура. В итоге агент меняет решение по ходу работы, тесты плывут, а кодовая база превращается в набор фрагментов.
Идея: Repository Planning Graph
Исследователи предлагают заменить расплывчатые планы устойчивым графом. Repository Planning Graph (RPG) — это единое представление, где в узлах живут файлы, классы, функции; а рёбра фиксируют семантические связи, потоки данных и порядок реализации. Так в одном формате сходятся два мира: что строим и как именно это будет устроено в коде.

Как работает ZeroRepo
RPG — это не только идея, но и рабочий фреймворк ZeroRepo. Он собирает репозиторий в три шага:
1) Планирование на уровне возможностей: из короткой спецификации выбирается релевантное поддерево из огромного дерева фич (более 1.5 млн узлов). Здесь же происходит реорганизация: близкие функции объединяются в модули с хорошей связностью.
2) Планирование реализации: граф дополняется файловой структурой, интерфейсами, типизированными потоками данных. Появляется топологический порядок — что и в какой последовательности писать.
3) Генерация кода по графу: узел за узлом, с тестовой валидацией в стиле TDD. В репозиторий попадает только то, что прошло тесты.

Как их оценивали
Чтобы измерить качеств, авторы собрали RepoCraft — бенчмарк из шести реальных Python‑проектов (аналоги scikit‑learn, pandas, sympy, statsmodels, requests, django) и 1,052 задач. Требование жесткое: из минимального описания нужно построить весь репозиторий и пройти эталонные тесты. Меряют широту функционала (coverage), корректность (pass rate), масштаб кода и новизну.

Что получилось на практике
На RepoCraft ZeroRepo показывает заметный задел. В среднем генерируется около 36 тысяч строк кода — примерно в 3.9 раза больше, чем у сильного базлайна Claude Code, и в десятки раз больше, чем у остальных участников. Функциональное покрытие достигает 81.5%, а доля пройденных тестов — 69.7%. Это на 27.3 и 35.8 процентных пункта выше, чем у Claude Code соответственно. Важно и то, что RPG стабилизирует интерфейсы, помогает выдерживать границы модулей и согласовывать потоки данных.

Что нового показывает анализ
Почти линейное масштабирование. И по числу фич, и по строкам кода рост близок к линейному, пока есть бюджет на планирование. Языковые пайплайны без графа быстро выходят на плато.
Понимание репозитория агентом. По журналам локализации RPG сокращает шаги поиска и правок на 30–50%: есть где искать, какие зависимости трогать и что сломается при изменении.
Управляемая новизна. Система не просто копирует известные компоненты, а предлагает новые функции (11–13% новизны) без разрыва целостности архитектуры.
Разные модели — разные траектории. Qwen3‑Coder агрессивнее расширяет покрытие, o3‑mini сдержаннее и ровнее распределяет фичи по подграфам. Оба стратегически дополняют друг друга по оси полноты и точности.
Почему это важно
RPG превращает расплывчатый план в формальный артефакт, который одинаково понимают и LLM, и инженер. Он даёт предсказуемость: топологический порядок, стабильные интерфейсы, явные каналы данных. В такой среде легче масштабировать разработку, подключать новых агентов и людей, проводить целенаправленную отладку и интеграцию.
Но RPG не волшебная палочка: система сильно зависит от качества исходных спецификаций, тестов и покрытия доменных сценариев в глобальном дереве фич. В сложных экосистемах потребуется точная настройка под домен и аккуратная работа с инфраструктурными частями проекта. Но направление выглядит зрелым: графовые представления снимают главный барьер долгосрочного планирования.
***
Если вам интересна тема ИИ, подписывайтесь на мой Telegram‑канал — там я регулярно делюсь инсайтами по внедрению ИИ в бизнес, запуску ИИ-стартапов и объясняю, как работают все эти ИИ-чудеса.