Роберту Мартину 73 года, программировать он начал в конце шестидесятых, известен как соавтор Agile-манифеста и автор принципов SOLID. Именно он написал Clean Code — книгу, которая стоит на полке чуть ли не у половины разработчиков мира. Я тоже читал — и не жалею ни минуты потраченного времени.

Идея книги одной строкой: код перечитывают намного чаще, чем пишут — поэтому будьте добры, пишите его чисто.

Clean Code была написана в 2008 году. А в конце июля Роберт Мартин за неделю собрал полноценный ремейк старой аркады Missile Command: 622 коммита, почти тринадцать тысяч строк кода. И не прочитал из них ни строчки.

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

Я решил разобраться в этой истории: раз автор книги про чистый код больше не читает код, то как он программирует? С этой целью я изучил репозитории Мартина и вместе с ИИ-ассистентами перебрал почти сотню его высказываний в X и на других площадках — каждое сверено по первоисточнику. В итоге набрал материала для потрясающего текста, который будет полезен не только инженерам, но и всем, кто использует ИИ для рабочих задач.

Кстати, это самый большой текст в подписке, поэтому готовьте самую большую кружку для кофе.

Сразу сниму главную претензию к Бобу. «Не читает код» — буквально неверно. Роберт Мартин читает спецификации и процедуры проверки, иногда заглядывает в имена функций, а результат тестирует руками. Отказался он от другого: от полного построчного чтения как главного способа доверять работе. Аргумент Мартина здесь простой: если читать ИИ-код целиком, то вы убьете главное преимущество такой работы — скорость работы.

Поэтому Мартин выстроил «полосу препятствий»: написанную ИИ-агентами систему проверок, сквозь которую он прогоняет ИИ-код. Такой подход — пример грамотно организованной loop engineering, техники работы с ИИ, о которой я рассказывал в [отдельном лонгриде](https://boosty.to/escaped_ai/posts/ebcb2513-9e24-4fde-a98a-d8592b1ee948). Дальше разберем, как она работает в прочтении Мартина.

## Разворот за четыре года

Итак, если вы пишите код для читателя, то каким он должен быть? У Мартина об этом целая книга, дам лишь главное: короткие функции, говорящие имена, никаких хитрых трюков, которые сегодня сэкономят строчку, а через полгода обернутся часами разбирательств. Целое поколение выросло на этом как на гигиене: чистить зубы — писать чисто.

Но это верно, когда читатель — человек. Уставший, с небольшой оперативной памятью, вернувшийся к чужому коду через полгода после того, как уволился его автор. Вся дисциплина чистоты — забота об этом человеке. Книга не о коде, она о читателе кода из 2008 года.

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

**Ноябрь 2022-го,** за четыре дня до запуска ChatGPT. «Предсказываю: ИИ в очередной раз разочарует "футуристов". Человеческий мозг настолько сложнее даже самых больших компьютерных систем, что цель — имитация разума — все еще очень далека».

**Февраль 2024-го.** Тон смягчается до дежурного: «ИИ — славный инструмент», конца программирования не будет.

**Ноябрь 2024-го.** Выходит его книга «We, Programmers» — хроника ремесла с подзаголовком «от Ады до ИИ». ИИ-часть все еще скептична.

**Сентябрь 2025-го.** «ИИ изменит программирование к лучшему — но программистов не заменит».

**22 января 2026-го** — первая трещина. «Claude кодит быстрее меня — значительно. И держит в "уме" больше деталей, чем я, — опять же значительно. Но Claude не может удержать общую картину. Он даже не понимает саму идею общей картины». Почти три тысячи лайков — читатели заметили то, чего в этой ленте еще не было.

**14 апреля 2026-го** — Мартин впервые произносит свою формулу целиком: «Я не ревьюю код, написанный агентами. Я измеряю: покрытие тестами, структуру зависимостей, цикломатическую сложность, размеры модулей, мутационное тестирование. По этим метрикам о качестве кода можно понять многое. Сам код я оставляю ИИ. Люди медленны в коде. Чтобы получить продуктивность, нам, людям, нужно отцепиться от кода и управлять с уровня выше».

**22 июля 2026-го.** Началось не с Мартина. Ори Померанц, инженер, пишущий код с 1983 года, спрашивает: «Я пробую писать с помощью Claude, но мне некомфортно позволять ему править мои файлы. Кто-нибудь еще это чувствует? Если я отвечаю за код, мне НУЖНО его понимать — хотя бы психологически. Начал программировать в 1983-м. Старый \[для использования ИИ\]?»


**23 июля.** Ответ Мартина: «Я значительно старше тебя. Я начал кодить в конце шестидесятых. Моя стратегия — не читать код, написанный моими агентами, вообще. Это единственный способ получить выигрыш от их продуктивности. Вместо этого я окружаю агентов предельно жесткими ограничениями: юнит-тесты, gherkin-тесты, QA-процедуры, метрики качества, мутационное тестирование, покрытие — и еще куча других. В итоге у меня очень высокая уверенность в их коде: он прошел сквозь строй всех моих ограничений и тестов». «Сквозь строй» — в оригинале run the gauntlet — его собственное выражение; отсюда и «полоса препятствий». Пост разлетелся по интернету: на момент написания статьи у него было восемнадцать с лишним тысяч лайков, пятьсот семьдесят один ответ.

Твит Мартина сработал: к концу обсуждения Померанц сдвинулся к его позиции — доверяет Claude достаточно, чтобы не читать код, но проверяет руками и требует автотесты.

Получается, совсем и не старый.

## Как Мартин программирует теперь

Виральный твит широко разошелся по пересказам — от изданий до блогеров. Но я не видел, чтобы кто-то разобрал [репозиторий Мартина](https://github.com/unclebob). А ведь там самое интересное — готовая схема того, как программирует «дядюшка Боб».

Главный репозиторий называется swarm-forge, «кузница роя». Это фреймворк оркестрации агентов, который Мартин создал 17 апреля 2026 года — через три дня после твита «я не ревьюю код агентов». На момент написания статьи у кузницы больше полутора тысяч звезд, и коммиты в нее идут постоянно — рой развивается на наших глазах. 

Устройство следующее: каждый агент работает в собственной копии проекта и собственном окне терминала (git worktree плюс tmux, если вам знакомы эти слова), а работу они передают друг другу эстафетой. Под капотом — агент на выбор: codex, claude или даже grok build.

Полный рой — шесть ролей: спецификатор, кодер, чистильщик, архитектор, упрочнитель (в оригинале specifier, coder, cleaner, architect, hardender) и QA — финальный контролер. Для задач поменьше конвейер ужимается до четырех ролей: работу чистильщика забирает рефакторер, упрочнение и финальное уведомление о готовности — архитектор, а отдельный QA-контролер исчезает. Для мелочей остается пара «кодер → чистильщик», где второй делает вообще всю проверочную работу один. Принцип при любом размере не меняется: писавший код агент сам его не проверяет.

Как это выглядит глазами человека? Допустим, вы захотели навайбкодить что-то по схеме Мартина. Строить рой с нуля не нужно: в папку проекта скачивается архив нужной конфигурации с github.com/unclebob, а стартовый скрипт сам догружает правила и открывает окна агентов — из своего понадобятся стандартные терминальные инструменты и хотя бы один установленный агент вроде codex или claude. 

Дальше вы рассказываете идею спецификатору: точка входа в его инструкции так и называется — «намерение пользователя». Он превращает рассказ в сценарии поведения и процедуры проверки, показывает вам и ждет одобрения: передавать работу кодеру без явного «да» ему запрещено. У Missile Command это видно прямо по истории репозитория: первым коммитом легла дизайн-спека, вторым — список из двадцати двух пользовательских историй, и дальше рой ел их по одной.

Добавлю, что если вы только начинаете вайбкодить, то начинать лучше с самой простой версии из писателя и проверяющего. Это уже полноценный рабочий цикл, достаточный для простого приложения. Затем поднимитесь по лестнице чисто из любопытства — заодно немного узнаете, как устроена полноценная разработка серьезного проекта.

Самое интересное в ролях — не обязанности, а запреты. Кодеру запрещено запускать проверки чистоты и мутационные тесты: это владения чистильщика, архитектора и упрочнителя. Тот, кто пишет код, не имеет права сам себя проверять. Контролеру QA, наоборот, запрещено заглядывать внутрь проекта: проверять можно только снаружи, через интерфейс, как обычный пользователь. А спецификатор — единственный, кому позволено разговаривать с человеком.

Кроме роли, каждый агент при старте получает «конституцию» — три коротких файла, общие для всего роя. И в них запретов тоже больше, чем разрешений. Свободная переписка между агентами запрещена: разрешены ровно два типа сообщений — передача работы и служебная заметка, причем заметку нельзя отправить без явного разрешения. При любой неоднозначности предписано «остановиться и спросить». Работать — только в своей копии проекта, в чужие ветки не заглядывать. И каждый коммит подписывать своей ролью.

Человек в инструкции спецификатора упоминается ровно два раза. Первый — в конце постановки: «спроси у пользователя одобрение, чтобы передать работу кодеру», то есть принеси сценарии на подпись; сама идея к этому моменту уже рассказана спецификатору в начале разговора. Второй — приемка, причем в той же фразе инструкции зашит вход следующего цикла: «когда QA сообщит, что работа завершена, влей изменения и спроси у пользователя следующую задачу». Выход одной задачи склеен со входом другой. Все. Между подписью и приемкой шесть агентов гоняют код по конвейеру без человека. 

И реальный пример. Назавтра после вирального твита Мартин сел и начал собирать Missile Command: 334 коммита в первый же день, 176 во второй, 96 в третий — и хвост до конца недели, всего 622 за семь дней. На выходе — не прототип, а готовая игра: настольная версия и браузерная, со счетом, волнами атак и глобальной таблицей рекордов, живущей на серверах Cloudflare. Любой может собрать ее из [репозитория](https://github.com/unclebob/missile-command) одной командой и попасть в мировой рейтинг игры, код которой автор не читал. Для масштаба: почти тринадцать тысяч строк кода, пять с лишним тысяч строк тестов, двадцать семь файлов спецификаций. 

## Полоса препятствий: из чего она собрана

Недавно я [писал](https://t.me/ai_exee/614) в канале, что экономика интеллектуальной работы перевернулась: написать — код, текст, отчет — теперь дешево, а дорого стало прочитать и проверить написанное. Мартин с этим не спорит. Он сделал следующий шаг, очень инженерный по духу: раз проверка стала самой дорогой частью работы, именно ее и надо автоматизировать следующей. Уверен, в ближайшие месяцы мы увидим много разных подходов к такой автоматизации. Полоса препятствий Мартина — один из первых. Пройдем по ней внимательно.

**Юнит-тесты** — проверки отдельных кусочков кода. Их пишут сами агенты, и Мартин их не читает. Ответ на вопрос «кто же проверит проверяющих» будет дальше, не волнуйтесь.

**Gherkin-спецификации** — тот самый артефакт, который Мартин читает глазами и утверждает лично. Заметьте: это не третье появление человека в конвейере, а содержимое первой из двух точек — когда спецификатор спрашивает одобрения, на подпись он приносит именно эти сценарии. Gherkin — язык описания поведения программы почти обычными словами; его придумали в середине 2000-х ровно для того, чтобы сценарии мог читать и утверждать человек без кода. Вот настоящий сценарий из Missile Command, целиком:

_Scenario: Aim crosshair clamps left and right edges_

  _Given a new game with width 800 and height 600_

  _When the player aims at -1 100_

  _Then the crosshair is at 0 100_

Перевод: дано — новая игра с экраном 800 на 600; когда игрок целится в точку за левым краем; тогда прицел останавливается на краю. Весь словарь языка — дюжина слов вроде «дано / когда / тогда» (полный список — в официальной справке: cucumber.io/docs/gherkin/reference), и ключевые слова переведены на семьдесят с лишним языков, включая русский.

Главное свойство, ради которого Gherkin стоит в центре конвейера: это не документация, а исполняемая спецификация. Каждая строчка сценария привязана к проверке — текст, который утверждает человек, и тест, который гоняет машина, буквально одно и то же. Такая спецификация не может незаметно протухнуть: разойдется с кодом — конвейер упадет. Человек утверждает поведение — реализацию сторожат проверки.

Есть здесь и ирония. Двадцать лет формат считался недоразумением: задумывался как язык для разговора с заказчиком, а осел у инженеров — лишним ритуалом, многословной писаниной поверх кода. Теперь писанину взял на себя агент, и главная слабость формата стала его достоинством: человеку остался ровно тот читаемый артефакт, ради которого всё затевалось.

**QA-процедуры** — инструкции финальной приемки, написанные обычной прозой: предусловия, шаги, критерии. С жестким требованием: проверять только снаружи, как пользователь, — внутренние механизмы проекта трогать запрещено. Это содержимое второй точки: на приемке Мартин проходит по таким процедурам руками, как пользователь.

**Метрики чистоты.** Главная называется CRAP — и это не шутка, а аббревиатура «Change Risk Anti-Pattern», риск при изменении кода. Устроена просто: чем сложнее функция и чем хуже она покрыта тестами, тем выше балл, причем сложность считается в квадрате, а непокрытость — в кубе. Балл выше тридцати — зона риска, «сложно и недотестировано». Чистильщику Мартина предписано держать CRAP не выше шести. В соседнем его проекте порог — восемь: пороги здесь настройка под задачу, а не догма.

**Мутационное тестирование** — кульминация полосы, тест самих тестов. Инструмент нарочно вносит в проект мелкие поломки — «мутации» — и смотрит, поднимут ли тесты тревогу. Формулировка из репозитория Мартина точнее любого пересказа: «Обычный прогон доказывает, что проект соответствует спецификации. Мутационный прогон проверяет, упадут ли приемочные тесты, если поменять важные значения». Первый проверяет код, второй — сами проверки.

Масштаб виден в цифрах: в каждый файл спецификаций Missile Command вшит отчет мутационного прогона, и сводка по всем двадцати семи файлам выглядит так — 2773 мутации сгенерировано, 2773 убито, ноль выживших.

Ноль выживших — не вердикт проверки, а условие выхода из цикла: упрочнитель инструктирован буквально «убить выживших», он правит тесты до тех пор, пока мутанты не перестанут проскакивать. Отчет свидетельствует, что цикл доработал до конца, — не что код безупречен. И ломали здесь значения в спецификациях, а не сам код.

## Он сам поставил эксперимент

Самое частое возражение Мартину звучит просто: покажи цифры. Приятная новость: он показал. 29 мая 2026 года, за два месяца до вирального твита, Мартин опубликовал собственный замер — и назвал его «Джон Генри», в честь легендарного рабочего, который посоревновался с паровым молотом, победил и умер от натуги. Давайте посмотрим, как дела у нашего Джона.

Условия такие. Одну и ту же задачу — написать классическую консольную игру Hunt the Wumpus — решали дважды. Сначала пять живых программистов, каждый поодиночке. Потом четырехролевой рой — та самая ужатая версия конвейера из прошлой главы.

Люди добирались до работающей игры в среднем за 146,6 минуты — почти два с половиной часа. Рой справился за 62 минуты общего времени, и вот его раскладка: десять минут на спецификацию, десять на кодирование, десять на рефакторинг и тридцать две — на мутационное упрочнение. Обратите внимание: половину машинного времени съела полоса препятствий, не написание кода.

Качество на выходе: покрытие тестами 97%, CRAP не выше 5,0 — строже порога Мартина. Вердикт самого Мартина в твите дословно: «Игра работала как положено. Качество кода: приемлемое».

Но главная цифра другая. Из 62 минут общего времени только 15 минут приходится на человеческое внимание: написать спецификацию, поиграть в готовую игру, приглядывать за процессом. У живого программиста человеческое время равно всему времени: 146 минут внимания против 15. Почти в десять раз меньше.

Достается эта скорость они не бесплатно: нужно выстроить процесс и наладить полосу препятствий, а затем поддерживать все это добро. Стартовый вариант можно взять у Мартина, но на серьезном проекте его обязательно придется доделывать под себя.

Оговорки очевидны: одна маленькая задача, пять участников, и судьей выступал сам автор роя. Это не наука, это один замер. Но замер, который автор выложил целиком, с цифрами и без рекламного вывода, — а еще он сам выбрал ему имя. Джон Генри обогнал машину — и умер. Человек, назвавший свой эксперимент в честь этой легенды, явно понимает, что соревноваться с машиной в скорости — затея со скверным концом. Поэтому он и не соревнуется, а берет все лучшее с обеих сторон.


## Где здесь дыры

Система Мартина выглядит стройно — тем важнее честно посмотреть, где у нее слабые места. Возражений в треде и вокруг него сотни; я отобрал самые сильные, по нарастающей.

**Первое, самое личное: полосу построили сами агенты.** Еще в феврале Мартин писал: «Я попросил Claude написать мне небольшой мутационный тестер на Clojure». То есть инструмент, которым он проверяет агентов, написан агентом. В треде его спросили об этом прямо: а кто пишет сами проверяющие инструменты? Ответ: тоже агенты — но инструменты малы и детерминированы. Трактовать можно двояко. Скептик скажет: охрана, нанятая подозреваемым. Мартин ответит: правильность маленькой детерминированной программы видна по ее результату, а не по происхождению. Обе трактовки честные — выбирайте по темпераменту.

**Второе, от главного оппонента.** Грэди Буч, еще один классик программной инженерии, ответил в ветке, выросшей из апрельского твита Мартина: «В отличие от Боба, я читаю весь код, созданный агентами. Покрытие тестами и подобные метрики дают мне уверенность в функциональности — и ровно никакой уверенности в том, что агенты не внесли уязвимостей, не оставили мертвого кода, который затруднит понимание системы, не упустили решений, критичных для производительности. Доверяй, но проверяй. Как опытный разработчик, я знаю запах хорошего и плохого кода. У агента нет ни опыта, ни контекста, чтобы это знать. Хотите быстро и неряшливо — следуйте совету Боба».

Тут я обязан сделать оговорку, которая сама по себе деталь сюжета: к моменту написания статьи этот пост Буча удален — текст восстановлен по сохранившимся индексам, цитирую с этой пометкой. Самый резкий публичный оппонент снял свою реплику; причин мы не знаем.

Важно и другое: Буч — не ИИ-скептик. Агентов он считает очередной ступенью абстракции, как когда-то компиляторы, и уже в августе писал, что проверенные десятилетиями инженерные методы надо адаптировать к агентной разработке. То есть спор двух классиков — не «пользоваться ли ИИ». Он ровно об одном: какие человеческие проверки сохранить при смене инструмента. Буч ставит на чтение. Мартин — на полосу. Причем мнение Буча могло и поменяться — в ИИ сейчас все настолько быстро, что апрельские реплики выглядят историей.

**Третье, в самое основание.** Ветеран тестовой автоматизации Zhimin Zhan напоминает: Gherkin уже пытались класть в основание процессов — и SmartBear с Tricentis, компании, строившие на нем целые продукты, потеряли на этом «десятки миллионов долларов и изрядно репутации». Помните иронию из главы про полосу? Вот ее вторая половина: формат, который ожил благодаря агентам, до этого дважды хоронили за большие деньги. Ставка Мартина — на то, что теперь, когда писанину несет агент, экономика формата сложится иначе. И в этом есть логика: раз код пишет ИИ, то текстовое описание работы агента, понятное любому человеку, действительно обретает новую ценность. Посмотрим, что выйдет в итоге.

**Четвертое, теоретическое.** Метрики — это «прокси с малым количеством информации», напоминает инженер Томаш Микула (его формулировку передаю по пересказу): вера менеджера, что бардак можно предотвратить через покрытие тестами и «метрики качества», — известная управленческая иллюзия. Ответ Мартина на это возражение обезоруживает: он признает, что может ошибаться, и называет свою позицию ставкой. Не доказанной теоремой — ставкой.

И закрою главу тем, что нравится мне в Мартине больше всего: его оговорки честнее его лозунгов. Он публично признал, что городить полный конвейер на каждую задачу — перебор: «часто я просто использую юнит-тесты и CRAP». Согласился, что даже многослойные тесты не ловят все баги и последним судьей остается человек с ручным тестированием. А на упрек в непоследовательности ответил, что семь месяцев назад сам считал, что код надо читать. Человек, который так спокойно показывает границы своей системы, вызывает больше доверия, чем сама система.

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

## Что забрать инженеру

Соберу практическую выжимку — что из системы Мартина переносится в обычную работу с ИИ, без роя и шести терминалов.

**«Пиши чисто» не работает. Работает «померь и заставь исправить».** Его формула из ответа критикам: «Агенту нельзя сказать "пиши чисто". Ты должен измерять чистоту того, что он производит, и заставлять исправлять провалы. Без таких ограничений агенты совершенно счастливо строят большие комья грязи, которые сами не смогут поддерживать». Практический перевод: любое пожелание к агенту превращайте в проверку с числом. Не «пиши тесты» — а «покрытие не ниже такого-то». Не «не усложняй» — а конкретный порог сложности. Пожелания агент забывает на втором часу работы; проверки не забываются, потому что их гоняет не он.

**Начинайте полосу с дешевых барьеров.** Полный конвейер на каждую задачу — перебор по признанию самого автора: «часто хватает юнит-тестов и CRAP». Первые два барьера дают больше всего защиты за меньшую цену; мутационное упрочнение и отдельные роли — это уже для проектов, которые жалко потерять.

**Разделяйте писателя и проверяющего.** Самое переносимое правило роя: тот, кто написал код, не проверяет его сам. Это доступно и без всякого роя: пусть один диалог пишет, а проверяет другой — с чистым контекстом, не знающий, «что имелось в виду». Проверяющий без контекста писателя видит не замысел, а то, что написано на самом деле, — в этом весь смысл.

**Пороги — настройка, не догма.** У самого Мартина CRAP не выше шести в одном проекте и не выше восьми в соседнем. Конкретная цифра значит меньше, чем сам факт числового порога: есть число — контроль можно доверить машине; нет числа — остается спорить о вкусах.

**Чистота — экономия, не эстетика.** Мотив Мартина сугубо практический: «грязный код замедляет моих агентов». Данные Sonar из главы про полосу это подтверждают: меньше токенов, меньше перечитываний. Если ИИ у вас платный, чистота проекта буквально уменьшает счет в конце месяца.

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

## Что забрать не-инженеру

Важно! Если вы инженер — тоже останьтесь и дочитайте эту главу. На мой взгляд, она главная в тексте.

Начну с примера другого известного человека современности — на днях Саймон Уиллисон дал Claude Code задачу сделать игру Raccoon Heist на Three.js. Claude Fable 5 подошла к задаче основательно: сама написала скрипты, сгенерировала текстуры и даже проверила их глазами. Прогнала тесты, нашла и исправила ошибки — отдельно для мобильной версии и десктопной. Ближе к концу сгенерировала титульный арт — и сама назвала его «шикарным». Все было прекрасно кроме одной проблемы.

Игра оказалась скучной.

Я не буду разбирать причины этого провала, так как глава про другое. Считается, что ИИ в первую очередь выстрелил в коде по простой причине: здесь легко можно понять, успешен ли результат. Тесты пройдены, код запускается — значит, успех.

Но если игра после запуска оказалась скучной — то успех тут же превращается в провал. Я уже писал, что в первую очередь мы автоматизировали написание контента (это может быть не только код). Сейчас — автоматизируем его прочтение. Но вот «скучный/интересный» — не автоматизируем никогда, хотя некоторую помощь ИИ может оказать и здесь. На мой взгляд, в разработке роль инженера будет все больше смещаться именно сюда — в зону ответственности за то, что результат окажется «интересным», «полезным», «нужным» — тем, за что люди готовы платить вниманием, временем или деньгами.

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

Но есть ли то, что можно переложить на схему Мартина? Конечно!

**Постановка задачи** — многих молодых журналистов в редакциях зачастую со скандалами доучивают писать план. Он кажется им чем-то не нужным, но как только план писать начинаешь, решается 50% проблем текста: появляется ровная структура, пропадают «подвисшие» идеи и высказывания, плюс с самого старта ты понимаешь, сколько тебе времени понадобится на сбор информации и работу.

Подготовительный этап отлично можно автоматизировать с помощью ИИ, причем с момента, о котором вы даже не подозреваете. В подписке есть [статья](https://boosty.to/escaped_ai/posts/33e32f7b-2dc6-4160-9ff9-3124f7d6ba9f) Тарика Шихипара из команды Claude Code, в которой он рассказывает, как с помощью ИИ еще перед тем, как писать промпт, разбирается, насколько он хорошо понимает задачу в принципе. Почитайте: там как раз про 10 минут, которые экономят часы.

**Критерии приемки — до, а не после.** Мартин тратит человеческое время в двух точках: постановка и приемка. Поэтому лучше сразу прописать — что вы хотите получить на выходе. Короткую новость, длинный гайд, описания товаров для интернет-магазина — а если описания, то одно или сразу три варианта, на выбор? Потратьте на критерии 5-10 минут: так и модель лучше поймет, что ей делать, а у вас будет под рукой короткий чек-лист для приемки результата.

**Тесты** — у каждой работы они свои, и они обязательно есть. Текст нельзя «запустить», но еще перед написанием можно проверить, актуальна ли тема, есть ли по ней поисковые запросы, а затем — не написали ли про нее уже конкуренты. Если писали — меняем угол. Готовый текст также прогоняется через редакционную политику, проверяется на фактику, а авторские интерпретации — обязательно штурмуются с помощью ИИ. Подумайте или даже обсудите с нейронкой, какие тесты должны быть в вашей задаче, как увеличивается их количество с ростом сложности.

**Принимайте снаружи.** QA-агенту Мартина запрещено заглядывать во внутренности проекта — только смотреть глазами пользователя. Моя финальная проверка любого текста — задача ИИ прочесть его глазами читателя (только не забывайте, что ИИ должен знать, кто именно ваш читатель). Аналогично в другой задаче. Делаете презентацию боссу — пусть ИИ посмотрит глазами босса. Заполняете странички в интернет-магазине — ИИ-агент сейчас может запустить браузер и посмотреть их глазами покупателя. 

**Проверяйте сами проверки.** Это мутационный прием из главы про полосу — подложите ошибку и посмотрите, поймают ли. Если не поймал, то причиной может быть не только плохая модель — например, диалог уже длинный, контекст замусорился и ИИ начал пропускать важные вещи. Тогда надо запускать новый чат, аккуратно перенеся в него результаты (или чистить контекст ИИ-агента).

**Лестница проверок.** Как Мартин не везде использует шесть агентов, так и вы регулируйте количество проверок. Писать модели «перепроверь себя» в том же чате должно быть инстинктивной вещью — но это хорошо только для мелких задач.

Задача сложная и/или результат ценен для вас — берем результат и переносим в новый чат или передаем новому ИИ-агенту. Контекст не будет замусорен и модель посмотрит «свежим взглядом». Сложность задачи растет — выносите проверки разным агентам, каждый со своим промптом и целью.

А если можете себе позволить — проверяйте работу одной модели с помощью другой. Я писал этот текст следующим образом: закинул идею в Opus 5 и дал задачу дособрать контекст. Твиты Мартина выцеплял и сверял по первоисточникам ассистент на Fable 5 — он же, как самая умная модель из моего набора, сводил финальный план и ассистировал в написании. А приемку глав делала GPT-5.6 Pro — по схеме Мартина: чужая модель, проверка только по своду проверенных фактов, переписывать текст запрещено, при неоднозначности — остановиться и спросить. Первый пакет проверки я откалибровал, подсадив четыре «мутации»: GPT-5.6 Pro поймала все четыре — и заодно нашла несколько настоящих неточностей, которые мы поправили.

**Помните, кто последний судья.** Даже Мартин при всей своей полосе финальное поведение проверяет руками — и прямо признает, что последний судья это человек. Автоматика фильтрует, но решение «принято» произносите вы. Удобно забыть об этом ровно до первого случая, когда придется объяснять, почему под плохой работой стоит ваша подпись.

## Подпись

Вернемся к спору, с которого все началось. Если присмотреться, Ори и Мартин спорили не про код. Ори говорит: если я отвечаю за результат — мне нужно его понимать. Мартин отвечает: я подписываюсь под тем, во что не заглядываю, потому что доверяю своим проверкам. Неприятная правда в том, что правы оба: понимать свой результат необходимо — и проверки нужны такие, чтобы работали даже с исполнителем, который не прочь схалтурить.

В том же треде Мартина прижали вопросом: если весь код пишет модель, а ты только смотришь на метрики — в каком смысле ты вообще инженер? Он ответил одной строкой, и эта строка — лучшее резюме всей истории: «I am the engineer because I am accountable». Я инженер, потому что отвечаю за результат.

Это главный вывод. Начиная работу над задачей, честно спросите себя — каким должен быть результат, под которым вы поставите подпись. Из ответа получится все остальное: как ставить задачу, какие критерии приемки, какие должны быть тесты, чтобы достичь результата.

И чем лучше вы осваиваете ИИ, тем чаще придется задавать себе этот вопрос: работы под вашей подписью становится все больше, а сама подпись — тяжелее. Как она тяжелеет от ступени к ступени, я разбирал в [лонгриде](https://boosty.to/escaped_ai/posts/41350944-ed2d-4ccb-8dd6-bc31222bbf05) про «лестницу» создателя Claude Code Бориса Черни. Система Мартина, по сути, отвечает на вопрос, который «Лестница» оставила открытым: как подниматься, не подписывая не глядя.