Процесс с упором на тестирование без код-ревью

Процесс разработки, в котором ручное код-ревью перестаёт быть главным механизмом надёжности, а поиск дефектов перекладывается на масштабное рандомизированное тестирование (фаззинг, property-based тестирование). Dan Luu в danluu-ai-coding-testing, опираясь на десятилетний опыт в Centaur (компании по проектированию CPU), утверждает, что такой подход даёт более высокое качество, чем процессы с опорой на ревью, и что именно под такой workflow органично подходят ИИ-агенты, пишущие код.

Модель Centaur

Что они делали вопреки общепринятым в индустрии разработки представлениям:

• Выделенные инженеры по тестированию как полноценная карьерная траектория наравне с проектировщиками логики - та же тарифная сетка, та же частота повышений. Тестирование - это навык; 20 лет опыта в нём перевешивают 5% чужого рабочего времени.
• Никакого код-ревью по умолчанию. Ревью проводилось по необходимости, для сложных изменений, а не в качестве обязательного шлюза. Доверие к тестам было настолько высоким, что ревью почти не добавляло надёжности.
• Практически никаких написанных вручную тестов и никаких unit-тестов. Ручные тесты ("hand tests") были исключением.
• Постоянное рандомизированное тестирование - то, что в софтверной разработке называют фаззингом / property-based / рандомизированным тестированием: непрерывная генерация и запуск новых тестов (около 800 из ~1000 машин непрерывно генерировали новые тесты, а около 200 прогоняли трёхмесячный регрессионный набор).
• Регрессионный набор тестов растёт бесконечно: любой тест, однажды нашедший баг, остаётся в наборе навсегда.

Результат: меньше одного заметного пользователю бага в год при команде настолько компактной, что компания смогла продержаться в условиях жёсткой борьбы на рынке x86 вплоть до 2021 года. Затраты усилий делились примерно как 55% на тестирование и 45% на разработку. При этом Luu подчёркивает, что решающую роль играет не объём усилий, а методология: у фаззинга низкие фиксированные затраты, и он масштабируется под любой бюджет ресурсов.

Почему это подходит для агентной разработки

Один человек, управляющий агентами, способен сгенерировать больше кода, чем десять человек в состоянии проверить вручную. Это ломает концепцию ревью как обязательного шлюза: потолок пропускной способности ревью (~400 строк кода в час, code-review-throughput-limits) становится узким местом всего процесса. У рандомизированного тестирования такого человеческого ограничения нет: туда просто направляют вычислительные мощности. Поэтому рабочий процесс, показавший эффективность в небольшой команде разработчиков CPU, оказывается именно тем, что позволяет агентным "фабрикам софта" выпускать огромные объёмы без потери качества.

Критически важная оговорка: всё, деградация чего не ограничена рамками, будет деградировать, если выливать сотни PR в день. Рандомизированное тестирование как раз и выступает таким ограничителем. Но LLM плохо умеют проектировать тесты: написанные ими фаззеры дают слабое покрытие и пропускают базовые вариации входных данных. Поэтому системе требуется контур обратной связи, находящий и закрывающий пробелы в покрытии (участие человека или поэтапная раскатка с мониторингом метрик, логов и обращений в поддержку). Конвейер Luu от тикета в техподдержке до PR - один из примеров такого контура: он генерирует исправление и добавляет тестовое покрытие, которое повторно выявляет этот же баг при регрессионном прогоне.

Связь с дискуссией о ревью

Это один из двух противоположных ответов на совет "просто проверяйте код ИИ как PR стажёра":

• reviewing-ai-code (Depierre): ревью не масштабируется, а проверять сгенерированный LLM код труднее (ревьюеры находят меньше дефектов при большей уверенности в себе) - следовательно, пропускная способность агентной разработки принципиально ограничена.
• Данная концепция (Luu): ревью изначально не было правильным инструментом для обеспечения надёжности; для этого нужны тесты, и тесты отлично масштабируются - следовательно, нужно отказаться от ревью, а не от агентов.

Обе стороны согласны, что модель "ревью как за стажёром" не работает. Обе сходятся на том, что предел ревью составляет около 400 строк кода в час. Но расходятся они в выводах: считать ли это потолком генерации кода через LLM (Depierre) или поводом вовсе перестать опираться на ревью (Luu). При этом Luu честно обозначает необходимое условие: схема работает только тогда, когда методология тестирования достаточно надёжна, чтобы ей доверять. В большинстве софтверных компаний этого нет: навык просто не развивался, поскольку тестирование никогда не рассматривалось как первоклассная карьерная траектория.

why-software-factories-fail критикует такую замену со стороны обучения моделей. Аргумент Horthy в том, что RL оценивает трейс исключительно по признаку успешного прохождения тестов и ни по чему более. Соответственно, при обучении модель ничто не штрафует за то, что код станет труднее изменять в следующем месяце - а значит, факт "тесты прошли успешно" оказывается именно тем сигналом, который не способен поймать деградацию, для сдерживания которой Luu предлагает его использовать.

benchmarking-opus-5-slopcodebench даёт конкретные данные о цене и выгоде смещения в сторону тестов: у Opus 5 тесты составляли 51% сгенерированного объёма против 11% у Opus 4.8, и ему потребовалось четыре строгих прохода против одного.

См. также: кластер фаззинга (coverage-guided-fuzzing, structure-aware-fuzzing, grammar-based-fuzzing, differential-fuzzing), llm-output-variance (почему единичные прогоны тестов вводят в заблуждение), agent-failure-mode-skill.