Пять артефактов вместо одного диффа: intent, спецификация, план, ограничения и acceptance criteria. Именно в эту сторону, по сути, предлагает двигать ревью кода колонка в The New Stack: не отменять человеческую проверку, а переносить ее туда, где еще принимаются решения, а не только сравниваются строки в pull request. Для русскоязычных команд это важный сигнал: если код все чаще пишет ИИ, то узким местом становится уже не набор текста, а качество постановки задачи.
Как пишет The New Stack, вопрос сформулирован почти провокационно: сколько нам осталось до момента, когда мы перестанем читать код вообще. Но ответ у автора не в духе «прощай, code review». Наоборот: контроль предлагается сохранить, просто поднять его на уровень выше. Человек должен смотреть не только на финальный diff, а на то, что именно хотели построить, по каким правилам, с какими ограничениями и как вообще будет определяться, что задача решена. В логике автора это выглядит не как ослабление инженерной дисциплины, а как попытка вернуть ее туда, где она реально влияет на результат.
Сама постановка вопроса выросла из очевидного тренда последних двух лет: генерация кода перестала быть экзотикой и стала повседневным инструментом. Когда фрагменты, функции и иногда целые модули появляются за минуты, старое ревью кода начинает буксовать. Человек по-прежнему пытается вручную вычитать все изменения, но объем артефактов уже растет быстрее, чем внимание тимлида или старшего разработчика. При этом проблема часто не в синтаксисе и не в стиле. AI-инструменты нередко пишут вполне правдоподобный код, который проходит линтеры и даже часть тестов. Сбой происходит раньше: не так понята задача, не зафиксированы ограничения, не описаны граничные случаи, не определены критерии приемки. В результате команда обсуждает красивый diff, хотя спорить надо было о другом еще до первой сгенерированной строки.
Проверять не код, а замысел
В этом и состоит главная мысль материала: человеческий checkpoint нужно переносить upstream, то есть выше по процессу. Если разработчик или продукт-команда формулируют намерение, спецификацию, план работ, технические и бизнес-ограничения, а также acceptance criteria, то именно эти документы и становятся новой первой линией контроля. Такой подход особенно понятен тем, кто уже устал от ревью в формате «тут переименуй переменную» на фоне гораздо более дорогих ошибок в бизнес-логике. Если ИИ ускоряет производство кода, то людям логично сосредоточиться на вещах, где цена ошибки выше: архитектурный выбор, контракты между сервисами, требования к безопасности, совместимость с текущей системой, ожидаемое поведение на краях.
Для российских команд здесь нет ничего мистического. Многие элементы этого процесса давно знакомы под другими названиями: техдизайн, RFC, краткая спецификация к задаче, чек-лист приемки, описание non-functional requirements. Разница в другом. Раньше эти документы нередко считались полезным, но необязательным приложением к «настоящей» разработке. Теперь они могут стать центральным объектом инженерного контроля. Если код пишется быстрее человека, то именно документы о намерении и правилах становятся тем местом, где команда еще успевает поймать ошибку дешево. После генерации и интеграции это уже дороже: нужно пересобирать реализацию, переписывать тесты, откатывать фичу или объяснять бизнесу, почему сделано «вроде то», но не то.
В практическом смысле это меняет и роль сеньоров. Их ценность все меньше в том, чтобы героически вычитывать километры diff'ов по ночам, и все больше в том, чтобы ставить рамку: что именно строим, какие trade-off допустимы, какие требования обязательны, а какие nice to have. Для продактов и CTO это тоже неприятная, но полезная новость. Массовое внедрение AI-ассистентов не сокращает потребность в сильной инженерной культуре, а повышает ее стоимость. Плохо сформулированная задача теперь масштабируется не медленно, а очень быстро. Раньше один разработчик мог неверно понять постановку и за день написать лишний кусок системы. Теперь ту же ошибку можно размножить по нескольким сервисам за пару часов, если генератор кода работает без внятных ограничений.
Что это меняет для команд и бизнеса
Если смотреть шире, статья попадает в болезненную точку всего рынка developer tools. Большая часть разговоров вокруг AI в разработке долго крутилась вокруг скорости: сколько строк написано, сколько времени сэкономлено, насколько быстрее закрываются тикеты. Но скорость без контроля намерения быстро превращается в ускоренное производство технического долга. Поэтому новый смысл ревью кода не в том, чтобы исчезнуть, а в том, чтобы стать многослойным. На первом уровне команда проверяет intent и критерии успеха. На втором — план и ограничения. И только на третьем смотрит на сам код, причем уже не как на единственный источник истины, а как на реализацию заранее обсужденного решения. Такой сдвиг особенно полезен для компаний, где несколько команд делят общую платформу: там ошибка в требованиях обычно опаснее локальной шероховатости в коде.
Есть и еще одна деталь, которую легко недооценить. Перенос проверки вверх по процессу фактически делает разработку более наблюдаемой для бизнеса и смежных функций. Код может оценить не каждый, а вот acceptance criteria, ограничения по срокам, требованиям к безопасности или совместимости читают и архитектор, и QA, и продукт, и иногда юрист или комплаенс. Чем больше часть инженерного решения выражена в понятных артефактах до написания кода, тем меньше коммуникация завязана на узкий круг людей, способных расшифровать diff. Для быстрорастущих компаний это не бюрократия, а способ не потерять управляемость, когда AI-инструменты разгоняют выпуск изменений сильнее, чем процессы согласования.
Открытый вопрос теперь звучит уже не так: «перестанем ли мы читать код». Скорее иначе: сколько человеческого внимания команды готовы отдать коду, если ту же самую внимательность можно раньше вложить в постановку задачи и поймать более дорогие ошибки до генерации. Похоже, ближайшая эволюция инженерного процесса будет не про отказ от ревью, а про смену точки, в которой человек говорит системе: да, именно это мы и собираемся строить.