Дядя Боб выпустил ub-mode: 750 слов правил для ИИ-агентов

Что произошло, почему это важно и что взять в работу.

Правила вида «сначала падающий тест, потом правка» превращают качество агентского кода в проверяемый контракт — но требуют ручной сборки утилит и адаптации под PR/CI команды.

Связанные услуги: Чат-бот для бизнеса, AI Boost Team, стать клиентом.

Репозиторий на два файла. README.md и SKILL.md. Кода внутри нет ни строчки. Всё, что выложил Роберт Мартин по прозвищу Дядя Боб, — примерно 750 слов инструкций для ИИ-агента. Автор «Чистого кода» на днях положил это на GitHub под именем ub-mode.

Смешно тут вот что. Человек, который двадцать лет учил людей писать аккуратный код, потратил 750 слов на то, чтобы объяснить машине то же самое. И, судя по тексту правил, объяснял он не «как писать код», а «как отчитываться за работу». Разница принципиальная.

что произошло и что именно лежит в репозитории

ub-mode — это скилл. Формат, который сейчас прижился у Claude, Grok, Cursor и прочих агентских сред: файл с набором инструкций, который агент подхватывает, когда его вызывают командой вроде /ub-mode. Для Claude в README указан путь ~/.claude/skills/ub-mode/SKILL.md. Скопировали, вызвали, работаете.

Второй файл, README.md, отсылает к трём внешним утилитам, которые надо ставить самостоятельно. То есть скилл сам по себе ничего не проверяет: он задаёт порядок действий и требует, чтобы агент прогнал результат через чужие инструменты.

Автор упоминает, что часть идей взял из poteto-mode / pstack. Это важная деталь для понимания жанра: перед нами не открытие, а аккуратная сборка из уже ходивших по рынку практик, сделанная человеком с репутацией. Репутация здесь и есть главный актив. Те же самые правила, подписанные никому не известным ником, никто бы не стал устанавливать.

откуда это растёт

«Чистый код» вышел давно и стал одной из тех книг, которые либо читают на первом году, либо ругают на пятом. Главная претензия к ней у практиков: слишком много ритуала, слишком мало доказательств, что ритуал окупается. С ub-mode история повторяется буквально.

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

Отсюда и вся конструкция. Правила написаны не для того, чтобы агент стал умнее. Они написаны, чтобы у него не осталось пространства для отчёта «готово, шеф».

три части: работа, правильность, дисциплина

first make it work

Здесь всё начинается с воспроизводимости. Агент обязан написать тест до правки кода и убедиться, что тест падает именно по ожидаемой причине. Не «упал хоть как-то», а упал от того бага, который мы лечим. Потом минимальная правка, которая делает тест зелёным.

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

Дальше идут требования, которые к «чистоте кода» отношения почти не имеют. Структура данных продумывается до логики. Всё внешнее валидируется на входе в систему. Код, который пишет в базу или дёргает внешний сервис, должен переживать повторный запуск после сбоя на середине и давать тот же результат, что и первый. Это уже про идемпотентность, и это самая практичная часть скилла.

И принцип, который стоит вынести в отдельную рамку:

«Важен принцип "убери лишнее перед тем, как добавлять". Прежде чем писать новый код, агент должен упростить то, что уже есть».

then make it right

Вторая часть — про первопричину. Формулировка Мартина жёсткая:

«Защитная проверка, которая только прячет падение, — это не исправление» ("A guard that only hides the crash is not a fix").

Guard на null убирает падение и не отвечает на вопрос, откуда null взялся и бывает ли он там по модели данных. Иногда защита действительно нужна, но правило требует сначала понять причину. По той же логике запрещено глушить ошибки компилятора.

Отдельный удар по тестам. Тест должен проверять поведение так, как его видит вызывающий код. Если тест остаётся зелёным при условии, что каждая функция возвращает пустой результат, такой тест выбрасывают. Это, пожалуй, самый полезный абзац во всём файле. Агенты (и люди, чего греха таить) обожают тесты, которые не могут упасть.

practice

Третья часть — рабочая дисциплина. Журнал решений с причинами. Бережное отношение к контекстному окну. Мелкие коммиты, в сообщении которых есть причина, суть изменения и способ проверки. Запрет удалять Git-worktree, если в нём остались незакоммиченные изменения.

Последний пункт выглядит мелочью до первого раза, когда агент сносит дерево вместе с полуготовой работой.

три утилиты вместо самооценки агента

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

• Crapper — считает риск изменения каждой функции: чем сложнее функция и чем хуже покрыта тестами, тем выше балл. Порог в правилах Мартина — меньше 10 для каждой функции. Языки: Clojure, Java, Go, TypeScript, Rust, Python.
• Dryer — ищет похожие фрагменты кода. Порог срабатывания — похожесть от 0,8.
• Mutator — мутационное тестирование. Вносит в код мелкие ошибки и показывает, какие из них тесты не заметили.

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

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

где начинается трение с реальной командой

Скилл требует отправлять изменения сразу в основную ветку. Вот тут правило Дяди Боба вступает в прямой конфликт с тем, как устроена работа в большинстве компаний: pull request, обязательное ревью, прогон CI, запрет прямых пушей в main.

Переносить этот пункт в команду без изменений нельзя. Это предпочтение одного разработчика, работающего в своём ритме, а не политика для коллектива из десяти человек. Правило придётся переписать под ваш процесс: ветка, PR, ревью, зелёный CI, мерж. Агент при этом должен оставаться в тех же рамках, что и люди, иначе вы получите аккуратный код в обход всех ворот качества.

Второе трение техническое. Утилиты ставятся отдельно, вручную. Crapper покрывает шесть языков, и это хороший охват. Про охват Dryer и Mutator в описании ничего нет, так что для вашего стека совместимость придётся проверять самому. Плюс все три инструмента надо встроить в пайплайн, иначе агент «забудет» их запустить.

Третье, самое земное. Скилл ничего не говорит о том, как его правила живут рядом с вашим линтером, форматтером и статическим анализатором. Никакой интеграции не предложено. Всё это склеивание — ваша работа на вечер или два.

чего в файле нет

В README и SKILL.md нет результатов сравнительных испытаний. Неизвестно, насколько хорошо агенты реально соблюдают эти инструкции и насколько меньше проблем становится в коде после подключения. Ни одной цифры, ни одного замера.

Для 750 слов правил это ожидаемо, но для решения «внедряем в команду» — критично. Вы покупаете не результат, а процедуру. Процедуру разумную, но непроверенную на вашем коде.

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

что взять в работу

• Заведите требование «сначала падающий тест с ожидаемой причиной» как формальное условие приёмки для агентских PR. Это проверяется за минуту и отсекает основной массив фиктивной работы.
• Правило про идемпотентность записи во внешние системы стоит вынести в чек-лист отдельным пунктом. Агенты на этом ошибаются регулярно и незаметно.
• Мутационное тестирование (Mutator) даёт самую честную картину того, что ваши тесты вообще ловят. Прогонять его раз в квартал на критичных модулях дешевле, чем читать отчёты агента о покрытии.
• Запрет глушить ошибки компилятора и ставить guard вместо разбора причины — переписать своими словами в code review guidelines. Люди на этом ошибаются не реже машин.
• Пороги Crapper и Dryer откалибровать на своём коде. Чужие цифры почти наверняка не подойдут.

вердикт

750 слов не сделают ваш агентский код хорошим. Они сделают другое: превратят «качество» из вкусового суждения в набор проверяемых пунктов. Есть падающий тест с описанной причиной — есть зачёт. Нет теста — нет зачёта. Функция с риском выше порога — на разбиение. Мутация прошла незамеченной — тест дописать.

Это и есть главная ценность ub-mode: не мудрость Дяди Боба, а контракт. Пока качество обсуждается на уровне «мне кажется, нормально», спорят вкусы. Когда есть три утилиты и журнал решений, спорят о порогах. Второй разговор короче и полезнее.

Цена честная. Утилиты ставите сами. Правило про пуш в main переписываете под свой CI. Пороги калибруете на своём коде. Доказательств эффективности в репозитории нет, их придётся собрать внутри команды. Кто-то посмотрит на этот список и решит, что вечер работы того не стоит. Возможно, для команды из двух человек с тремя репозиториями так и есть — тогда берите из файла один пункт про падающий тест и не мучайтесь.

А вот если у вас агенты уже пишут в прод и вы ловите себя на том, что читаете их диффы на веру, ub-mode даёт готовый каркас приёмки. Собрать его под себя — работа. Проверить, что он работает, — тоже работа. Но это первая из виденных публичных попыток сформулировать требования к агентскому коду так, чтобы их можно было предъявить, а не обсудить.