Чтение всей кодовой базы за пределами окна контекста

Если модель принимает миллион строк, это еще не значит, что она понимает систему из миллиона строк. Вместимость показывает, помещается ли текст. Она не говорит, найдет ли модель нужное определение, свяжет ли косвенный вызов с побочным эффектом и заметит ли, что шаг JCL меняет смысл запущенной программы COBOL.

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

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

Окно контекста измеряет вместимость, а не понимание

Длинное окно контекста задает максимальный объем входных данных, которые модель примет при определенных условиях. Оно не обещает равномерного запоминания, устойчивого рассуждения по всему окну и правильной связи между далекими фактами. Это разные способности. Сводить их к одной метрике ошибочно.

Нельсон Лю и его соавторы наглядно показали проблему позиции в работе Lost in the Middle. В ответах по нескольким документам и при поиске пар ключ-значение результат часто был лучше, когда нужный материал стоял в начале или конце входа. Когда тот же материал перемещали в середину, результат ухудшался. Работа не доказывает, что любая современная модель ошибается на любой длинной программе. Она доказывает другое: успешная загрузка плохо предсказывает надежное использование данных.

Код сложнее обычного текста. В репозитории есть тысячи повторяющихся форм: геттеры, валидаторы, структуры записей, ветки ошибок, сгенерированные файлы и почти одинаковые пакетные шаги. Модели приходится различать похожие факты и следовать отношениям, которые никогда не стоят рядом в тексте. Абзацы CALCULATE-TAX и CALCULATE-TAX-OLD могут совпадать почти по всем токенам, но вызываться из разных мест. Сходство помогает найти оба. Оно не определяет, какой из них управляет транзакцией.

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

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

Еще один тест проверяет композицию. Спросите, откуда берется поле, где оно меняется и какой внешний эффект зависит от итогового значения. Затем задайте те же вопросы по отдельности и сравните собранный путь. Читатель, который отвечает на каждый локальный вопрос, но теряет идентичность по цепочке, умеет искать, но не понимает систему. Такой сбой легко пропустить, потому что каждый отдельный ответ выглядит правильным.

Поиск пропускает отношения без общего словаря

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

Представим правило начисления в COBOL. Видимый абзац читает класс счета и рассчитывает комиссию. В последний рабочий день шаг JCL выбирает другой входной набор данных. Copybook накладывает друг на друга два поля записи, а триггер PL/SQL отменяет комиссию для перенесенных счетов. Ни один из этих артефактов не обязан повторять формулировку тикета. Если получить только абзац, выйдет аккуратная и неверная функция TypeScript.

SWE-bench показал связанный факт в меньшем масштабе: реальные исправления часто требуют согласованных изменений в нескольких функциях, классах и файлах. В исходной постановке обычный поиск сравнивали с доступом к файлам, которые изменил человек. Это полезное предупреждение. Улучшенная генерация не восстановит доказательства, которых не передал поисковый этап, а при настоящей миграции заранее известного идеального списка файлов нет.

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

Читатель репозитория должен объединять несколько путей в одном хранилище доказательств:

• лексический поиск точных идентификаторов, литералов, имен записей и кодов ошибок;
• семантический поиск понятий, выраженных другими словами;
• разрешение символов и обход вызовов для явной структуры программы;
• ребра потоков данных и схем для значений, пересекающих границы процедур;
• трассы исполнения для динамического выбора, конфигурации и внешних эффектов.

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

Границы фрагментов создают еще одну скрытую потерю. Объявление процедуры может попасть в один фрагмент, а предусловие, обработчик ошибки или соседнее определение данных в другой. Большие фрагменты сохраняют больше локального контекста, но снижают точность и занимают больше промпта. Перекрытие копирует текст, но не восстанавливает структуру программы. Фрагменты по синтаксическому дереву улучшают компромисс, однако даже полная функция не покажет условие планировщика или эффект триггера в другом месте. После первого совпадения поиск должен расширять граф. Остановка должна зависеть от закрытых вопросов, а не от произвольного top-k.

Размывание внимания сохраняется в большом промпте

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

Распространенный совет предлагает положить весь репозиторий в промпт и попросить модель внимательно его изучить. Совет популярен, потому что убирает заметный компонент конвейера. Не нужно настраивать индекс и некого винить за плохой поиск. Простота только внешняя. Модель все равно выполняет отбор, но теперь внутри непрозрачного прохода. Там нельзя проверить пропущенных кандидатов или воспроизвести маршрут.

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

LongBench v2 включил понимание репозиториев в задачи с очень длинным входом и показал, что прямой ответ остается сложным. Интереснее методический вывод: дополнительное время на рассуждение и вычисления может быть не менее важным, чем заявленный размер входа. Архитектура миграции должна вынести промежуточную работу наружу. Один проход не должен одновременно изучать систему, выбирать целевую архитектуру, создавать код и подтверждать паритет.

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

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

До генерации репозиторию нужна типизированная карта

Анализ всей кодовой базы начинается с типизированного представления системы, по которому можно выполнять запросы. Плоский векторный индекс полезен внутри него, но не заменяет его. Долговечная единица представляет сущность с идентичностью, расположением, языком и ребрами к другим сущностям.

Как минимум карта должна описывать файлы, символы, точки входа, вызовы, чтение и запись, схемы, задания, экраны, тесты, ключи конфигурации и внешние интерфейсы. Ребрам нужны типы, поскольку calls, loads dynamically, writes field и runs after требуют разного рассуждения. У каждого ребра должны быть уверенность и происхождение. Ребро вызова от компилятора не должно выглядеть так же, как связь, предположенная моделью.

В унаследованных репозиториях границы языков входят в семантику. JCL выбирает программы и наборы данных. Карты CICS связывают экраны с полями. Программы RPG зависят от display files. Формы VB6 содержат привязки событий вне обычных процедур. Classic ASP смешивает разметку, скрипты, состояние сеанса и доступ к данным. Пакеты PL/SQL могут скрывать эффекты за триггерами и синонимами. Парсер основного языка видит только часть исполняемой системы.

Карта должна хранить отрицательные и нерешенные факты. Если цель динамического вызова нельзя определить статически, сохраните выражение и множество кандидатов вместо молчаливого выбора. Если два copybook-файла определяют запись с одним именем при разных настройках сборки, сохраните оба варианта и условие выбора. Неизвестное должно порождать запросы трассировки или случаи паритета, а не догадки в прозе.

Компактная запись доказательства может выглядеть так:

{
  "claim": "late fee is suppressed for migrated accounts",
  "path": ["BILLJOB", "FEE-CALC", "ACCT_FEE_TRIGGER"],
  "evidence": ["jobs/bill.jcl:88", "src/fee.cbl:412", "db/account.sql:219"],
  "conditions": ["RUN_MODE=MONTH_END", "account.migrated=true"],
  "unresolved": ["dynamic dataset alias at BILLIN"]
}

Эта запись не служит трюком для промпта. Это проверяемое утверждение, с которым может спорить следующий этап. Когда генерация меняет FEE-CALC, система находит затронутые точки входа, запрашивает нерешенную привязку набора данных и выбирает тесты для этого условия. Без карты каждый промпт заново открывает эти факты и каждый раз делает это по-разному.

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

Чтение всей кодовой базы требует этапов

Надежный читатель разделяет обнаружение, моделирование поведения, целевое проектирование, реализацию и проверку. Этапы могут повторяться, но каждый создает артефакты, ограничивающие следующий. Поэтому свободная генерация не сотрет ранее обнаруженную неопределенность.

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

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

Целевое проектирование затем решает, где это поведение должно находиться: в сервисах Go, ядрах Rust, клиентах TypeScript или Postgres. Здесь переписывание отличается от транслитерации. Преобразование каждого абзаца в функцию может сохранить поток управления вместе с глобальным состоянием, файловой связанностью и допущениями планировщика. Проект должен сохранять поведение на границе, но осознанно менять внутреннюю структуру.

Реализация получает ограниченные рабочие пакеты из карты. Пакет содержит целевое поведение, нужные исходные сущности, вышестоящие вызовы, последующие эффекты, ограничения, неизвестные и обязательные случаи паритета. Модель вправе запросить дополнительные доказательства. Она не должна заполнять отсутствующее ребро уверенной догадкой.

Проверка идет постоянно, а не после героического финального слияния. Сбои обновляют модель поведения или показывают дефект новой системы. Обратная связь нужна, поскольку анализ исходников не определит, была ли странная ветка мертвой, содержала ли нормативное исключение или достигалась только производственными данными.

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

Люди должны проверять те же артефакты. Инженерам нужно изучать спорное поведение и целевые контракты, а не просматривать тысячи сгенерированных строк в надежде заметить семантическое изменение. Этап готов двигаться дальше, когда утверждения подкреплены, за неизвестные назначены ответственные и обязательные проверки существуют. Одобрение гладкого текста к этому решению отношения не имеет.

Данные исполнения находят то, чего не видно статически

Статический анализ описывает возможное поведение. Записанное исполнение показывает, что действительно произошло при конкретных входах. Серьезному переписыванию нужны оба источника, потому что они закрывают слепые зоны друг друга.

Статический анализ перечислит ветки, которых нет ни в одной записи. Он найдет запись в пути ошибки, ежеквартальное пакетное задание или действие экрана, отсутствующее в свежем трафике. Трассы исполнения разрешают динамические вызовы, реальные значения конфигурации, псевдонимы наборов данных, SQL времени исполнения и порядок внешних эффектов. Ни один источник нельзя объявлять полной истиной.

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

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

case: invoice/month_end/migrated_account
old: status=200 body_sha256=7c... ledger_rows=0 notices=1
new: status=200 body_sha256=7c... ledger_rows=1 notices=1
verdict: FAIL side_effect.ledger_rows expected 0 got 1

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

Записанный трафик требует осторожности. Секреты и персональные данные нужно обрабатывать соответственно среде, а разрушительные эффекты при воспроизведении изолировать или виртуализировать. Нужен и перечень покрытия: какие точки входа, бизнес-периоды, классы ошибок и варианты конфигурации есть в корпусе? Миллион повторений успешного запроса не покрывает редкую процедуру закрытия.

Правила сравнения требуют такой же проверки, как захваченные входы. Временные метки, сгенерированные идентификаторы, неупорядоченные строки и зависящие от среды пути иногда нужно нормализовать, но каждое правило скрывает возможное различие. Храните правило как код, объясняйте его безопасность и проверяйте, что оно не маскирует значимое изменение. Если другая пакетная задача зависит от порядка старых записей, сортировка перед сравнением создаст ложный паритет.

Параллельному чтению нужно общее состояние

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

Параллельные исполнители должны брать явные области графа или вопросы. Один разрешает ребра от задания к программе, другой картирует эффекты базы данных, третий классифицирует внешние точки. Каждый пишет сущности, типизированные ребра, доказательства и конфликты в общее хранилище. Идентичность сущностей должна быть стабильной, чтобы CUSTOMER-REC в copybook и буфер, переданный через три программы, распознавались как одна структура при одном условии сборки.

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

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

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

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

Общее состояние не означает один огромный промпт для всех исполнителей. Это транзакционное хранилище доказательств со стабильными идентификаторами и проверкой версий. Исполнители обрабатывают ограниченные части и объединяют факты, только если ревизия источника еще совпадает. Такой подход избегает изолированных агентов, которые забывают друг друга, и глобального разговора, где уже непонятно, какое утверждение актуально.

Качество архитектуры и паритет требуют отдельных проверок

Переписанная система может совпасть по наблюдаемому поведению, но плохо воспроизвести старую архитектуру. Она может выглядеть современной и менять поведение на границах. Это отдельные проверки, и одна не должна компенсировать другую.

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

Демонстрации репозиториев часто стирают эту разницу. Синтаксически правильный Go, полученный из COBOL, демонстрирует перевод. Замена связанного с пакетами состояния на явные сервисы при сохранении поведения закрытия демонстрирует модернизацию. Для второго нужны карта репозитория, эксплуатационные ограничения и доказательства паритета. Одной генерации кода недостаточно.

Задайте критерии проверки до реализации. Для границы сервиса запишите разрешенных вызывающих, контракты запросов и ответов, владение транзакцией, поведение повторных попыток и случаи паритета. Для числового ядра Rust запишите области входов, округление, переполнение и эталонные векторы. Для клиента TypeScript укажите владельца валидации и серверные ограничения. Это инженерные решения, а не подробности из исходного фрагмента, случайно занявшего первое место.

Не принимайте фразу «модель видела весь репозиторий» как доказательство любой проверки. Требуйте путь от точки входа до измененного поведения, нерешенные ребра на нем, целевое решение вместо старой связанности и пройденные случаи воспроизведения. Без этих четырех элементов система выдала код без обоснованного описания исходной системы.

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

Проверяйте читателя изменением доказательств

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

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

Затем контролируемо изменяйте вход:

1. Переставьте файлы и результаты обхода графа, не меняя содержание.
2. Добавьте почти одинаковые мертвые реализации и устаревшие комментарии.
3. Переименуйте локальные идентификаторы, сохранив структуру и поведение.
4. Удалите необходимый артефакт и проверьте, сообщает ли система о неопределенности.
5. Добавьте трассу исполнения, противоречащую статической гипотезе.

Отдельно оценивайте полноту доказательств, правильность пути, работу с неопределенностью, сгенерированное изменение и результат паритета. Читатель, пришедший к верному ответу неверным путем, ненадежен. Система, которая отказывается от вывода после удаления доказательства, может быть лучше системы, сохранившей прежний ответ.

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

Приемочный вопрос состоит не в том, помещается ли миллион строк в одно обращение к модели. Нужно выяснить, способна ли система объяснить поведение, выдержать нерелевантный контекст, показать недостающие доказательства, создать осознанную целевую архитектуру и проверить новую реализацию против старой. Большее окно может помочь на отдельных этапах. Оно никогда не заменит окружающие механизмы.