Вступление
Это история о том, как попытка починить маленький раздражитель в Claude Code неожиданно привела меня к полноценному сетапу для разработки фич совместно с AI-ассистентом. Приложил немного музыки для атмосферы.
Я больше 10 лет работаю в продуктовом дизайне и дизайн‑менеджменте. Обычно — на стыке дизайна, процессов и продукта. Помогаю компаниям решать проблемы деградации интерфейсов, несистемности и слабой синхронизации между дизайном и разработкой.Последние полгода я много работаю с Claude Code. Но не в формате «пусть AI рисует лендинги». Меня интересует другое: можно ли превратить AI‑ассистента в инструмент для сложных, многоуровневых дизайн‑процессов внутри больших команд. Не генератор кнопок, не copilot для «поправь typo», а инженерный слой поверх процессов.Эта статья — не про сам Claude Code. Она про методологию, которая возникла в процессе работы с ним.
С чего всё началось
Я работаю с Claude Code в native macOS‑приложении, и параллельно у меня обычно запущено несколько больших задач. Примерно раз в минуту происходит одно и то же: «Разрешить выполнить bash‑команду?», «Разрешить изменить файл?», «Разрешить доступ?» — Allow. Allow. Allow. Deny. Allow.Поверх стандартных разрешений, у меня установлена кастомная система, которая блокирует Claude от произвольных изменений файлов и ведёт лог решений. Заглянув как‑то в лог, я узнал что за неполный рабочий день было 671 permission‑событий, 591 Allow, 72 Deny и 8 infrastructure errors. Соотношение — примерно 8:1 в пользу Allow.Это означает, что я уже не принимаю решения — я натренировал себя автоматически нажимать Allow. Это не контроль — это автопилот без обучения. В этот момент я понял неприятную вещь: если однажды Claude Code попросит что‑то действительно опасное — например:
—я, скорее всего, нажму Allow автоматически. Не потому что доверяю, а потому что привык. Финальным триггером для меня стала команда:
Разрешение на которую Claude запрашивал уже седьмой раз за эту сессию. Стало очевидно: система перестала выполнять свою функцию.
Первый импульс — быстрый фикс
Первая реакция была предсказуемой — добавить команду в allowlist. После добавления запросы на эту команду перестали поступать — проблема была решена. Но именно здесь всё и началось. Дальше возник вопрос: «Почему я разрешаю именно эту команду, а не сотню других похожих?» Это субъективно и не масштабируется, и главное — это не отвечает на вопрос: «Можно ли ей доверять?».
Я начал наблюдать за своими действиями и заметил следующее:rm /tmp/fooя разрешал сотни раз — и без негативных последствий, аkill -9 $(pgrep daemon)я разрешил один раз — и потом потратил час на восстановление окружения. Ключевое наблюдение заключалось в том, что разница между безопасным и небезопасным действием проявляется не в момент, когда я нажимаю Allow, а в последствиях.Так появилась идея создать тулу TrustGate — не просто allowlist, а систему, которая смотрит на мои Allow/Deny, отслеживает последствия и автоматически расширяет allowlist только для паттернов с устойчиво положительной обратной связью.
Напомню, что тула TrustGate здесь лишь как пример — для погружения, а вообще‑то я рассказываю вам про сетап.
Что я не сделал сразу
В типичном «вайб‑кодинге» следующий шаг выглядит так: «Окей, Claude, набросай мне TrustGate.» Ассистент пишет пару сотен строк Python, я пробегаюсь по ним по диагонали, и через неделю у меня хрупкая тула, детали которой я не понимаю.Но я не пошёл писать код — это критически важный момент в этой истории. Вместо этого я попросил Claude объяснить, как он понимает задачу, не выполняя её. Для этого у меня есть команда/wh
/wh= what‑how означает «Не выполняй задачу. Сначала покажи, как ты её понимаешь.»
Это звучит банально, но именно здесь проходит граница между генерацией кода и совместным проектированием. В штатном режиме ассистент работает так: запрос → действие. Для простых задач это идеально — «Поправь typo», «Переименуй переменную», «Добавь кнопку». Но для сложных систем такой режим опасен, потому что ассистент может неверно интерпретировать задачу или выбрать неправильную архитектурную ветку. Это выяснится уже после того, как часть работы будет сделана.
После этой команды ассистент выдаёт структурированный разбор: задача, ожидаемый результат, что будет затронуто, что предполагается, что неясно. И именно здесь вскрылась первая критическая проблема. Claude спросил:
“TrustGate должен работать только с Claude запросами или со всеми системными модальными окнами (sudo, TCC permissions, push-уведомления приложений)?”
Это две радикально разные системы: одна — на Python с парсингом JSONL, вторая — на Swift с AX‑мониторингом системы. Если бы я пропустил/wh, мы бы пошли во вторую сторону и потеряли бы пару дней. Так появился первый принцип методологии: Understanding‑first, action‑last.
Дальше начался цикл уточняющих вопросов и ответов, и один из них оказался поворотным.
Ассистент: «Какой режим автоматизации выбрать: auto‑add при достаточном количестве positive outcomes, weekly digest с предложениями или только статистика без действий?»Я: «Мне не нужен контроль там, где он мне не нужен — для этого есть ты. Но ты должен учиться не на моих решениях, а на их последствиях. Я могу разрешить, и всё будет хорошо, а могу разрешить, и через час всё сломается. Trust score должен расти от тишины после Allow, а не от самого Allow.»
Так появился второй принцип: Outcome‑driven, не output‑driven. Тула учится на последствиях — упало ли что‑то, откатил ли я изменения, появились ли регрессии. Наш процесс тоже: ассистент не доверяет хорошо написанной спеке, он доверяет моему ревью на неё — не была ли она отвергнута в следующих нескольких итерациях.Логика простая: я хочу осторожную тулзу, которая скорее не доверится, чем доверится зря. В коде TrustGate это превратилось в формулу:
trust score: score = (positive − 10·negative − 2·denied) / (samples + 1)
И здесь случилось самое интересное: метод разработки начал отражать свойства самой тулзы. TrustGate учится через feedback loop, и процесс проектирования TrustGate тоже начал строиться через feedback loop. Мы начали оценивать ассистента не по качеству текста и «умности» рассуждений, а по последствиям его решений через несколько итераций.
Семь принципов, которые проявились дальше
После 4–5 проходов по спеке и полной её переписи каждый раз, я попросил ассистента отрефлексировать: «Что мы фактически делаем? Какие правила применяем?» Так появились семь принципов:
1. Understanding‑first, action‑last.До любого крупного решения —/wh= what/how. Сначала понимание — потом действие.
2. Full rewrites > incremental diffs.Каждый серьёзный архитектурный пивот → полное ревью спеки. Не patch и не incremental. Почему? Потому что incremental‑подход со временем разрушает целостность системы: куски старой логики и новые предположения начинают объединяться и противоречить друг другу. Полный ревью заставляет заново собрать систему как целое. TrustGate переписывался шесть раз. И каждая версия была лучше предыдущей.
3. Atom decomposition вместо time estimates.В какой‑то момент Claude сказал: «Stage 0 займёт 1–2 часа». Мы остановились и заменили time estimates на атомы с понятными acceptance criteria. Запрещены фразы вроде «это займёт 1–2 часа». Например:
Acceptance
Расширить tuple поддерживаемых инструментов + добавить ветку рендера для Bash
./tests.sh— 28/28 PASS, dry-run с tool=Bash возвращает корректный блок
Расширить fast-path regex в hook'е
manual dry-run Bash → появляется prompt в диалоге
Sensitive-command check (regex-список:sudo,rm -rf /,kill -9,dd if=...)
тест для каждого опасного паттерна → auto-deny
Группа тестов=== Bash ===вtests.sh(6-8 кейсов)
все PASS, включая новые
Решение про Read/MCP — отдельные атомы или transcript fallback only
конкретное решение зафиксировано вRules.md
Заметь: ни в одном атоме нет фраз «разобраться», «подумать», «понять». У каждого есть проверяемое условие готовности: тест прошёл, файл изменён, dry‑run вернул нужный результат. Ответ всегда однозначный — да или нет. Никаких «почти готово» и «на 90%».
4. Auto‑checkpoints на критических переходах.Перед коммитом, большим изменением или созданием файла ассистент обязан провести структурированный аудит. Главное правило —file:lineили ничего. У меня это/au.
/au— это последний взгляд критическими глазами перед тем, как сказать «done». Каждая находка в аудите обязана указывать пальцем на конкретное место в коде или иметь воспроизводимый сценарий. Без пальца — не находка. Запрещены формулировки «стоит подумать о безопасности», «хорошо бы добавить тесты», «consider refactoring». Это убивает 80% обычного бесполезного code review.
5. Empirical verification > рассуждения.Если можно проверить — проверяем. Не «кажется, должно работать», а запускаем тест, делаем dry‑run, воспроизводим. Тридцать секунд реального запуска почти всегда ценнее длинных рассуждений.
6. Asymmetric runaway = Outcome‑driven, не output‑driven.Один реальный провал важнее десяти успешных шагов. Почему так «несправедливо»? Потому что последствия не симметричны. Десять правильных edits экономят, условно, час суммарно, один неудачный edit может стоить двух часов восстановления. Это не пессимизм, а наблюдение: скрытая ошибка работает против тебя дольше, чем явный успех — на тебя.
7. Independent judgement, не consensus‑seeking.Ассистенту запрещено отвечать «как скажешь», «выбирай ты», «оба варианта хорошие». Он обязан аргументировать все свои предложения — почему да, почему нет — и давать рекомендацию.
Как этим управлять, чтобы оно реально работало
Если посмотреть на это как на последовательный процесс, то это:Раунд 1.
- Описываешь идею +/wh
- Получаешь понимание задачи с описанием и списком «темных углов»
- Запрашиваешь решение по «темным углам»
- Изучаешь, задаешь вопросы, накидываешь решения
- Собираешь скоуп финальных решений для раунда 1
- На скоуп предыдущего раунда применяешь/au
- Получаешь аудит: слабые места, риски, нерешенные вопросы и список «темных углов»
- Изучаешь, задаешь вопросы, накидываешь решения
- Собираешь скоуп финальных решений для раунда 2
Повторяешь раунд 2 до тех пор, пока список «тёмных углов» не сведётся к одному или двум. Для примера, в первом раунде этот список может быть over 20.
Я упаковал методологию в slash‑команду /sb (от spec‑build), которая лежит в~/.claude/commands/sb.md— это просто markdown со служебными метаданными, который Claude Code загружает в контекст разговора при вызове команды. После одной команды/sbв начале сессии ассистент работает под методологией до явного/stop-sbВнутри файла — три блока, которые я считаю критическими.
1. Автоматические проверки
Список триггеров, на которые ассистент обязан реагировать самостоятельно — без моего напоминания:
- Я описываю задачу → ассистентиспользует 1. Understanding‑first, action‑last
- Ассистент готов дать time‑estimate → использует 3. Atom decomposition
- Обсудили design‑решения без финализации → 2. Full rewrites
- Готов commit / create file / большое изменение → 4. Auto‑checkpoints
- Склоняется к consensus («выбирай ты») → 7. Independent judgement
- Совершил destructive op → 5. Empirical verification/6. Asymmetric runaway
Ключевой посыл: проактивность со стороны ассистента. Не я триггерю их — а он. Раньше я был дирижёром: говорил/wh,/au— собирай флоу в нужные моменты. Вся нагрузка была на мне. С/sbассистент становится главным дирижёром, я — редактором с правом вето.
2. Фразы переопределения
Любую контрольную точку можно отменить. Все переопределения — через слэш..
- /skip-ritual— пропустить текущий checkpoint
- /atom— принудительный atom decomposition
- /no-wh— пропустить understanding‑articulation для текущего запроса
- /independent— own judgement с +/-
- /stop-sb— выйти из методологии до конца сессии
- /sb calibrate quieter|louder— снизить/повысить частоту checkpoint‑ов
- /sb retro— structured отчёт за сессию
3. Известные ограничения заранее описаны
Любая методология — это набор правил с конкретными границами применимости. Я фиксирую ограничения явно — не как отказ от ответственности, а как карту: где система работает надёжно, где — на собственный риск.
1. Ассистент сам себе судья.Ассистент пишет инструкции, сам их выполняет, сам отчитывается в/sb retro. Объективности нет. Поэтому я периодически прошу собрать retro вручную, не доверяя автогенерации.
2. Потеря фокуса на длинных сессиях.При большом объёме методология может перестать применяться — не потому что забыл, а потому что свежий запрос перетягивает внимание с раздела «правила» на раздел «вот этот конкретный баг». Что делаю: повторно вызываю /sb. Не элегантно, но работает.
3. Размытые сигналы ловятся не всегда. Триггеры с чёткими условиями работают в ~85–90% случаев. Размытые сигналы — ~40–60%. То есть половину моментов, когда ассистент перестаёт мыслить самостоятельно и начинает подстраиваться под меня, я ловлю вручную, а не он сам. Что делаю: для критических пунктов есть команды/independentи/no-wh— можно форсировать вручную, не дожидаясь ассистента.
4. Зависимость от качества модели. Методология опирается на три способности ассистента: удерживать контекст длинной сессии, понимать русский язык контекстуально, формировать собственную позицию и аргументировать её. На моделях слабее эти три способности деградируют. На каких именно — я не валидировал систематически.
Заключение
Я начал день с раздражения от 671 клика, а закончил с новой тулой и сетапом, который сэкономит мне время в будущем.Spec‑build — не панацея. Я не буду применять её к bug fix«ам, к рефакторингу, к „поправь дату в README“, но буду применять при разработке новой тулы с нетривиальной архитектурой, для многостейджевой системы с зависимостями, для решений с необратимыми последствиями (миграции, формат хранения, границы безопасности) и кросс‑проектной интеграции (моя тула X использует чужую тулу Y).Самый честный тест этого сетапа: „Если я не применю spec‑build, насколько мне будет жалко через неделю?“. Если „сильно“ — значит, нужно применять. Если „не очень“ — не нужно.»
И ещё один личный итог. Я заметил, что больше не работаю с ассистентом как с инструментом — я работаю с ним как с методологически грамотным джуниором, который иногда умнее меня в технических деталях, но всегда нуждается в моей проверке. Эта формулировка для меня оказалась более продуктивной, чем «AI‑инструмент» или «AI‑партнёр». Джуниор — потому что он не удерживает долгосрочный контекст и у него нет ответственности. Методологически грамотный — потому что после/sbон сам управляет процессом разработки.
P. S. Оставлю тут пасхалочку на следующие статьи, по которым пока ещё собираю статистику, но которые уже использую каждый день: «Управление голосом», «Notifier — центр отображения системных сообщений», «Самообучение и долгосрочный контекст».