Доверие ИИ: почему Роберт Мартин не читает код нейросетей и вам не советует

Почему легендарный программист перестал читать код ИИ

Роберт Сесил Мартин, известный как Дядя Боб, автор книг по чистой архитектуре, сделал заявление, которое разделило сообщество разработчиков. Он признался, что полностью перестал читать код, сгенерированный ИИ-агентами. Вместо этого он полагается на автоматические проверки: юнит-тесты, тесты на Gherkin, метрики качества и мутационное тестирование.

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

За этим решением стоит 50-летний опыт Мартина в программировании. Он десятилетиями продвигал идею, что качество кода измеряется не его внешним видом, а поведением, подтверждённым тестами. ИИ-агенты лишь обострили этот принцип. Если раньше можно было спорить о читаемости, то теперь, когда автор кода - не человек, единственным объективным критерием становится прохождение автоматических проверок.

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

Четыре столпа автоматической проверки кода

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

Юнит-тесты: фундамент доверия

Юнит-тест - это маленькая программа, которая проверяет одну конкретную функцию. Вы подаёте на вход известные данные и сравниваете результат с ожидаемым. ИИ сгенерировал функцию сложения двух чисел - тест передаёт 2 и 3 и проверяет, что ответ равен 5. Если ответ 6, тест падает, и вы узнаёте об ошибке до того, как код попадёт к пользователю.

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

Gherkin-тесты: проверка поведения системы

Gherkin - это язык описания сценариев, построенный на конструкции Given-When-Then. Он связывает код с бизнес-требованиями на естественном языке. Сценарий для интернет-магазина выглядит так:

Given пользователь добавил товар в корзину
When он применяет промокод на скидку 10%
Then итоговая сумма уменьшается на 10% от цены товара

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

Метрики качества: автоматический надзиратель

ИИ склонен генерировать запутанные конструкции. Длинные функции на 200 строк, вложенные условия пятого уровня, копирование блоков кода вместо выделения общей логики. Человек на код-ревью может устать и пропустить это. Метрики не устают.

Цикломатическая сложность измеряет количество независимых путей через функцию. Значение выше 10 - сигнал к рефакторингу. Количество строк в функции жёстко ограничивается, например, 20-30 строками. Процент дублирования показывает, сколько кода скопировано, а не переиспользовано. Мартин рекомендует настроить эти метрики в CI/CD и блокировать слияние кода, если они превышают порог. ИИ-агент, получивший отказ из-за метрик, в следующей итерации сгенерирует более чистый код. Это дисциплинирует и машину, и команду.

Мутационное тестирование: проверка самих тестов

Самая коварная ловушка при работе с ИИ - ложное чувство безопасности. Вы написали тесты, они проходят, вы уверены в коде. Но насколько строги сами тесты? Мутационное тестирование даёт ответ.

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

Почему порядок в коде важен для ИИ (и для вас)

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

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

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

Можно ли доверять такому подходу в реальных проектах?

Главный страх: что будет, если тесты неполные или метрики настроены неправильно. Это рабочий риск, а не фатальный недостаток подхода. Мартин не предлагает слепо доверять автоматам - он предлагает направить усилия на создание качественных проверок вместо ручного чтения сгенерированного кода.

Внедрение идёт постепенно. Начните с юнит-тестов для критической логики. Добавьте линтер и метрики сложности в пайплайн CI/CD - они будут блокировать явно проблемный код без участия человека. Когда процесс отлажен, подключите Gherkin-тесты для ключевых пользовательских сценариев. Мутационное тестирование оставьте на этап, когда база тестов уже покрывает основной функционал. Не обязательно внедрять всё сразу.

Такой подход не отменяет контроль - он его усиливает. Разработчик перестаёт быть узким местом, которое физически не успевает прочитать всё сгенерированное. Вместо этого он проектирует систему проверок, которая ловит ошибки быстрее и надёжнее. Это смена роли, которую мы наблюдаем в индустрии: от написания кода к созданию агентов и тестов. OpenAI в отчёте о долгоживущих ИИ-моделях подтверждает: автономные агенты накапливают ошибки и отклоняются от инструкций. Автоматические проверки - это барьер, который не даёт этим ошибкам попасть в продукт.

Что это значит для обычного разработчика: 3 практических шага

Подход Мартина - не теория для избранных. Это практическая стратегия, которую можно внедрить в любом проекте, где используется ИИ-генерация кода.

Шаг 1: Начните писать юнит-тесты для всего кода, включая сгенерированный ИИ. Получили код от нейросети - сразу напишите тест, который проверяет его поведение. Не читайте код построчно, проверьте его работой. Это быстрее и объективнее. Если в проекте уже есть тесты, добавьте запуск на каждый pull request от ИИ-агента.

Шаг 2: Настройте линтер и метрики сложности в CI/CD. Инструменты вроде ESLint, Pylint или SonarQube проверяют код автоматически. Установите пороги: функция длиннее 30 строк не проходит, цикломатическая сложность выше 10 требует рефакторинга. Эти правила применяются одинаково к коду от человека и от ИИ. Anthropic в Claude Code уже использует команду специализированных ИИ-агентов для проверки каждого pull request - это следующий уровень автоматизации, к которому можно стремиться.

Шаг 3: Попробуйте описать ключевой сценарий в Gherkin. Выберите одну критическую функцию продукта - оформление заказа, регистрацию, расчёт стоимости. Опишите её поведение в формате Given-When-Then. Подключите инструмент вроде Cucumber или Behave. Когда ИИ-агент изменит этот участок кода, вы мгновенно увидите, не сломалось ли поведение.

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