Как профессионалы в области программного обеспечения действительно оценивают код, сгенерированный ИИ?

Зарегистрированный отчёт на arXiv поднимает вопрос, который избегали: какие критерии и какие предвзятости разработчики используют при принятии или отклонении кода LLM. Это отсутствовавшая эмпирическая основа для дискуссии.

Простыми словами

Научная статья, опубликованная на arXiv 13 июля 2026 года (arXiv:2607.09434), формализует в формате Registered Report исследование того, как профессиональные разработчики оценивают код, сгенерированный инструментами вроде Copilot, ChatGPT или Claude. Иными словами: первая попытка строгого измерения того, что на практике означает «принятие кода от ИИ».

Что даёт такой подход

Registered Report публикует протокол (вопросы, гипотезы, план анализа) ДО сбора данных — методология проходит рецензирование заранее, а результаты публикуются независимо от их знака. Этот формат, заимствованный из экспериментальной психологии, исключает p-hacking и постфактумное сочинительство. Его появление в Software Engineering само по себе сигнализирует: поле наконец требует надёжных доказательств, а не анекдотических демонстраций. Резюме на arXiv чётко об этом говорит: спустя несколько лет после Copilot в литературе до сих пор нет эмпирических оснований для главного действия — человеческой ревью кода от ИИ.

Анализ — почему это важно для профессии

1. Пробел в исследованиях. Мы измеряем скорость генерации, количество принятий в редакторе, списанные токены. Но по‑серьёзному мы не измеряем критерии, которые разработчики используют, когда кликают «принять». Эта статья как раз нацелена на эту слепую зону.

2. Связь с темой «хайп-усталости». Другая статья на arXiv, опубликованная в тот же день («Programmers Are Poor and Overconfident Judges of LLM-Generated Assertions», arXiv:2607.08885), предполагает, что разработчики переоценивают свою способность оценивать выводы LLM. Вместе эти работы рисуют неудобную картину: мы оцениваем быстро, оцениваем плохо, но уверены в себе. Это заставляет переосмыслить рабочие процессы — больше автоматизированных защитных мер на выходе, меньше доверия к человеческому глазу на входе.

3. Что может извлечь craft-сообщество прямо сейчас. Два конкретных шага: (a) делать ревью кода от ИИ явным (короткий чек-лист: намерение, инварианты, крайние случаи) вместо неявного; (b) измерять у себя инциденты после мержа, связанные с кодом от ИИ, который был «принят без обсуждения».

Так что

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