Crucible Code — системное мышление для программистов

13 декабря 2025

Crucible Code — системное мышление для программистов hero image

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

И вот, контекст размазан, гипотезы генерируются хаотично, проверяются интуитивно (“вроде работает”, “это просто должно сработать”), и либо не записываются вовсе, либо теряются в чатах, грязных черновиках, бесконечных “Save for later” в Слаке.

В итоге – либо прыжок к первому решению, которое “звучит разумно” (привет, предвзятость), либо analysis paralysis.

Это не всегда, и вовсе не обязательно проблема навыков. Это проблема отсутствия инфраструктуры и системы для мышления.

Я вдохновился First Principles Framework’ом и сделал crucible-code, чтобы попытаться эту инфраструктуру дать широкому кругу разработчиков.

В прошлое воскресенье я участвовал в семинаре Мастерской Инженеров Менеджеров, где Анатолий Левенчук рассказывал про FPF.

Что же это такое? Это мощнейший фреймворк системного мышления — эссенция лучших практик системного мышления и первых принципов. Он сложный, объемный и невероятно крутой.

Анатолий рассказывал что даже LLM, которым весь FPF в контекст не влезает (там 3348537 символов, что примерно 837000 токенов), на удивление хорошо работают, если файл-спецификацию FPF просто прикрепить к чатику ChatGPT.

Анатолий подчеркнул, что осознанно не пытается “упростить” FPF до уровня кода или утилит, потому что целевая аудитория намного шире чем инженеры-программисты.

Но я-то программист :) И вот я подумал – а почему бы и да?

Встречайте, крохотный инструмент на базе FPF для повседневной работы инженера (и не обязательно программиста!) – Crucible Code на GitHub

Что это такое (стараюсь простыми словами)

Crucible-code – это набор команд для Claude Code CLI агента, которые превращают его в методичного системного архитектора.

Он проводит вас через ADI цикл:

  1. Abduction (Генерация гипотез) — накидываем варианты, от скучных до радикальных.
  2. Deduction (Логическая проверка) — ищем противоречия, не написав ни строчки кода.
  3. Induction (Эмпирическая проверка) — тесты, бенчмарки, ресёрч.

На выходе вы получаете не кусок кода, а Decision Rationale Record (DRR) — документ, где в сказано: “Мы выбрали решение X, потому что факты Y и Z указаывают на то, что это решение подходит. Мы отвергли решение W, потому что тесты показали риск N. Нужно пересмотреть решение, если нагрузка вырастет в 10 раз”.

Только там это расписано с некоторыми метаданными и чуть большей степенью формальности.

Чуть позже мы вернемся к этому циклу и рассмотрим его подробнее.

Один из главных принципов: External Transformer

Идея вот в чем: система не может трансформировать сама себя. Нужен внешний агент.

В нашем случае – это ВЫ.

Claude Code генерирует гипотезы, ищет улики, пишет планы. Но мы сами принимаем решение на каждом этапе. Человеку тут — тот самый внешний трансформер. Так что Crucible Code делает все чтобы не давать пользователю расслабиться и пропустить неудобные вопросы.

Троянский конь системного мышления

Первая версия была просто набором шагов и в основном только ADI, без дополнительных формальностей из FPF.

Но в версии 2.1.0 я пошел дальше и все таки спрятал сложную онтологию FPF “под капот”. Прелесть в том что вам не нужно знать FPF, чтобы хотя бы в какой то степени им пользоваться, цикл команд в Crucible Code сам заставляет следовать принципам.

Цикл выглядит как то так:

1. Agentic Init & Context Awareness

Когда вы запускаете /fpf:0-init, Claude Code создаёт структуру директорий для работы по FPF. Дополнительно он сканирует ваш репозиторий чтобы понять контекст. Да, как обычный init в агентских cli, но с большой вероятностью вас проведут по интервью чтобы заземлить контекст проекта еще больше: — “Я вижу Python и Django. Какой у нас бюджет? Какой ожидаемый Scale (100 rps или 100k rps)? Какие есть жесткие ограничения?”

Результат записывается в .fpf/context.md. После этого любая гипотеза проверяется не в вакууме, а с оглядкой на этот контекст. Claude Code сам скажет: “Эта идея конечно очень крутая, но чтобы натренировать такую нейросеть нам потребуется GPU, а в контексте сказано ‘low budget‘“.

2. Строгое разделение: Метод vs Работа

В FPF есть принцип Strict Distinction. В инструменте это реализовано так: любая гипотеза теперь делится на две части:

  1. The Method (Design-Time) — План. Рецепт. Что мы вообще хотим сделать?
  2. The Validation (Run-Time) — Улики. Тесты. Логи. То, что произошло на самом деле.

Работаю с FPF вам будет намного сложнее путать “я придумал, как это сделать” с “я доказал, что это работает”.

3. NQD (Novelty, Quality, Diversity)

Когда вы запустите fpf-1-hypothesize, Crucible Code не просто накинет несколько гипотез на исследование, нет – он обязан их классифицировать:

— Conservative: Проверенное, надежное решение. — Novel: “Современный”, энтузиастичный подход. — Radical: Рискованное, но потенциально мощное решение.

Это страхует от зацикливания на том, что вы и так знаете.

ADI Цикл в приближении

Фаза 1: Abduction — “А какие вообще есть варианты? Что нам с этим всем делать?” Команда /fpf-1-hypothesize.

Вместо того чтобы кидаться писать код первого пришедшего в голову решения, мы генерируем некоторое пространство вариантов. Claude Code предложит 3-5 гипотез разной степени новизны и сложности.

Фаза 2: Deduction — “Где тут логическая дыра?” Команда /fpf-2-check.

Мы ещё не пишем имплементацию, нееет, до этого еще далеко :) На этом этапе мы проверяем гипотезы на прочность логически (вместе с LLM).

— “Если мы начнем клепать микросервисы (гипотеза), а у нас в команде 2 джуна (контекст), 1 миддл и нет инфраструктурных инженеров – то мы умрем на этапе девопса”.

Гипотеза отбрасывается до того, как вы потратили 2 недели на настройку Kubernetes. А потом полтора года страдали от стремительно усложняющейся архитектуры и инфраструктуры.

Фаза 3: Induction — “Talk is cheap. Show me the numbers.” Команды /fpf-3-test (локальные эмпирические тесты) и /fpf-3-research (внешний поиск, например – WebSearch и WebFetch в интернете).

Оставшиеся после дедукции гипотезы мы проверяем боем. Напиши прототип. Запусти бенчмарк. Найди документацию. Если мы чувствуем что “улик” для работы с гипотезами мало, то мы можем воспользоваться fpf-3-research, собрать внешнюю информацию и уже затем, потенциально более тщательно, вернуться к проверкам через /fpf-3-test.

Фаза 4: Audit — “Самое слабое звено - не значит бесполезное” Команда /fpf-4-audit - Это единственная опциональная команда, которую можно пропустить и перейти сразу к пятому шагу, но я настоятельно рекомендую никогда ее не пропускать, особенно если вы работаете над действительно сложным решением, и/или решением которое может сильно повлиять на качество вашей системы.

На этой фазе работает принцип WLNK (Weakest Link): смысл его в том, что уверенность во всем решении равна уверенности в самом слабом доказательстве. Если бенчмарк отличный, но документация явно говорит “Это сырое апи, не используйте его в проде” — решение скорее всего ненадежно.

Audit — это фаза bias-check и WLNK анализа. Тут Claude проверяет:

Фаза 5: Decision — “Фиксируем” Команда /fpf-5-decide Claude собирает всё вместе: контекст, гипотезы, улики, риски. Но именно вы - “внешний трансформер” должны выбирать победителя. Тут создается тот с самый Design Rationale Record который я уже упоминал.

Ну в общем то – все! Помимо DRR в проектной директории .fpf остаются собранные улики которые пригодятся в будущем - либо для новых циклов работы по FPF, либо… ну например чтобы вспомнить о решениях, или написать хорошую документацию по проекту.

Реальный кейс: Легаси Монолит, Операционной и Технический Долг

Задача прямо сейчас: есть легаси монолит и долг в технических и операционных решениях. Ничего криминального, типичный стартап. Нагрузка на команду и меня самого тоже “типичная” для стартапов.

Спустя полтора месяца сотрудничества мне в принципе понятны основные направления проблем, но не до конца ясно за что именно хвататься первым. А выбирать надо так, чтобы эффект от решения был максимальным – улучшение должно быть кратным.

Хотя, решение за что хвататься уже было принято, я решил проверить Crucible Code именно на этой проблеме. Мне показалось что задача с довольно размытым контекстом и явно выходит за рамки одного монолита.

Запустил /fpf-1-hypothesize. Claude предложил:

/fpf-2-check продолжил сразу выбросив H2. У нас нет возможности замедлять разработку или обучать паттернам проектирования текущую команду, потому что DDD требует высокой квалификации, которой (судя по контексту) пока недостаточно.

/fpf-3-test: Claude запустил существующие модульные тесты. Оказалось, тесты бегут быстро (2с), но падают. Быстрая настройка и запуск статического анализатора (H3) показала 350+ ошибок.

В итоге на /fpf-5-decide мы выбрали гибрид H1 + H3 (Чиним текущие тесты, пишем новые и внедряем их в CI + бейслайн статического анализатора выше которого (по числу нарушений) подниматься при будущих изменениях кодовой базы мы уже не дадим. H2 (рефакторинг) отложили до лучших времен.

Вся работа заняла ~25 минут.

Можно сказать “Ну итак наверное было понятно что делать, да”. Как я сказал ранее, да – насмотрешись на код и процессы я склонялся к тому что надо решать боттлнек с тестированием и линтерами. Но я лишь склонялся. После FPF сессии выбор был железобетонный, подкрепленный доказательствами и зафиксированный документально.

Воспользовавшись артефактами от Crucible Code я создал Story таску в Jira и скоро она поедет в работу (Тому же Claude Code, например.)

Без этой системы и артефактов мы бы еще неделю качали головами.

Почему не SuperClaude, ну или AgentOS какой нибудь?

Сейчас есть много “комбайнов” вроде SuperClaude или AgentOS, которые забивают контекст толстенными промптами или скиллами, создают 15 “специализированных” субагентов и пытаются “думать за тебя”, автоматизировать все. Это история скорее про вайб-кодинг – “Дорогой клауд код, сделай мне красиво”.

Имеет место быть, но место это очень далеко от инженерии.

Crucible Code — это экзоскелет, а не автопилот.

1. Минимальный оверхед.

Ваша обычная работа с Claude Code остается обычной. FPF включается только по команде. Да, в репозитории Crucible Code я делюсь своим CLAUDE.md, но скорее просто ради примера. Я практически уверен что Crucible Code заработает хорошо без каких-либо дополнительных указаний.

2. Никакой магии.

Вы видите каждый шаг, вы думаете вместе с Claude Code.

3. Структурированная Память.

Файл session.md хранит состояние вашего совместного размышления во время самой сессии. Дополнительно – хранятся все гипотезы, их статусы, DRR записи, evidences. Все это связано друг с другом через метаданные в файлах. Даже если Claude (или вы) “забудет” контекст диалога, он перечитает документы в .fpf и вспомнит: “Ага, мы отвергли MongoDB, потому что у нас нет админа”.

Кстати, в Crucible Code есть дополнительные команды не связанные с ADI циклом:

/fpf-status — где мы сейчас?

Показывает текущую фазу цикла, список гипотез с их статусами (L0/L1/L2/invalid), и подсказывает логичный следующий шаг. Полезно когда вернулся к задаче после перерыва, потерял сессию или “потерял нить”

Более чем ожидаемо что работая над сложной задачей вы зависните на стадии /fpf-3-* на несколько часов и забудете что там за этап был вообще в Crucible Code.

Ну или вам надо продолжить в понедельник… Crucible не просто разбрасывае хлебные крошки, он оставляет за собой целые батоны хлеба.

Да, кстати, у меня бывало так что после /fpf-3-test оставались отличные скрипты, которые после /fpf-5-decide прозрачно переносились в основной код. Claude Code при работе по Crucible Code циклу все еще следует вашим указаниям в CLAUDE.md по поводу стиля кодирования и требованиям.

/fpf-query — поиск по наработанной базе знаний.

Можно искать по гипотезам, уликам, прошлым решениям. Фильтрация по уровню достоверности (L0, L1, L2, invalid). Например: “покажи все проверенные улики про кэширование, мы в прошлом месяце что то исследовали по этому поводу” или “какие гипотезы мы выбросили неделю назад по задаче XXX-123 и почему”

/fpf-decay — проверка свежести улик.

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

Когда использовать Crucible Code

Не побоюсь сказать, но эти команды могут стать незаменимым помощником в следующих случаях:

Crucible Code и FPF вам совершенно не нужны:

Quick Start

  1. Забирайте репозиторий:
git clone https://github.com/m0n0x41d/crucible-code.git
./install.sh /path/to/your/project

или глобально (команды будут скопированы в ~/.claude/):

./install.sh -g
  1. Инициализируйте (Claude просканирует проект и задаст пару вопросов):
claude
/fpf-0-init
  1. Начните думать над вашей задачей системно:
/fpf-1-hypothesize "Кажется что нам все таки не стоит использовать redis для очередей потому что..."

Мышление — может быть инженерным процессом. Его можно отлаживать, оптимизировать и версионировать. Попробуйте!

p.s. Ах да, вы уже догадались что Crucible Code можно использовать не только для программной инженерии? И что вам ничего не мешает в ADI цикле пользоваться всякими MCP и прочими уловками? Хе хе хе!