Claude Code: держите контекст чистым, а контроль — под задачу

Я сижу в Claude Code с релиза — каждый день, на реальных задачах. Успел побыть и скептиком («очередная хайповая штука»), и фанатиком («агент всё сделает сам»). В итоге пришёл к набору правил, которые помогают не скатываться в крайности.

Для меня Claude Code — лучший агент на рынке. Cursor, Gemini CLI, Codex пробовал, но разница ощутимая. Anthropic реально вкладываются в продукт и регулярно добавляют фичи.

Статья для тех, кто начинает работать с Claude Code. Опытным многое будет знакомо, но наверняка что-то зацепит. Две части: как не засорять контекст и как менять подход в зависимости от задачи.

Следите за размытием контекстного окна

Контекстное окно — главный параметр, влияющий на «ум» агента. Чем больше информации в нём находится, тем сильнее деградирует качество ответов: агент начинает пропускать важные детали. Поэтому критически важно держать в контексте только релевантную для задачи информацию.

Агрессивно делайте /clear

Я делаю /clear каждый раз, когда заканчиваю работать над подзадачей — даже если следующая связана с предыдущей. Да, предыдущий контекст может помочь агенту на следующем шаге. Однако лучше прикинуть интуитивно, какая часть оставшейся информации действительно полезна. Если это менее 50%, лучше очистить окно и позволить агенту заново собрать нужные данные.

Не перегружайте агента MCP-серверами

MCP Tools попадают в промпт при каждом запросе — агенту нужны их описания, чтобы решить, какой инструмент вызвать. Проблема в том, что это сильно раздувает контекст: пара MCP-серверов может съесть 50% окна ещё до того, как вы напишете первый запрос. При этом большинство tools вы, скорее всего, не используете вообще.

Что делать:

1. Отключите ненужные MCP-серверы. Если вы раз в месяц создаёте задачу в Jira и createIssue — единственный tool, который используете, лучше отключить этот сервер. Создавайте задачи вручную или заведите отдельного агента в Claude Desktop.

2. Ограничьте список tools. Некоторые MCP-серверы позволяют указать, какие tools подключать. Если ваш сервер это поддерживает — пройдитесь по списку и оставьте только нужные.

К сожалению, в Claude Code пока нет встроенного способа фильтровать tools — всё зависит от поддержки со стороны конкретного MCP-сервера. Многие серверы такой возможности ещё не дают.

Ещё одно ограничение: нельзя подключить MCP tools только к sub-агенту, оставив основной агент «чистым».

Используйте Skills

Skills — это «ленивые» инструкции. Они загружаются в промпт только когда нужны.

Рано или поздно вы столкнётесь с ситуацией: агент решает задачу не так, как принято в вашем проекте. Пишет миграции без IF NOT EXISTS, создаёт endpoints в другом формате, использует не тот стиль логирования.

Первая мысль — добавить правила в CLAUDE.md:

Когда ты пишешь миграции для БД всегда используй IF NOT EXISTS 
инструкцию для колонок, таблиц и т.д.

Это работает, но со временем CLAUDE.md разрастается. Инструкции по миграциям, API, тестам, код-стайлу — всё в одном файле. В итоге системный промпт занимает 30% контекста, а для текущей задачи релевантно процентов 10. Зачем грузить правила по миграциям, если вы пишете юнит-тест?

Skills решают эту проблему. Скилл состоит из заголовка (когда активировать) и тела (сами инструкции). Агент видит только заголовки, а тело подгружает по необходимости. Получили задачу на миграцию — активировался скилл — инструкции в контексте. Пишем тест — скилл про миграции не трогаем.

🗒️ По состоянию на ноябрь 2025 skills работают нестабильно. Агент часто не активирует скилл, даже если задача идеально подходит под описание — это известная проблема, на которую жалуются многие.
Пользователи экспериментирует с решениями: hooks, ручная классификация. Некоторые коллеги вообще переизобретают механизм — складывают инструкции в отдельную папку и прописывают в CLAUDE.md, когда какой файл читать. Как ни странно, работает лучше.
Я пока не заморачиваюсь с кастомизацией — жду фикса от Anthropic, проблема слишком заметная, чтобы её игнорировать. А пока вкладываюсь в точные заголовки скиллов, чтобы повысить шанс активации.

Используйте Sub agents

Sub agents тоже помогают с контекстом, но защищают от другого — от мусора в выводе команд и tools.

Классический пример — запуск тестов. Вывод go test ./... содержит кучу информации, которая агенту не нужна. Зачем ему знать про 200 успешных тестов? Важны только упавшие.

Решение — создать sub-агента через команду /agents. Он получает задачу от основного агента, запускает те��ты в своём контекстном окне и возвращает только суть: какие тесты упали и почему. Основной агент получает чистый, сжатый результат вместо простыни логов.

Меняйте подход в зависимости от задачи

В production подход отличается от vibe-coding, где можно не смотреть на код и следить только за результатом.

Я делю задачи на три типа:

1. Типовые — на 95% состоят из паттернов, которые уже есть в кодовой базе

2. Специфичные — есть уникальные части, требующие особого внимания

3. Абсолютно новые — нужно с нуля разработать важную подсистему

Plan mode для agent-first задач

Типовые задачи отдаю агенту целиком — пусть решает e2e, я т��лько ревьюю результат.

Здесь удобен Plan Mode. Описываете задачу верхнеуровнево, агент строит план, вы корректируете и запускаете выполнение. Обычно я меняю план 1–3 раза, нажимая «Keep planning» и уточняя детали, пока план не устроит полностью.

Итеративный подход для human-first задач

Специфичные задачи разбиваю на этапы. Даю агенту небольшой кусок, смотрю результат, вношу правки, коммичу и перехожу к следующему. Больше контроля, больше качества, но и больше вовлечения — вы ведёте процесс, агент помогает.

Важно: фиксируйте успешные шаги через git commit. Агент часто начинает за здравие, а заканчивает за упокой — и тогда незакоммиченные изменения оказываются перемешаны, откатывать больно.

🗒️ В Claude Code есть команда /rewind для отката неудачных итераций. Я почти не пользуюсь (наверное, зря) и полагаюсь на git. Если у вас есть опыт с /rewind — напишите в комментариях, насколько надёжно работает.

Plan Mode здесь почти не использую — задачи мельче, проще смотреть результат через git diff и корректировать код, а не план.

Не используйте Claude Code для абсолютно новых задач

Для третьего типа задач я вообще отказываюсь от Claude Code. Использую обычную LLM для вопросов, сниппетов и подсказок, но всю разработку веду сам.

Почему? Когда вы пишете новую подсистему с нуля, важно контролировать каждый аспект. Не давать LLM вводить свои подходы. В прототипах — пожалуйста, пусть агент творит. Но в production-коде я хочу точно знать, как всё устроено, и быть уверенным в каждой строчке.

Заключение

Два главных принципа:

Держите контекст чистым. Агресси��но делайте /clear, отключайте ненужные MCP-серверы, выносите инструкции в skills, а шумный вывод — в sub-агентов. Чем меньше мусора в контексте, тем умнее агент.

Подбирайте уровень контроля под задачу. Типовые задачи отдавайте агенту целиком через Plan Mode. Специфичные — разбивайте на этапы и коммитьте каждый успешный шаг. Абсолютно новые подсистемы пишите сами, используя LLM только для подсказок.

Claude Code — мощный инструмент, но не волшебная палочка. Результат зависит от того, насколько осознанно вы им пользуетесь.