Снова про review-bottleneck

Наткнулся на видео, где мужик говорит, что проблема code review bottleneck в ai-разработке решается через отказ от code review. В моей системе координат это совет является безусловно вредным, но раз человек знает, что такой bottleneck есть, то, наверное, ему есть, что предложить.

В общем, смотрю, что мужик предлагает: TDD, agentic review и более тщательное SDD. Ну то есть, как я это понял:
1. Вы с агентом написали тест, который проверяет, что желаемое поведение появилось
2. Вы с агентом составили архитектурное решение, как вы видите реализацию.
3. Агент нагенерил реализацию.
4. Другой агент отревьюил на предмет фигни и поправил.
5. ???
6. PROFIT!

Насколько это лечит проблему?

По-моему, в апреле, у меня появился новый этап в цикле разработки - design preview. Он появился после того, как я понял, что на сложных кейсах, где меняется существующая логика, первая итерация red-usecase, green-usecase сразу гарантированно идёт в помойку, потому что ИИ начинает впихивать костыли, лишь бы позеленить тест. Поэтому я решил, что необходимо все же добавить небольшой этап проектирования перед разработкой.

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

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

1. Review bottleneck никуда в таком подходе, откровенно говоря, не уходит. Просто смещается влево на этап архитектуры. Сокращает ли это man in the loop? Вот хз вообще.
2. Спроектированная заранее архитектура - это набросок. Как она реально ляжет в настоящий код - большой вопрос. Весьма вероятно, что никак. И это много раз случалось у меня, например. Как это влияет? Просто придётся вернуться на этап проектирования и все продумать заново. И, вероятно, код читать придётся.
3. Даже на спроектированной заранее архитектуре даже отрефакторенный код может оказаться кучей вонючей субстанции. И без человеческого ревью это, как оказалось, не выловить.
4. Агенты умеют нарушать инструкции. Если он не сможет реализовать вашу ADR, или тест окажется красным, агент легко может реализовать что-то ещё и сказать, что все готово. И то что он сделает, даже отдалённо не будет напоминать то, что вы от него ожидали. Хотя вот это можно выловить агентским ревью.

Что это значит?

С одной стороны все 4 возражения не очень строгие.
1. По идее, проектирование только архитектуры может быть дешевле, чем ревью. В смысле человеческого времени.
2. Если не попал в решение, и тест все ещё красный, или агент поднимает какой-то консерн, то, во-первых, это все ещё не каждый раз, во-вторых, всегда можно повторить этап проектирования.
3. Если код плох, но работает и архитектурно соответствует желаемому, то, в целом, можно и удовлетвориться.
4. Если агент сделал что-то не то, то на агентском ревью это можно обнаружить и поправить.

С другой стороны, вот у меня вроде точно такой процесс, как озвучивает автор: и tdd, и sdd, и agentic review (хоть пока и без архитектурного контроля независимым агентом), но от ревью я, если честно, отказываться не готов.

Да и не занимает это ревью так уж много. По моим ощущениям, большинство кейсов не требуют больше 15 минут ревью суммарно. Итого, небольшое приложение на 100 кейсов не потребует больше 25 часов ревью, то есть больше 3 рабочих дней. По моему опыту разработка сотни кейсов занимает 2 недели. Ну полнедельки-то из них на ревью уж можно выделить?

Короче, на мой скромный взгляд, сейчас отказываться от человеческого ревью кода РАНО. Думаю, лучше тут не торопиться, ещё успеется.