После шести месяцев ежедневной работы с Claude Code разработчик зафиксировал 10 конфигураций, которые снижают потери времени на исправление действий агента с 10–15 часов в месяц до значительно меньшего. Ниже — суть каждой из них.
**1. CLAUDE.md: жёсткий лимит 8 тыс. символов**
| Уровень | Команда | Поведение агента | Когда использовать |
|---|---|---|---|
| Низкий | /effort low | Быстрый черновик без объяснений и плана | Утилиты, скрипты, разовые задачи |
| Средний | /effort medium | Краткий план, затем реализация | Стандартные фичи, исправления, рефакторинг |
| Высокий | /effort high | Развёрнутый план, затем реализация | Новые компоненты, изменения публичных API |
| Максимальный | /effort max | Анализ, план, одобрение, реализация, отчёт — остановка после каждого шага | Ядро системы, auth, schema migrations |
Раздутый главный файл — первая и самая дорогостоящая ошибка. К марту у автора CLAUDE.md разросся до 40 тыс. символов: архитектурные решения, стайл-гайд, правила тестирования, доменная модель. Казалось, больше контекста — лучше результат. Нет. Трансформер хуже удерживает информацию из середины длинного документа: агент буквально не замечал правила, которые находились в середине файла. Проверка подтвердила: воспроизвести правило из строки 300 Claude не смог.
Разделение разрешений в settings.json снижает число прерываний за сессию с 15–20 до 2–3.
Решение — жёсткий лимит 8 тыс. символов на главный файл, остальное выносится в `.claude/skills/` и `.claude/specs/` и подгружается по запросу. После рефакторинга главный файл занял 6 тыс. символов, расход токенов на инициализацию сессии упал примерно на 35%.
**2. settings.json: три настройки, которые меняют процесс**
Большинство разработчиков не открывают settings.json вообще. Три изменения дают ощутимый эффект. Первое — разделение разрешений: операции чтения и запуска тестов (`git log`, `git diff`, `npm test`, `grep`, `find`) проходят без подтверждения, деструктивные команды (`git push`, `git reset --hard`, `rm -rf`) требуют явного ок. Число прерываний за сессию упало с 15–20 до 2–3. Второе — Stop hook для логирования: после каждой сессии в файл пишется время и задача. Третье — запрет опасных SQL-операций (`DROP TABLE`, `TRUNCATE`, `DELETE FROM * WHERE 1=1`) на уровне разрешений. Файл settings.json коммитится в репозиторий, и все разработчики в команде получают одинаковые ограждения.
**3. acceptEdits: только с тестом**
acceptEdits убирает запрос подтверждения перед каждым изменением файла. Работает для механических задач: миграция типов JS → TS, переименование, замена импортов, генерация тестов для уже написанной логики. Не работает для новой функциональности, рефакторинга архитектуры и правок в auth, payment, data layer. Кейс из практики: включённый acceptEdits для задачи «почисти неиспользуемые импорты» привёл к тому, что агент заодно переработал несколько сервисов — формально правильно, но хуже существующего паттерна. Итог — полчаса незапланированного ревью. Правило: acceptEdits только если есть автоматический тест, который поймает ошибку.
**4. Hooks как защитные барьеры**
Hooks — shell-скрипты, которые запускаются до или после инструментов агента. Три из них изменили рабочий процесс. Stop hook пишет время и задачу в лог после каждой сессии: через месяц данные показали 2 ч 15 мин с агентом в день и 4–5 сессий — вместо субъективного «работаю иногда». PreToolUse hook блокирует опасные команды по регулярному выражению; за первые три месяца сработал 7 раз, из них 2 раза агент предлагал нежелательную операцию. Notification hook отправляет системное уведомление по завершении задачи — простая вещь, которая убрала привычку смотреть в терминал каждые 30 секунд и позволила реально переключаться на параллельные задачи.
**5. Multi-model council для архитектурных решений**
Параллельные сессии с разными моделями на одну задачу с последующим синтезом результатов. Три запроса с разными приоритетами: Opus — надёжность и явность контрактов, Sonnet — скорость разработки, Haiku — минимальная сложность. Затем четвёртая сессия с Opus синтезирует лучшие части всех трёх с учётом контекста проекта. Занимает 20–25 минут. На последнем крупном рефакторинге (переработка event-driven части системы) это заменило недельную дискуссию в команде и дало более чистое решение, чем обсуждение вдвоём-втроём. Особенно полезно, когда в команде нет второго сеньора для технического ревью.
**6. Параметры усилий: глубина под задачу**
Формализованные уровни проработки в виде skill-файла: `/effort low` — быстрый черновик без объяснений; `/effort medium` — краткий план и реализация; `/effort high` — развёрнутый план для новых компонентов и изменений публичных API; `/effort max` — критические задачи, агент останавливается после каждого шага и ждёт явного подтверждения. На уровне `/effort max` за полгода не было ни одного случая, когда пришлось полностью откатываться.