Все, кто сталкивался с контролем качества, помнят классическую формулу - fail fast: ошибку, обнаруженную на этапе написания кода, исправить дешевле, чем на этапе тестирования. С появлением ИИ эта формула смещается на один шаг влево - ошибка в спецификации теперь стоит намного дороже, чем стоила раньше. ИИ возвращает нас во времена K-GAS и model driven development: условия, из которых автоматически создаётся код, важнее самого кода. Контроль качества для кода, написанного ИИ, должен быть организован совершенно иначе, чем для кода, написанного человеком.

Эффективность code review падает практически до нуля: человек не успевает за скоростью генерации. В отличие от человеческого кода, в котором раз за разом повторяются типовые ошибки, за которые глаз цепляется сам, ИИ-ошибки случайны и не имеют паттерна. Стандартные метрики эффективности ревью, вроде числа комментариев, перестают работать.

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

Поэтому акцент смещается от code review и code style guide в сторону формулирования требований, подробного описания архитектурных решений и последующей автоматизированной проверки корректности работы получившегося кода. В идеальном случае человек вообще не должен открывать созданный ИИ код. За человеком нужно закрепить то, что автоматизировать нельзя: ревью требований и спецификаций, формулирование инвариантов, разбор инцидентов.

Схема контроля качества теперь выглядит так:

Тесты. Conformance-тесты к требованиям и развитые юнит-тесты с измерением покрытия C1/C2. Юнит-тесты с фиксированными параметрами плохо работают против случайных ошибок, поэтому к ним добавляются property-based tests, проверяющие инварианты на тысячах сгенерированных входов, и контрактные тесты на границах модулей, закрывающие проблему интеграции независимо сгенерированных кусков. Всё это из хорошей практики превращается в жизненную необходимость.

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

Отдельная проблема - круговая валидация: если тесты пишет тот же ИИ по той же спецификации, тест подтверждает согласованность системы, а не её корректность. Код и тесты должны генерироваться из одной спецификации, но в разных сессиях. Мутационное тестирование - единственный способ проверить, что тесты вообще что-то тестируют: если намеренно испорченный код проходит ваши тесты, тесты не работают.

Трассируемость и документация. От требований к тестам и от тестов к коду. Код работает, тесты зелёные, но никто не понимает, как работает система - этот comprehension debt взрывается при первом серьёзном инциденте. Без трассировки невозможно ревьюить тесты.

Статический анализ вместо глаз. Если человек не открывает код, его глаза должен кто-то заменить. Это делает статический анализатор - основной инструмент борьбы с «экологическими» багами. Архитектурные тесты автоматические проверки запретов на зависимости между модулями, циклических ссылок, дублирования определений. Измерение метрик сложности кода - цикломатической сложности, количества точек выхода и так далее.

Безопасность и supply chain. Отдельный пласт, который в классической схеме контроля качества живет на периферии, теперь входит в обязательный периметр. ИИ галлюцинирует зависимости - несуществующие пакеты; тянет устаревшие версии библиотек с известными CVE. SAST/DAST-сканеры в CI переходят из разряда «хорошо бы» в разряд «без этого нельзя». Сюда же лицензионные проблемы: сгенерированный код может воспроизводить фрагменты лицензируемого кода, и это юридический риск.

Контроль качества смещается не только влево, к требованиям, но и вправо, в эксплуатацию. Раз код никто не читал, единственный способ узнать, что он сломался - наблюдение за поведением системы: метрики, алерты и т.д. Канареечные деплои и автоматический откат становятся частью системы качества.

Человек выходит из кода - но не из ответственности за систему.

#blog