Контекст-инжиниринг для coding-агентов: как структурировать сессии и не сойти с ума

Сломанный телефон между вами и кодом

Представьте: вы объясняете junior-разработчику сложную задачу. Сначала он кивает, говорит "понял". Через пять минут задает вопрос, который показывает, что не понял вообще ничего. Вы начинаете сначала. Еще через десять минут он пишет код, который не имеет отношения к изначальной задаче.

Так работают большинство coding-агентов в 2026 году. Проблема не в том, что Claude Code 2.0 глупый (он чертовски умный). Проблема в том, что мы общаемся с ним как с человеком. А он — не человек. У него нет рабочей памяти в нашем понимании. Только контекстное окно, которое постоянно перезаписывается.

Сессия != разговор

Вот где мы все обламываемся. Мы думаем о сессии с агентом как о диалоге. Пилим фичу, обсуждаем, уточняем. В реальности каждая новая реплика в чате — это полная пересборка контекста.

Представьте, что у вас есть стакан с водой. Каждое новое сообщение — это добавление капли подкрашенной жидкости. Сначала вы видите изменение цвета. Потом — все меньше и меньше. Через 20 капель первоначальный цвет воды не имеет значения.

То же самое с контекстом агента. Первые промпты определяют "цвет" всей сессии. Потом их влияние размывается. И если вы не структурировали сессию правильно с самого начала — все, можете начинать заново.

Архитектура сессии: три слоя вместо одного

Типичная ошибка: бросаем агенту задачу и ждем результата. Правильный подход: строим сессию как трехслойный пирог.

1 Фундамент: системный промпт, который не меняется

Это не просто "ты — helpful assistant". Это конституция вашей сессии. Конкретные правила, которые не должны нарушаться никогда.

Плохой пример:

Ты — AI-помощник для программирования. Помоги мне написать код.

Хороший пример (для TypeScript-проекта):

# Роль: Senior TypeScript разработчик

## Обязательные правила
1. Всегда используй строгий режим TypeScript (strict: true)
2. Никогда не используй тип `any` — если не знаешь тип, используй `unknown`
3. Экспортируй только named exports
4. Пиши JSDoc для всех публичных функций
5. Все асинхронные операции оборачивай в try/catch

## Структура ответов
1. Сначала объясни подход (2-3 предложения)
2. Покажи код с комментариями
3. Объясни trade-offs выбранного решения

## Контекст проекта
- Версия Node.js: 20.x
- Фреймворк: Next.js 15
- Стиль кода: Airbnb с модификациями
- Основные библиотеки: React Query, Zod, Tailwind

Разница как между "веди себя хорошо" и уголовным кодексом. Первое можно трактовать как угодно. Второе — четкие статьи.

2 Рабочий слой: задача и ее контекст

Сюда попадает только то, что нужно для текущей задачи. Не вся документация проекта. Не история всех коммитов. Только relevant context.

Как определить, что relevant? Задайте себе вопрос: "Если бы я сам писал этот код, что бы мне понадобилось знать?"

Пример плохого подхода:

Вот весь наш проект (15 файлов, 3000 строк). Напиши функцию авторизации.

Пример хорошего подхода:

# Задача: добавить OAuth авторизацию через Google

## Контекст
- Существующая система использует JWT, токены хранятся в cookies
- В `src/lib/auth.ts` уже есть базовая структура (приложу ниже)
- Нужно интегрировать с `next-auth` версии 5.0
- Требования безопасности: no implicit flow, PKCE обязателен

## Критические файлы
typescript
// src/lib/auth.ts (только релевантные части)
export interface UserSession {
  id: string;
  email: string;
  role: 'user' | 'admin';
}

// ... остальной код

Видите разницу? Во втором случае агент не тратит 80% контекста на чтение кода, который не нужен для задачи.

3 Динамический слой: история взаимодействия

Самое сложное. Как сохранять контекст между сообщениями, когда контекстное окно ограничено?

Решение: не пытайтесь сохранить ВСЕ. Сохраняйте только КЛЮЧЕВЫЕ решения.

Техника: контекстные якоря

Когда сессия разрастается до 50+ сообщений (а это происходит быстро), нужно механически возвращать агента в нужное русло.

Контекстный якорь — это периодическое повторение ключевых правил. Не всех. Только тех, которые агент начинает нарушать.

Пример из практики. Пишем сессию про TypeScript. Через 20 сообщений агент начинает предлагать использовать `any`. Вместо того чтобы ругаться, просто вставляем якорь:

[Напоминание: строгий режим TypeScript, тип `any` запрещен, используй `unknown` или дженерики]

Работает лучше, чем "ты же обещал не использовать any!". Потому что это не упрек, это обновление контекста.

Ошибки, которые стоят денег и нервов

Ошибка №1: Монолог вместо диалога

Вы пишете промпт на 500 слов. Объясняете задачу, контекст, технические ограничения, бизнес-логику. Агент читает, думает, выдает ответ. Вы недовольны — он упустил важный нюанс.

Проблема: в длинном монологе модель теряет иерархию информации. Все кажется одинаково важным.

Решение: разбивайте на части с явными маркерами важности.

# ГЛАВНАЯ ЗАДАЧА: реализовать платежную интеграцию

## КРИТИЧЕСКИЕ ТРЕБОВАНИЯ (обязательно):
1. Безопасность: токены карт не хранятся в нашей БД
2. Соответствие PCI DSS

## ВАЖНЫЕ, НО НЕ КРИТИЧЕСКИЕ:
- Логирование всех транзакций
- Retry логика при fails

## ЖЕЛААТЕЛЬНО:
- Поддержка Apple Pay/Google Pay

Ошибка №2: Смешивание абстракций

В одной сессии пытаетесь и архитектуру обсудить, и конкретную функцию написать, и баг пофиксить. Агент путается, потому что каждый тип задачи требует разного контекста.

Правило: одна сессия — один уровень абстракции. Архитектурные решения — в отдельной сессии. Реализация — в другой. Багфиксы — в третьей.

Да, это значит больше сессий. Но каждая из них будет в 3 раза эффективнее.

Ошибка №3: Игнорирование "тока стоимости"

Claude Code 2.0 стоит денег. Каждый токен — деньги. Каждая сессия — деньги. Но мы ведем себя как будто это бесплатно.

Просчитывайте токены заранее. Примерная формула для 2026 года:

• Системный промпт: 500-1000 токенов (оптимизировать до предела)
• Контекст задачи: 1000-3000 токенов (только необходимое)
• Ответ агента: 500-2000 токенов (зависит от сложности)

Если ваша сессия превышает 10K токенов — что-то пошло не так. Скорее всего, вы решаете несколько задач в одной сессии или загрузили слишком много контекста.

Практика: сессия от начала до конца

Давайте пройдем по реальному примеру. Задача: добавить feature flag систему в существующий React-проект.

Шаг 0: Подготовка (делаем ДО открытия чата)

## Файл: project_context.md

### Технический стек
- React 19 с хуками
- TypeScript 5.5
- Zustand для state management
- Vite для сборки

### Существующая структура
- `src/features/` — фичи по domains
- `src/lib/` — утилиты
- `src/types/` — TypeScript типы

### Ограничения
1. Не добавлять тяжелые зависимости (максимум 10KB bundle)
2. Поддержка A/B тестирования из коробки
3. Флаги должны быть доступны и на клиенте, и на сервере

Шаг 1: Инициализация сессии

[Системный промпт]
Ты — senior фронтенд-разработчик, специализируешься на React и TypeScript.

Правила:
1. Всегда предлагай несколько вариантов решения с trade-offs
2. Код должен быть production-ready с учетом линтинга и типизации
3. Комментируй сложные части кода
4. Предлагай оптимизации по производительности

[Загружаем project_context.md]

Задача: разработать систему feature flags для нашего проекта.
Требования:
- Флаги могут быть boolean (вкл/выкл) или multivariate (A/B тесты)
- Управление через админку (будет позже), пока — конфиг файл
- Флаги должны кэшироваться на клиенте (30 секунд)
- TypeScript типы для всех флагов

Шаг 2: Уточняющий диалог с якорями

Агент предлагает решение. Вы видите проблему — нет поддержки серверного рендеринга. Вместо того чтобы начинать спор:

Хороший вариант, но нужно учесть SSR. 
[Напоминание: флаги должны работать и на клиенте, и на сервере]

Как адаптировать решение под Next.js App Router?

Якорь напоминает о критическом требовании, не перезагружая весь контекст.

Что делать, когда сессия пошла наперекосяк

Бывает. Агент "зациклился" на неправильном подходе. Каждое следующее сообщение усугубляет ситуацию.

Не пытайтесь "исправить" сессию. Начинайте новую.

Но! Сначала проведите post-mortem. Почему сессия пошла не туда?

Инструменты, которые не стоит игнорировать в 2026

Контекст-инжиниринг — это не только промпты. Это инструменты, которые управляют этими промптами.

• Cursor с его Codebase Intelligence — не просто "ищет в файлах". Он строит граф зависимостей и загружает в контекст только релевантные части. Если вы все еще копируете код вручную — вы в каменном веке.
• Claude Desktop с файловым менеджером — загружает файлы как семантические чанки, а не просто текст. Разница в качестве ответов — на 30-40%.
• Простые тулы вроде Token Calculator — перед отправкой промпта прикидываете, сколько он будет стоить. Элементарно, но 90% разработчиков этого не делают.

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

Вопросы, которые мне задают чаще всего

Какой длины должен быть системный промпт?

Короче, чем кажется. Идеал — 300-500 токенов. Если больше — вы пытаетесь запихнуть в него то, что должно быть в контексте задачи.

Исключение: когда вы работаете с узкоспециализированным агентом (только security, только performance). Тогда можно 800-1000 токенов, но каждый должен быть на счету.

Нужно ли каждый раз заново загружать контекст проекта?

Зависит от агента. Claude Code 2.0 помнит контекст в пределах одной сессии (чата). Но если вы закрыли чат и открыли новый — все с нуля.

Отсюда правило: длинные задачи — один длинный чат. Не закрывайте его, пока задача не решена. Используйте паузы, якоря, но не начинайте заново.

Как понять, что проблема в контексте, а не в агенте?

Проведите тест: дайте ту же задачу, но с идеально структурированным контекстом. Если результат улучшился — проблема в контексте. Если нет — возможно, агент действительно не справляется с задачей.

В 2026 году в 80% случаев проблема именно в контексте. Модели стали достаточно умными, но они остаются зависимыми от входных данных.

Стоит ли использовать несколько агентов в одной сессии?

Только если у вас есть четкий оркестратор. Вручную переключаться между ChatGPT, Claude и локальной моделью — гарантия потери контекста.

Если идете этим путем, посмотрите нашу статью про суб-агентов. Там разобраны рабочие схемы.

Что будет дальше? (Спойлер: станет проще, но не для всех)

К концу 2026 ожидаем модели с контекстом в 1M+ токенов и эффективным механизмом attention. Казалось бы — вот он, рай. Загрузил весь кодбазу и пиши что хочешь.

Реальность: чем больше контекст, тем важнее его структура. Потому что найти иголку в стоге сена из 1M токенов сложнее, чем в стоге из 100K.

Контекст-инжиниринг не умрет. Он станет более тонким. Вместо "как уместить все в 128K" будем думать "как структурировать 1M токенов, чтобы агент нашел нужное".

Мой прогноз: через год мы будем смеяться над сегодняшними попытками "оптимизировать промпты". Потому что вместо промптов будем строить семантические карты кодбазы, которые агенты смогут навигировать как Google Maps.

Но фундаментальный принцип останется: garbage in, garbage out. Сколько бы токенов ни было, если вы загружаете мусор — получите мусор на выходе.

Начните со структуры сегодня. Потому что когда придут модели на 1M токенов, те, кто научился работать с 128K, будут иметь огромное преимущество.

Они будут знать не только как загружать контекст, но и как его организовывать. А это — следующий уровень.

Подписаться на канал