Как инструменты ИИ для программирования меняют чужой код

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

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

Как автодополнение предсказывает ближайшее локальное изменение

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

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

Language Server Protocol проводит здесь полезную границу. Запрос на дополнение содержит позицию в документе, а также может содержать символ или тип запуска. Протокол не задаёт миссию вроде «замени этот слой хранения» и не описывает цикл проверки, который докажет корректность замены. Продукт может дополнить подсказку индексированными фрагментами репозитория, но взаимодействие всё равно заканчивается предложением. Более широкий поиск улучшает догадку, но не превращает её в расследование.

Автодополнение перестаёт помогать, когда правильность зависит от фактов за пределами переданного окружения. Абзац COBOL может менять поле, формат которого задан в copybook, а JCL в конце месяца выбирает другой набор входных данных. Обработчик события VB6 может казаться неиспользуемым, пока файл формы не привяжет его по имени. Процедура PL/SQL может зависеть от переменной пакета, которую инициализировал прежний вызов. У пропущенного факта часто допустимый синтаксис, и в месте правки нет видимой подсказки о его существовании.

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

Как ассистент работает в переданном диалоге

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

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

Границу легко пропустить, потому что чат уверенно рассуждает о файлах, которые никогда не открывал. Если ассистент говорит: «Эту функцию вызывает только пакетный импортёр», утверждение может быть выводом из вставленного фрагмента, а не результатом поиска по репозиторию. Спросите, что именно он проверил. Надёжный ответ назовёт места вызова, конфигурацию, сгенерированные привязки или данные выполнения, на которых основан вывод. Если таких сведений нет, считайте утверждение гипотезой.

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

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

Как агент меняет репозиторий в цикле действий

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

Цикл важнее окна чата. Полезный агент действует примерно так:

1. Определяет состояние репозитория и применимые инструкции.
2. Ищет определения, места вызова, конфигурацию, тесты и сгенерированные связи.
3. Вносит ограниченное изменение в отдельной ветке или изолированном worktree.
4. Запускает проверки, способные опровергнуть изменение.
5. Изучает diff и сообщает об оставшейся неопределённости.

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

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

Условие остановки тоже требует проверки. Фраза «тесты прошли» достаточна лишь тогда, когда тесты покрывают рискованное поведение. Фраза «сборка успешна» подтверждает ограничения типов и связывания, но не равенство бизнес-логики. Агент должен остановиться, потому что выполнил явное условие приёмки и исчерпал согласованные проверки, а не потому, что закончились очевидные действия или diff выглядит аккуратно.

В незнакомых системах главный риск создаёт недостающий контекст

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

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

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

В легаси-системах появляются связи между языками. COBOL вызывает ассемблер или процедуры базы данных. Программы RPG зависят от команд CL и файлов с внешним описанием. Страница Classic ASP обращается к компонентам COM, написанным на VB6. Книга Excel вызывает запрос Access, который запускает хранимую процедуру. Инструмент, индексирующий только язык из задачи, строит чистую карту с пропущенными дорогами.

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

Для совпадения поведения нужен независимый от нового кода оракул

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

Небольшой стенд проверки паритета можно начать с манифеста, который определяет равенство:

{
  "case": "month_end_partial_input",
  "input": "fixtures/partial.dat",
  "compare": ["stdout", "records", "exit_code"],
  "ignore": ["run_id", "processed_at"]
}

Затем запустите старую и новую реализации из чистого состояния и сохраните машиночитаемые результаты:

case                         old  new  records  result
month_end_partial_input      04   04   1827     PASS
blank_amount_field           00   00   19       PASS
operator_rerun_after_step_3  00   08   641      FAIL

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

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

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

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

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

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

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

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

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

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

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

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

Автодополнение выигрывает, когда разработчик уже знает замысел

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

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

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

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

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

Ассистент лучше всего работает с вопросом, который можно ограничить

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

Задайте ограниченный вопрос с названными доказательствами. Вместо «объясни эту подсистему» спросите: «Используя определение задания, эти два copybook и три места вызова, объясни, когда CUSTOMER-STATUS меняется с H на A. Для каждого перехода укажи файл и символ, затем перечисли пути, которые не удалось разобрать». Ответ всё ещё может быть неверным, но такой формат делает видимыми выводы без опоры на данные.

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

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

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

Агентам нужны ограниченные права и видимые доказательства

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

Полезный отчёт о запуске должен отвечать на конкретные вопросы:

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

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

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

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

Выбирайте инструмент по доказательствам и масштабу последствий

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

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

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

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

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

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

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