Может ли ИИ-агент работать без контекста всей кодовой базы?

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

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

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

Файл не равен единице поведения

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

За пределами мейнфреймов действует та же схема. Форма VB6 вызывает компонент COM, версию которого выбирает регистрация. Контроллер PHP подключает файл конфигурации, собранный скриптами развертывания. Программа RPG читает область данных и вызывает другую программу по имени из поля. Пакет PL/SQL зависит от триггера, который меняет строку после записи. Ни одна из этих зависимостей не обязана выглядеть как обычный импорт.

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

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

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

Места вызова скрываются за пределами графа импорта

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

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

Та же слепая зона принимает привычные формы:

• Планировщик вызывает shell-скрипт, который запускает программу под псевдонимом.
• Таблица базы данных сопоставляет коды транзакций с именами обработчиков.
• Механизм рефлексии загружает класс, имя которого задано в конфигурации.
• Макрос электронной таблицы вызывает метод COM через объект с поздним связыванием.
• Сгенерированный JCL подставляет имя процедуры только после символьной замены.

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

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

Даже простой поиск по репозиторию показывает, насколько быстро якобы изолированный символ выходит за пределы модуля:

rg -n -uu 'CALC-TAX|CALCTAX|calc_tax' .
rg -n -uu 'EXEC PGM=|CALL +[A-Z0-9-]+|CALLP|PROCEDURE DIVISION' .
rg -n -uu 'handler|program_name|transaction_code' config db jobs src

В реальном выводе есть пути и номера строк, например jobs/NIGHTTAX.jcl:18://STEP20 EXEC PGM=CALCTAX. Артефакт прост, но он заставляет проверяющего изучить вызовы за пределами открытого файла. Серьезный агент должен автоматически строить более подробную карту и хранить доказательства для каждого ребра.

Бизнес-правила перемещаются вместе с данными

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

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

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

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

Современный тип не обязательно правильнее старого представления. Перенести 9(7)V99 COMP-3 в десятичный тип можно, но только с сохранением масштаба, знака, округления, переполнения и реакции на неверный ввод. Замена шестизначной даты временной меткой может убрать неоднозначность в новой архитектуре и незаметно добавить правило выбора века, которого в исходной системе не было.

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

Ночное пакетное задание работает как другое приложение

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

Документация IBM по z/OS описывает JCL как место, где системе указывают, откуда взять входные данные, как их обработать и что сделать с результатом. Операторы DD связывают имена внутри программы с реальными наборами данных и задают, например, режим использования и формат записей. Это не оболочка приложения, а исполняемый контекст.

Представим изменение, которое добавляет новый статус в интерактивную функцию заказов. Путь запроса записывает H для отложенных заказов, показывает правильное сообщение и проходит проверку. Ночное задание расчетов читает тот же файл. Его первый шаг сортирует в расчетный вход только прежние статусы, а шаг обработки ошибок копирует все остальные во временный набор данных с DISP=(NEW,PASS). Следующий шаг запускается только при совпадении условия по коду возврата. Новый статус не попадает в расчет, оказывается во временном файле и исчезает после штатного завершения задания. Ни один исходный файл проверенного сервиса не показывает такой результат.

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

Для каждого задания по расписанию агент должен описать пять фактов:

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

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

Конфигурация исполняет правила

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

Конфигурация старой системы редко лежит в одном аккуратном каталоге. Ею может быть символьный параметр JCL, область данных IBM i, INI-файл рядом с настольным приложением, строка из формы Access, значение реестра, элемент среды или электронная таблица, скопированная в отслеживаемую папку. Одни значения хранятся в системе контроля версий. Другие поступают через средства развертывания или действия операторов. Агент должен найти и различить оба вида.

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

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

Для каждого значения, выбирающего поведение, агент должен ответить на четыре вопроса:

• Где определено значение и кто может его менять?
• Какой код его читает и когда происходит чтение?
• Какие значения встречались в реальных средах?
• Что происходит, если значение пустое, устаревшее, неизвестное или недоступное?

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

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

Сначала карта, потом патч

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

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

Для каждого предлагаемого изменения я использую компактную запись:

{
  "change": "add held order status H",
  "entry_points": ["POST /orders/{id}/hold", "NIGHTSET STEP20"],
  "writers": ["OrderStatus.bas", "HOLDORDR.cbl"],
  "readers": ["SETTLE.cbl", "RECON.sql"],
  "contracts": ["ORDER-REC copybook", "status_control table"],
  "unresolved": ["Does restart input retain H records?"],
  "required_evidence": ["online trace", "nightly replay", "reconciliation totals"]
}

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

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

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

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

Контексту нужны слои, а не один огромный запрос

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

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

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

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

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

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

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

Паритет проверяют на границе поведения

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

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

Случай проверки паритета должен содержать достаточно деталей для воспроизведения расхождения:

{
  "case_id": "nightly-held-order-restart",
  "entry_point": "NIGHTSET",
  "input_refs": ["orders.dat#sha256:...", "status_control#2026-08-01"],
  "source": {"rc": 4, "settled": 812, "held": 17, "control_total": "194033.22"},
  "target": {"rc": 0, "settled": 829, "held": 0, "control_total": "196801.04"},
  "comparison": "mismatch"
}

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

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

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

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

Проверяйте заявление о последствиях, а не только diff

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

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

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

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

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

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

Охват всей системы меняет экономику

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

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

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

По этому стандарту мы работаем, когда CodeHero за срок до 30 дней переписывает старые системы на Go, Rust, TypeScript и Postgres. Короткий срок убедителен только тогда, когда обнаружение, анализ нескольких языков и проверка паритета охватывают систему целиком, а не ждут, пока люди будут по одному передавать файлы.

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