Роберт Мартин начал программировать в конце 60-х. Он написал книгу, которая задала индустрии стандарт читабельного кода. И теперь он публично говорит, что не читает код своих AI-агентов — совсем. Это не жест разочарования. Это осознанная стратегия.
«Моя текущая стратегия — не читать код, который пишут мои агенты. Это единственный способ воспользоваться их продуктивностью. Вместо этого я окружаю агентов жёсткими ограничениями: unit-тесты, Gherkin-тесты, QA-процедуры, метрики качества, mutation testing, покрытие тестами и многое другое. В итоге у меня очень высокая уверенность в коде, потому что он прошёл весь этот гарлет».
Контекст
Роберт Мартин — один из авторов Agile Manifesto (2001) и создатель принципов SOLID. Его книга «Clean Code» (2008) почти два десятилетия служила обязательным чтением для любого разработчика, который хочет писать понятно: маленькие функции, говорящие имена, минимум побочных эффектов. Его позиция по качеству кода — одна из самых цитируемых в профессиональном сообществе.
Твит набрал быстрые очки на Hacker News и стал поводом для дискуссии: что именно меняется в роли инженера, когда агент пишет тысячи строк за минуту. Ответы под постом разделились — одни считают, что это здравый прагматизм, другие — что без понимания кода нельзя гарантировать безопасность и архитектурную целостность.
Показательно, что заявление сделано человеком, который буквально написал книгу о важности читабельности. Когда Uncle Bob говорит «я не читаю», — это не лень. Это сигнал о смене парадигмы, который сложно игнорировать.
Аналитика
Суть позиции — доверие через верификацию, а не инспекцию. Мартин не говорит «AI всегда прав». Он говорит: если код прошёл жёсткий набор автоматических проверок — mutation testing, покрытие, Gherkin-сценарии, QA-метрики — значит, он ведёт себя так, как требует спецификация. Глаз инженера тут лишнее звено.
Для индустрии это важный сигнал. Десятилетиями code review был основным механизмом контроля качества и передачи знаний. AI меняет уравнение: агент способен сгенерировать 2000 строк за минуту. Читать их с той же внимательностью, что и человеческий код, — физически нецелесообразно. Ответ Мартина — переложить гарантии качества на автоматические системы, а человеческое внимание направить на проектирование ограничений, интерфейсов и тестов.
Есть важный нюанс: этот подход работает, если ты уже умеешь писать качественные тесты. Mutation testing — не тривиальный инструмент, Gherkin требует дисциплины. Это не упрощение процесса, это его реорганизация. Инженер перемещает усилия с чтения имплементации на проектирование ограничений. Возможно, это и есть новое определение senior-разработчика в мире агентных систем.
Кейсы применения в бизнесе
B2B SaaS стартап (3-5 разработчиков): Команда использует Claude или Cursor для генерации endpoint'ов и бизнес-логики. Вместо ручного code review на каждый PR — жёсткий CI с порогом покрытия выше 85%, обязательным mutation score и автоматическими интеграционными тестами. Разработчики пишут тесты и интерфейсы, агент генерирует реализацию. Скорость поставки фичей растёт, а знания о логике хранятся в тестах, а не в голове одного человека.
Корпорация с legacy: Новый код пишется агентами, но каждый модуль проходит mutation testing через Stryker (JS/TS) или mutmut (Python). CI не пропускает PR с mutation score ниже установленного порога. Code review остаётся для архитектурных решений и публичных интерфейсов — не для имплементации. Junior-разработчики могут участвовать в продуктивной работе без риска деградации качества.
SMB и локальный бизнес в КР/СНГ: Небольшая команда или фрилансер автоматизирует отчёты, интеграции, внутренние инструменты с помощью AI. Вместо ручной проверки — набор дымовых тестов и Gherkin-сценарии на критические бизнес-пути. Если тест зелёный — деплой. Это снижает порог входа: дорогой senior для построчного ревью уже не обязателен.
Кейсы в личной жизни
Разработчик-фрилансер: Переходишь на TDD-first с агентами — сначала пишешь тест (что должен делать модуль), потом просишь Claude написать реализацию, которая его проходит. Не читаешь имплементацию подробно — проверяешь только интерфейс и тесты. Скорость сдачи задач клиенту растёт, уверенность остаётся.
Студент или начинающий разработчик: Вместо того чтобы разбирать каждую строку AI-кода, пишешь тесты на желаемое поведение и используешь агента как генератор реализаций. Это прокачивает навык постановки требований — более ценный долгосрочно, чем умение читать чужой синтаксис.
Контент-мейкер или продакт: Нужны скрипты для автоматизации — парсинг, отчёты, публикации. Формулируешь, что скрипт должен делать, добавляешь несколько assert'ов на граничные случаи, отдаёшь агенту. Получаешь работающий код без погружения в детали реализации. Главное — знать, что проверять.
Как применить сегодня
- Перейди на TDD с агентами: сначала пиши тест — потом отдавай задачу AI. Тест = спецификация, а не опциональная проверка.
- Настрой mutation testing: mutmut для Python, Stryker для JS/TS. Подключи к CI — PR с низким mutation score не проходит.
- Добавь Gherkin/Cucumber сценарии для бизнес-критических путей — это одновременно документация и автотест.
- Установи минимальный порог покрытия в CI (например, 80%) — агент обязан писать тестируемый код или провалит пайплайн.
- На code review фокусируйся только на интерфейсах и архитектурных контрактах — имплементацию проверяют тесты, не ты.