Наша концепция проверки кода, созданного ИИ

JetBrains Research

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

Исследования

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

Наша команда Human-AI eXperience в сотрудничестве с исследователями из Лундского университета изучает, как должен выглядеть инструмент для проверки кода, созданного ИИ, и как он должен быть интегрирован в процесс разработки. Исследование описано в новой paper и будет представлено на Международной неделе эмпирической разработки программного обеспечения 2026 (ESEIW) в октябре.

Основная мысль исследования заключается в том, что главная проблема при проверке кода, созданного ИИ, — это калибровка доверия. Пока инструменты не станут совершеннее, разработчики будут продолжать работать «вслепую».

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

Почему ваши привычные инстинкты проверки не работают с кодом, созданным ИИ

Традиционно, когда вы проверяете код коллеги, вам помогает множество невидимых факторов. Вы примерно знаете уровень их квалификации, в каких частях кодовой базы они уверены, а в каких склонны торопиться. Вы можете задать им вопросы. Когда что-то выглядит странно, вы можете написать им в Slack и получить объяснение за тридцать секунд. Однако ничего из этого невозможно, когда автором является LLM.

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

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

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

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

Другими словами, проверка изменений в нескольких файлах, созданных LLM, — это не проблема сравнения кода (diffing), а проблема калибровки доверия. Мы определяем калибровку доверия как способность распределять усилия по проверке пропорционально риску на уровне сегментов, когда автора нельзя расспросить о его уверенности или логике рассуждений. Это навык понимания того, где нужно присмотреться внимательнее, а где можно позволить себе беглый просмотр — навык, который при проверке кода, написанного человеком, поддерживается неявно через социальные и контекстные сигналы, и для которого проверка кода, созданного ИИ, в настоящее время практически не предоставляет никакой поддержки.

Трехуровневый рабочий процесс проверки: от общего обзора к выборочным деталям

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

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

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

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

Инструменты: что есть сейчас и как наше предложение может помочь разработчикам инструментов поддержать разработчиков ПО

Ни одна из этих идей не возникла на пустом месте, и мы обсуждаем это в статье. Некоторые из конструктов имеют частичные аналоги в уже существующих инструментах: CodeRabbit предлагает краткие текстовые обзоры пулл-реквестов. Claude Code запускает несколько агентов-рецензентов, которые помечают результаты по уровню серьезности. Модель стековых пулл-реквестов Graphite разбивает крупные изменения на независимо проверяемые единицы — это ближайший существующий аналог нашей идеи «фрагментов», хотя он работает с несколькими пулл-реквестами, а не декомпозирует одно сгенерированное предложение. GitHub тоже заметил этот сдвиг. Платформа теперь выпускает рекомендации специально для проверки кода, созданного ИИ. Также сообщается, что проверка кода с помощью Copilot уже составляет более одной пятой всех проверок на платформе.

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

Вывод для разработчиков инструментов ясен и прямолинеен: если вы создаете инструменты IDE для эпохи разработки, ориентированной на ИИ, вопрос, вокруг которого нужно строить работу, — это не «Как нам отобразить diff?», а «На каком уровне детализации проверяющему нужно распределить внимание и какой сигнал нам нужно там отобразить?»

Наша трехуровневая структура предоставляет принципиальную основу для создания таких инструментов. Вот некоторые рекомендации:

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

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

В предыдущей статье нашего блога мы обсуждали, как расширенная реальность может быть интегрирована в инструменты для помощи разработчикам при проверке кода, сгенерированного ИИ (см. раздел под названием «Наброски того, что можно создать»). Следите за обновлениями в этой области, чтобы узнать о подобных исследованиях.

Узнать больше