Context engineering: навык, заменивший prompt engineering

Ещё год назад половину тренинга я тратил на то, чтобы показать людям «магические» формулировки промптов. «Act as a senior engineer». «Think step by step». «Take a deep breath». Работало — немного. Сегодня эти трюки никого не интересуют, потому что перестали давать разницу. Модели стали настолько хороши, что точные слова почти не решают.

Решает контекст. Получит ли AI правильные файлы, конвенции проекта, архитектуру и ограничения — или нет. Это называется context engineering, и в 2026 году именно этот навык отделяет тех, кому AI реально ускоряет работу, от тех, кто до сих пор жалуется, что «оно генерирует ерунду».

Почему формулировка промпта перестала играть роль

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

И вот суть проблемы. Когда агент ошибается, это редко из-за неправильной формулировки. Почти всегда — потому что он не знал ваш код. Не знал, что у вас есть кастомный error handler и не надо писать try/except. Не знал, что вы фиксируете конкретную версию библиотеки. Не знал, что почти идентичная функция уже лежит тремя папками дальше. Более умный промпт это не исправит — не хватает-то информации, а не инструкций.

Что «контекст» на самом деле значит для coding-агента

Контекст — это не только текст вашего промпта. Это всё, что у агента есть в контекстном окне в момент, когда он начинает работу. И он состоит из нескольких слоёв, которые легко упустить.

• Релевантные файлы — конкретные исходники, которых касается изменение, плюс те, от которых они зависят
• Конвенции проекта — инструкционный файл (CLAUDE.md, rules), стиль кода, именование, паттерны
• Архитектура — как слои общаются друг с другом, где границы, кто за что отвечает
• Прежние решения — почему построено так, а не иначе (ADR, комментарии, история)
• Ограничения — что нельзя менять, какие версии, какие требования к безопасности и производительности

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

Конкретные тактики, которые работают

1. Курируйте файлы, не заваливайте

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

2. Держите инструкционный файл проекта

CLAUDE.md (или эквивалентный rules-файл) — самый дешёвый context engineering из существующих. Вы пишете конвенции один раз, и агент имеет их в каждой сессии. Стек, команды, именование, «всегда делай X, никогда Y». Держите его лаконичным — пара десятков реальных правил, а не стостраничный мануал, которому всё равно никто не следует.

# CLAUDE.md — контекст, который нужен агенту

## Stack
Django 5.2, Django Ninja, PostgreSQL

## Конвенции
- Глобальный ObjectDoesNotExist handler — без try/except boilerplate
- select_related/prefetch_related на каждом queryset с relations
- Все API URL заканчиваются слэшем (/)

## Никогда
- Не трогай миграции, которые уже задеплоены
- Не добавляй зависимости без согласования

3. Используйте retrieval и MCP для живых данных

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

4. Сужайте задачу

«Переделай auth» — плохой контекст, потому что это плохо ограниченная задача. «Перепиши login endpoint в auth/views.py на JWT, сохрани текущую сигнатуру, запусти тесты в auth/tests.py» задаёт агенту чёткие границы. Чем острее scope, тем меньше места для догадок — и тем меньше нежелательных изменений в файлах, которых это не должно было касаться.

Частые способы всё испортить

• Слишком много нерелевантного контекста — завал шумом, в котором тонет сигнал
• Устаревший контекст — сессия, притянутая из прошлой задачи, старые файлы, мёртвые подходы
• Отсутствие ограничений — агент не знает, что нельзя менять, поэтому меняет; не знает версии, поэтому использует не то API
• Предположение, что модель «знает» ваш проект — не знает, пока вы ей не покажете

Устаревший контекст — самый коварный. К третьей задаче в одной сессии агент тащит багаж от первых двух — файлы, которые уже не релевантны, и тупики, которые активно вредят следующей попытке. Новая задача? Новая сессия. Чистый контекст почти всегда побеждает раздутый.

Практический воркфлоу

Когда вы раскладываете context engineering в рутину, он перестаёт быть загадочным навыком и превращается в несколько шагов, которые вы делаете почти автоматически.

• 1. Ограничьте задачу — одно чёткое изменение, а не «исправь всё»
• 2. Выберите файлы, которых это реально касается, и добавьте их в контекст
• 3. Убедитесь, что конвенции и ограничения лежат в инструкционном файле
• 4. Попросите агента описать план и проверьте, что у него верная картина
• 5. Дайте ему работать с feedback loop — запусти тесты, исправь ошибки
• 6. Очистите сессию перед следующей несвязанной задачей

Context engineering — не хайп и не очередной buzzword. Это просто перенос внимания с того, как вы говорите с AI, на то, что вы даёте ей для работы. Этой дисциплине я учу на своих воркшопах на реальном коде команд — потому что как только вы её освоите, вы перестанете бороться с промптом и начнёте реально управлять AI.