Вопрос уже не только «работает ли код»

Когда в pull request появляется новая строчка, ревьюер всё чаще задаёт не только обычный вопрос «работает ли это?». Появляется второй: этот код написал человек, AI-ассистент или они сделали это вместе?

Именно об этом пишет автор заметки From “Who Wrote This?” to “Provenance, Actioned”. Главная идея простая: AI-код не нужно запрещать, но его происхождение должно быть видно прямо во время ревью.

Разработчик мог принять подсказку Copilot, переработать ответ ChatGPT, вставить сгенерированный фрагмент после нескольких правок — а в истории коммита всё равно останется его имя. Обычный git blame показывает автора изменения, но не объясняет, как именно появился спорный блок.

Коротко: если AI уже участвует в написании кода, ревью должно видеть этот след, а не угадывать его по стилю.

Что такое provenance в коде

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

Похожая логика уже есть в безопасности цепочки поставки ПО. В спецификации SLSA provenance происхождение описывается как проверяемая информация о том, откуда появился программный артефакт и как он был произведён. Для AI-кода смысл близкий, только переносится ближе к моменту code review.

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

Как это может помочь ревьюеру

В идеальном варианте рядом с изменённым фрагментом появляется отметка: provenance доступна. По клику ревьюер видит prompt, модель, контекст сессии и быстрые действия: открыть исходный диалог, скопировать prompt в комментарий или временно вынести фрагмент для локальной проверки.

Это небольшая деталь интерфейса, но она меняет разговор. Вместо «что это вообще такое?» появляется предметное обсуждение: «вот запрос к модели, вот результат, вот место, где нужно проверить безопасность или логику».

«Самая полезная provenance — та, по которой можно сразу действовать».

Эта мысль важна. Происхождение AI-кода не должно быть архивом ради отчётности. Оно должно помогать принять решение: принять, доработать, проверить внимательнее или отклонить изменение.

Почему это вопрос безопасности

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

NIST в документе Secure Software Development Practices for Generative AI отдельно связывает генеративный ИИ с практиками безопасной разработки. Смысл здесь простой: AI-инструменты не отменяют проверки кода, тесты, threat modeling и ответственность команды.

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

Где остаются вопросы

Пока это скорее направление, чем устоявшийся стандарт. Не до конца понятно, кто будет фиксировать происхождение: IDE, расширение Git, CI/CD, платформа для ревью или отдельный агент. Не меньше вопросов к точности: если система будет часто ошибаться, ревьюеры быстро перестанут ей доверять.

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

Главная интрига — научатся ли команды использовать provenance без охоты на ведьм: не искать виновного, а быстрее понимать происхождение решения.

Итог

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

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

Хорошее code review в эпоху ИИ — это не поиск, кто «виноват» в строке кода. Это проверка решения, его рисков и поддержки в будущем. Кто помог написать фрагмент, уже не так важно, как то, можно ли понять его путь и уверенно принять ответственность за результат.