ub-mode — дисциплина разработки для ИИ-агентов от Дядюшки Боба

Дядюшка Боб вышел на арену ИИ-кодинга. Роберт Мартин, автор книги «Чистый код», в конце октября 2026 года опубликовал репозиторий ub-mode — агентный навык из одного файла SKILL.md. Внутри сокращённый набор его принципов дисциплинированной разработки, который ИИ-агент обязан соблюдать при каждом изменении кода. Менее чем за две недели проект собрал около 6,7 тыс. звёзд на GitHub. Навык — урезанная переработка правил из проектов poteto-mode и pstack, дополненная детерминированными инструментами контроля качества.

Как устроен навык

ub-mode — это один текстовый файл с YAML-заголовком. Внутри нет кода, только короткие повелительные правила. Агент активирует навык по команде /ub-mode или когда пользователь просит следовать «сокращённым принципам».

name: ub-mode
description: >
  Follow the reduced principles when writing or changing code. Every change
  follows First Make it Work, then Then Make it Right, then Follow Practice.
  Use when the user runs /ub-mode or asks for the reduced principles.

Правила разбиты на три части, и каждая правка кода проходит через них по порядку:

1. First Make it Work — сначала заставить код работать.
2. Then Make it Right — потом сделать правильно.
3. Practice — дисциплина вокруг работы: журнал, контекст, коммиты.

Форма выбрана не случайно. Агенту бесполезно объяснять философию на три страницы — нужен список проверяемых действий. Поэтому каждый пункт сжат до одной фразы в повелительном наклонении.

First Make it Work

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

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

Фундаментальное мышление. Сначала правильная форма данных, потом логика. Первым делом делают то, что помогает всем следующим этапам. Если параллельные писатели важны, состояние не разделяют.

TDD. Падающий тест пишут до изменения кода. Тест должен упасть по ожидаемой причине. Затем вносят минимальное изменение, которое его проходит. Если честный тест непрактичен, плохой тест писать не нужно — он только создаёт видимость проверки.

Редизайн от первых принципов. Новое требование не прикручивают к старой конструкции. Вопрос звучит иначе: как бы вы это построили, если бы требование было с самого начала? Ответ продумывают до конца и доставляют по частям.

Атака на предпосылку. Если два исправления с одной предпосылкой провалились на одной и той же проверке, предпосылку записывают одним предложением. Дальше считают, у кого из участников перекос обязанностей, и снимают его. Новое исправление не начинают, пока с предпосылкой не разобрались.

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

Исполнение от результата. Цель — конечное состояние, которое можно проверить. Разрыв посередине допустим, если он запланирован и от него можно откатиться.

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

Архитектура

Отдельная ветка правил про структуру кода:

• Модель домена. Домен кладут в такую структуру, где невозможные состояния невозможно выразить. Словарь терминов домена поддерживают отдельно. Если код уже ясен и локален — его не трогают.
• Дисциплина границ. Данные проверяют там, где они входят в систему. Внутри им доверяют. Бизнес-логику держат в чистой функции.
• Дисциплина типов. Невозможное значение делают невозможным и для записи. Внешние данные разбирают один раз — на входе. Предупреждения компилятора не отключают.
• Идемпотентность операций. Повторный запуск — или запуск после падения на середине — приводит к тому же конечному состоянию.
• Разделение общего состояния. Если двум участникам не нужен один изменяемый объект, каждому дают свой. Если нужен — писатель один, и это закрепляют в самой структуре, а не в договорённостях.

Then Make it Right

Второй блок — про качество того, что уже работает.

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

Мелкие проверяемые шаги. Работу нарезают на единицы. Одну закончили и проверили — только потом начали следующую.

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

Crapper. Инструмент crapper считает сложность, покрытие и CRAP-score для каждой функции. Функцию держат ниже порога CRAP 10 — разбивают, тестируют или делают и то и другое. Стоит ли сокращать разветвления на switch, решают отдельно.

Dryer. Инструмент dryer находит структурное дублирование. Дубли с рангом 0.8 и выше убирают.

Mutator. Мутационное тестирование закрывает дыры в проверках: покрыть непокрытое, убить выживших мутантов, удалить мёртвый код.

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

Practice

Третий блок — дисциплина вокруг самой работы.

Журнал. Каждое действие и его причина записывают. По завершении журнал отчитывают пользователю.

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

Чистка ворк-деревьев. Находят то, что безопасно удалить, проверяют, что удаляемое никому не нужно, и возвращают место на диске. Незакоммиченная работа ждёт явного решения, а не молчаливого удаления.

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

Инструменты-спутники

Правила — половина дела. Вторая половина — инструменты, которые превращают пожелания в проверяемые ворота. README репозитория называет их deterministic quality-gate tools, то есть детерминированные ворота качества. Они считают факты и не зависят от настроения модели.

Схема простая: LLM отвечает за изменения кода, инструменты — за проверки. Требование «каждая функция ниже CRAP 10» нельзя размыть вежливым пересказом, потому что его проверяет число.

Установка

Установка занимает одну команду копирования. Файл SKILL.md кладут в каталог навыков агента под именем ub-mode:

~/.claude/skills/ub-mode/SKILL.md
~/.cursor/skills/ub-mode/SKILL.md
~/.grok/skills/ub-mode/SKILL.md

После этого навык вызывают командой /ub-mode. По умолчанию он не навязывается: агент включает его, когда пользователь просит работать по сокращённым принципам.

Зачем это нужно

Сами принципы не новы — все они знакомы по книгам Мартина и его докладам. Ценность ub-mode в форме подачи под конкретного потребителя: не человека, а LLM. Каждое правило сжато до одного проверяемого действия, а спорные места — вроде «если честный тест непрактичен, не пиши плохой» — закрывают лазейки, через которые агент обычно выкручивается.

Вторая ценность — связка правил с инструментами. Один файл SKILL.md задают порядок, а crapper, dryer и mutator превращают порядок в измеримые ворота. Это тот же подход, что и в обычной разработке с CI-проверками: договорённости без автоматической проверки со временем исчезают.

Проект свежий и активно развивается: первая версия появилась 25 октября 2026 года, лицензия MIT. Репозиторий: unclebob/ub-mode.