Комментарии 12
Multi-model council cпорная штука. На практике этот подход требует больших затрат токенов и времени. На мой взгляд, более эффективно запросить у одной модели несколько вариантов решений, явно указав критерии типа скорости, надежности или минимализма. Это быстрее, дешевле и часто не уступает по качеству солянки мнений из разных моделей.
Согласен что для большинства задач один запрос с явными критериями дешевле и быстрее. Использую multi-model именно там где ставки высокие: структура базы данных, публичный API или ядро системы, что тяжело переделать. Там 20 лишних минут и $2 на токены оправдывают себя даже если выигрыш 10-15% в качестве решения. На рутинных задачах согласен, один промпт с 3 вариантами работает не хуже.
BurntToast отличный выбор для Windows. У меня macOS поэтому osascript, но принцип тот же. Про MCP для БД согласен, это уже must-have, не опция. Возможно стоило включить в список, но тогда 10 превратилось бы в 15.
1. CLAUDE.md до 8к символов, остальное в отдельные файлы
Ещё важно чтобы эти отдельные файлы модель читала когда нужно и не читала когда не нужно - и это обеспечить уже сложнее.
2. .claude/settings.json — три настройки которые меняют процесс
Пустая трата времени.
Безопасность дают исключительно бэкапы плюс песочница (и не встроенная в Claude Code, а внешняя), ограничивающая доступ агента исключительно файлами проекта и секретами, которые явно прокинули в песочницу. В этом случае худшее, что может устроить агент - удалить файлы проекта (но тут есть ежедневный бэкап) или что-то пушнуть на гитхаб в рамках прав выданного ему токена. Когда это есть, то: claude --dangerously-skip-permissions.
3. acceptEdits — включать выборочно, не глобально
Пустая трата времени.
Намного продуктивнее запретить в AGENTS.md делать коммиты без ревью пользователя, после чего дать модели возможность написать рабочий код проходящий тесты, а уже потом этот код смотреть. Так получается в разы быстрее, потому что не тратится время на ревью промежуточных полурабочих вариантов и ручные подсказки модели для исправления ошибок, который она бы и сама исправила получив обратную связь от линтера и падающих тестов.
4. Hooks как guardrails — три которые работают
Блокировка опасных команд - это театр безопасности, модель всегда это может обойти.
А вот уведомление при получении ответа - да, это QoL фича. Только у меня оно звуковое.
5. Multi-model council для архитектурных решений
Если это встроенная фича, то я такую не нашёл пока. Но вручную так делал. Иногда действительно польза есть, но редко.
Зато я недавно нашёл фичу /advisor и включил потестить. В результате Opus начал ходить к Opus за консультациями (автоматически, по собственной инициативе). Очень забавно за этим наблюдать, но важнее то, что результаты этих консультаций показывают, что как минимум в половине случаев он не зря ходил.
6. Параметры усилий — глубина под задачу
(Тут я не из собственного опыта, так что не могу гарантировать корректность.) Есть мнение, что Opus на medium хуже, чем Sonnet на high. Хуже, но дороже. С другой стороны, Opus на xhigh - как-то уж очень дорого. Поэтому если задача сложная-архитектурная, то Opus на high, а если не сложная или по уже составленному Opus плану - то… DeepSeek V4 Flash. :)
7. Context Rot — распознать и перезапустить вовремя
В целом верно, я раньше тоже так делал. Но в последнее время я перестал тратить своё время на подготовку резюме прошлой сессии - либо прошу его подготовить самого агента, либо тупо /compact и качество ответов восстанавливается само.
8. Правило двух коррекций
По моим наблюдениям, особенно если мы говорим про Opus и модели сравнимого уровня, то это упрямство означает то, что модель иначе видит позиционирование проекта/цель текущей задачи и т.п. расхождение в целеполагании. Очень хорошо лечится добавлением таких "философских" пояснений в AGENTS.md. Иногда в процессе уточнения сам начинаешь, наконец-то, понимать, о чем, на самом деле, текущий проект. :)
А вот с более слабыми моделями - да, нужно декомпозировать или давать примеры.
9. Sandbox mode — разные настройки для разных окружений
Театр безопасности.
10. Skills для lazy-loading специфичного контекста
Да, скиллы - бомба. Особенно если модель верно понимает, когда какой скилл грузить.
По settings.json и acceptEdits: это вопрос сколько прерываний по умолчанию. У меня было 15-20 за сессию, стало 2-3. Если изначально меньше, то да, смысла нет. По безопасности согласен, полной гарантии нет, это friction barrier: чуть медленнее случайно ошибиться. Реальная безопасность только через внешнюю песочницу как ты справедливо написал. По skills солидарен, это лучшее из списка.
Ещё важно чтобы эти отдельные файлы модель читала когда нужно и не читала когда не нужно
это называется скилл
2-3-4-9 - автомод.
7 compact, но оно редко нужно даже на задачах в 100+ стадий, если стоят плагины на контроль контекста
Всю статью не буду комментировать. Несколько советов. В силах и инструкциях пропиши наборы тулов для испольхования. Потому что у него есть встроенный хороший Grep и используя тулы он будет меньше просить баша и грепа. И собственно уменьшит еще твою инициализацию, потому что не будет грузить все на всякий случай и не использовать. Также наврное более принято говорить не о символах, а о токенах. Потому что если файл на 4к токенов (40к символов) то жто нормальный вполне размер.
По тулам дельное замечание, добавлю в settings. По токенам vs символам: сознательно выбрал символы чтобы не зависеть от модели, у разных токенизаторов разное соотношение. Для Claude это примерно 1к токенов = 4к символов латиницы, для кириллицы чуть меньше. Но согласен что в контексте Claude Code правильнее мыслить в токенах.
Так же у себя настраивал . потом с инструкций перешел на специализированных субагентов и скрипты максимально возможно вместо инструкций , инструкции забываются - скрипт 100% выполняется так как написан
Хорошая статья, спасибо - мне особенно полезно было про уведомления о завершении. Поставил себе BurntToast на два события: при завершении задачи и когда Claude запрашивает подтверждение.
По поводу пункта «5 Multi-model council для архитектурных решений» - поделюсь своим вариантом: использую плагин codex-peer-review@agent-peer-review-marketplace: Claude при составлении плана автоматически передаёт его в Codex для критики. Хотя ранее делал это вручную - копировал план в чат с GPT и обратно. Теперь всё происходит прямо в консоли, без переключения контекста.
Для детальной проработки планов - superpowers@claude-plugins-official. Заставляет проходить через детальный брейнсторминг.
MCP для прямого доступа к БД и прочей инфраструктуре уже даже не упоминаю - это базовый уровень.

10 настроек Claude Code для разработчика-архитектора