239 промптов. Столько я написал для portal-frontend, пытаясь объяснить агенту, как устроен проект. А потом попробовал другой подход - пусть агент найдёт контекст сам.
Проблема, которую я не сразу увидел
Сначала казалось, что всё работает. CLAUDE.md с описанием стека, конвенциями именования, паттернами компонентов. Агент читает - агент выполняет. Я описывал архитектуру, структуру папок, как у нас организован стейт.
portal-frontend - фронтенд на React с TypeScript, больше 150 компонентов. Первые месяца два промпты были короткими: краткий контекст, чёткая задача, хорошие результаты. Потом проект вырос - и всё пошло не так.
Кодовая база растёт. Добавляются новые компоненты с новыми паттернами. FormInput переписывался несколько раз, Modal получил новый API, появились хуки, о которых в CLAUDE.md ни слова. Описание контекста устарело - а агент об этом не знал. Когда я добавлял новые страницы и просил агента создать auth-компонент, половина промпта уходила на объяснение структуры - и агент всё равно генерировал что-то не то. Приходилось переделывать, дописывать промпты. Следующий промпт - снова объяснять контекст.
Philipp Schmid из Google DeepMind сформулировал это точнее, чем я мог бы: “Most agent failures are not model failures anymore, they are context failures.” Модель не виновата. Контекст неправильный.
Что сломано в самом подходе
Стандартная схема: человек описывает контекст в промпте, агент читает, планирует, делает. На демо работает. В реальном проекте - нет.
Проблема не в том, что агент плохо читает. Проблема в том, что я описываю контекст плохо. Я не знаю всё о собственном проекте. Я забываю упомянуть детали, которые кажутся очевидными. Я описываю состояние, которое было несколько недель назад.
Агент планирует на основе моего описания - неполного, возможно устаревшего. Отсюда и generic результат.
Инверсия выглядит иначе. Вместо “human → [контекст в промпте] → agent планирует” - “human → [цель] → agent исследует → agent обнаруживает контекст → agent планирует”. Контекст берётся из актуальной кодовой базы, а не из моей головы.
Cursor Blog описал этот паттерн в январе 2026-го: “As models have become better as agents, we’ve found success by providing fewer details up front, making it easier for the agent to pull relevant context on its own.”
Меньше деталей в начале. Больше самостоятельного поиска.
Как работают explore-субагенты
В Claude Code есть паттерн orchestrator-worker. Лид-агент анализирует задачу и запускает специализированных субагентов параллельно. Explore - один из таких субагентов.
Explore-субагент работает в изоляции: только чтение, быстрая навигация, никаких правок. Пока он исследует кодовую базу, его контекстное окно засоряется промежуточными результатами - отклонёнными файлами, тупиковыми поисками. Это нормально. В конце он возвращает только релевантный результат, а не всю историю поиска - контекст основного агента остаётся чистым.
По данным Morph LLM, агенты тратят больше половины времени на поиск контекста. Если поиском занимается сам coding-агент, после нескольких итераций его контекст деградирует - в него попадает мусор из неподходящих файлов. Изоляция explore-субагента решает это.
Для portal-frontend разница была ощутимой. Задача: добавить auth-компонент. Раньше я бы написал: “добавь компонент авторизации, используй наши паттерны” - и потом объяснял бы, что такое “наши паттерны”. Теперь explore-субагент сам находит FormInput, Button, Modal, хуки для работы с API - с конкретными файлами и строками. Основной агент получает реальную карту проекта, а не мою интерпретацию двухнедельной давности.
Результат: код, который не нужно переделывать.
Три фазы explore-субагента
Паттерн, который описывает SkillMD.ai, разбивает исследование на три части.
Сначала - определение глубины. Quick для простых задач: один-два поиска, общая картина. Thorough для сложных: полный граф зависимостей, все импорты, все вызывающие функции, тесты. Агент выбирает глубину под задачу.
Потом - итеративный поиск. Агент ищет широко, извлекает ключевые слова из найденного, идёт глубже по графу зависимостей. Несколько витков: поиск → чтение → гипотеза → следующий поиск. Это не grep по одному паттерну, а рассуждение о том, где искать дальше. Для FormInput в portal-frontend explore-субагент в среднем проходил три таких витка: сначала файлы по имени, затем импорты, затем примеры использования.
В конце - сжатие и отчёт. Не весь путь поиска, а карта: список файлов с диапазонами строк, граф зависимостей, структура паттернов.
ContextPacker работает похожим образом через AST-парсинг. Строит семантический скелет репозитория - функции, классы, типы, - потом приоритизирует файлы по релевантности задаче. Архитектурный подход отличается, принцип тот же: дать агенту ментальную карту, а не загружать всё подряд.
Когда статическая конфигурация всё равно нужна
Есть вещи, которые explore не должен переоткрывать каждый раз. Жёсткие ограничения: не трогать этот модуль, не использовать эту библиотеку, соблюдать такие-то соглашения по коммитам. Это в CLAUDE.md - и это работает.
Проблема начинается, когда пытаешься в CLAUDE.md описать паттерны кодовой базы. Паттерны меняются. Конвенции эволюционируют. Документация устаревает быстрее, чем её обновляют.
Консенсус к началу 2026-го: CLAUDE.md как guardrails, автоматический discovery как source of truth. Ручной контекст для стабильных правил, explore-субагент для паттернов кодовой базы.
Anyline применили это на серьёзном масштабе: шесть репозиториев, несколько платформ, работа растянутая на несколько недель и сессий. Они создали мета-репозиторий с картой всей системы - что где живёт, как связаны репозитории, что сейчас в работе. Агент начинал каждую сессию с исследования этой карты. Ноль потерь контекста между сессиями.
Исследование Codified Context на реальном production-проекте с сотнями тысяч строк кода показало похожий результат. Вместо одного универсального агента - набор специализированных: для безопасности, производительности, документации. Каждый с минимальным специфичным контекстом. Система прошла сотни сессий разработки без деградации качества.
Что это меняет
Раньше я был архитектором контекста. Я описывал проект, решал, что важно упомянуть, обновлял CLAUDE.md после каждого большого изменения. Это не масштабировалось. Я не успевал, я забывал, я описывал своё понимание - а не реальное состояние кода.
Теперь агент сам исследует кодовую базу перед планированием. Я формулирую цель. Агент смотрит, что реально есть в проекте, планирует на основе актуального состояния.
Моя роль изменилась. Я настраиваю систему: что в CLAUDE.md, как работают explore-субагенты, какие ограничения жёсткие. Это работа один раз, а не каждый промпт.
Shoeb Ali из NEXORA.AI сформулировал это так: “Prompt engineering gets you the demo. Context engineering gets you to production - and keeps you there.”
239 промптов на portal-frontend. Большинство из них - это я объяснял агенту то, что он мог найти сам.
Дополнительно: Cursor Blog “Dynamic Context Discovery” (Jan 2026), Codified Context - arXiv:2602.20478v1 (Feb 2026), SkillMD.ai “How to Build explore-codebase Agent Skill”, Anyline “In Which We Give Our AI Agent a Map” (Mar 2026)