Я наконец понял, почему анти-ИИ луддиты так яростно отрицают сгенерированный код. Причина ровно та же, по которой когда-то отрицали автотесты.
Понял я это не из статьи про ИИ, а из собственной памяти о людях, которые двадцать лет назад с той же интонацией объясняли, почему автоматике доверять нельзя, а глазами — можно.
Как ведёт себя здоровый инженер
У тебя есть приложение. Неважно, кто его написал: ты сам, коллеги, модель или оно скачано из интернета. Здоровый инженер берёт и покрывает его тестами.
Подчёркиваю: тестами покрывается не код, а приложение. Функциональными и нефункциональными end-to-end тестами. Ты имитируешь условия, в которых приложение будет работать в проде: под соответствующей нагрузкой, с реальными объёмами данных, и дёргаешь его за рычаги реальными задачами эксплуатации.
Нефункциональные тесты — отдельный класс: нагрузка, устойчивость, безопасность, объёмы данных и прочие non-functional требования заказчика и желаемые условия работы продукта. Не «открывается ли форма», а «что происходит с системой под реальным давлением».
Если приложение всё это выдерживает — оно годно к эксплуатации. Логика простая: если ты достаточно достоверно сымитировал эксплуатацию на стенде, то в реальной эксплуатации приложение будет выполнять те же функции не хуже. Это не вера. Это то, на чём стоит вся дисциплина тестирования последние десятилетия.
Что на это отвечает луддит
«Пфф, ерунда, нейрослоп, это ничего не гарантирует. Надо смотреть код глазами».
Давайте разберём эту позицию по существу, потому что она того заслуживает — как заслуживает разбора любое утверждение, которое выглядит здравым, но разваливается при первом нажатии.
Ты взял навайбкоженное приложение и засунул его в окружение, копию прода. Положил туда данные — копию прода. Подал нагрузку — копию прода. Подёргал все функции ровно так, как их дёргают реальные пользователи: синтетикой или по записям из реальных продакшен-логов.
И увидел: всё работает. Память не течёт. Ключи не уезжают на сторону. База не встаёт в дедлок. Место на диске не кончается. Сеть не падает. Сканеры уязвимостей показывают нули.
После этого тебе говорят, что ничего из этого ничего не гарантирует, и обязательно нужно прочитать каждую строчку глазами.
Вопрос один: что именно добавит чтение строк глазами к стенду, который уже воспроизвёл прод целиком? Человек, вычитывающий diff, не увидит утечку памяти под нагрузкой — её видит профайлер на стенде. Не увидит дедлок на реальных объёмах — его ловит нагрузочный тест. Не найдёт уязвимость быстрее сканера. Глаз инженера проверяет намерение автора строки. Стенд проверяет поведение системы. В проде работает поведение, а не намерение.
Где я этих людей уже видел
Я стал вспоминать, где встречал этот способ спорить раньше. И вспомнил. Там, где внедряли автотесты.
Аргументация «за» была тогда дословно такой же, как сейчас аргументация «за ИИ»: можно писать, не вглядываясь в каждую строку, и проверять результат end-to-end, а не вычитывать код глазами. Доверяй проверенному поведению, а не ручному осмотру.
Аргументация «против» — зеркально та же, с обратным знаком: «автомат не понимает смысла», «это ничего не гарантирует», «настоящий инженер должен пройти код руками». Поменяй слово «автотест» на «ИИ» — и ты не отличишь речь 2008 года от речи 2026-го.
Современные анти-ИИ луддиты — это ровно те же люди, которые когда-то сопротивлялись автотестам в пользу огромных трат времени на ручное ревью. Та же роль, та же логика, те же проигранные двадцать лет назад аргументы. История уже вынесла по этому спору вердикт — просто теперь на сцене другой реквизит.
Контур, а не глаза
Отсюда вытекает практический вывод, который переживёт весь этот спор.
Если обеспечить AI-кодинг нормальным процессом QA — тем самым стендом, что описан выше, — навайбкоженное приложение работает идентично написанному руками. Не «почти», не «с оговорками». Идентично по наблюдаемому поведению, потому что проверяется именно поведение в условиях прода.
Есть живая иллюстрация этого тезиса. Фаундер в одиночку переписал десятилетнюю кодовую базу на AI-инфраструктуре: около шести месяцев без продакшен-инцидентов, 10–15 деплоев в день. Это чужой кейс, не мой личный опыт, — но он показывает ровно то, о чём речь: AI-код плюс процесс равно надёжность. Надёжность даёт процесс, а не происхождение строк.
Ручное построчное ревью AI-кода изоморфно старому сопротивлению автотестам: это ритуал контроля, который чувствует себя безопасностью, но не производит её. Безопасность производит контур проверки поведения. Глаз над diff'ом — не производит.
Кто это умеет строить
Вся соль в том, что «просто обеспечить нормальный QA» — это и есть работа. Стенд-копия прода, синтетическая нагрузка по реальным логам, нефункциональные тесты, quality gates, единые правила приёмки — это не то, что заводится само от того, что ты против луддитов.
Я этот контур строил руками. В Korus — масштабирование автотестов на phpunit и cypress, рост release reliability, формализация процессов контроля качества и quality gates на уровне департамента. В UMI на старте в трекере висело несколько тысяч багов и прилетало по 5–10 новых в день; после внедрения QA-практик, системного баг-трекинга, единых правил приёмки и CI/CD — качество и стабильность релизов выросли предметно.
Это тот самый навык, который превращает навайбкоженное в production-grade: не чтение строк, а построение приёмочного контура, которому можно доверять.
Спор про «смотреть код глазами» закрыли ещё на автотестах. Если нужен человек, который умеет собрать этот контур на практике, — вы знаете, где меня найти.