Управление контекстом при работе с AI-агентами: как сохранить понимание системы и не тратить время на восстановление

В статье на vc.ru Александр Некрашенко пишет, что Claude Code и Codex сделали код дешёвым ресурсом, а главным узким местом стало не написание строк, а понимание системы. Для бизнеса это означает сдвиг в управлении разработкой: команда может быстро получить много кода, но потерять архитектурную память и начать тратить время не на выпуск продукта, а на восстановление контекста. Решение уже не в том, чтобы просто дать людям ещё один агент, а в том, чтобы управлять тем, что агент получает на вход и что возвращает в систему на выходе.

Что именно изменилось в процессе разработки

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

AI-агенты убрали этот побочный эффект. Теперь разработчик часто делает только две вещи: формулирует задачу и объясняет её агенту. Дальше Claude Code, Codex или другой инструмент предлагает вариант решения и пишет код сам. С точки зрения скорости это удобно. С точки зрения управления системой — уже не так удобно, потому что код появляется быстрее, чем успевает появиться общее понимание, зачем он такой и как он связан с остальным продуктом.

Автор статьи предлагает смотреть на новый цикл иначе:

• было: задача → код → документация;
• стало: контекст → генерация → контекст.

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

Как это бьёт по срокам, деньгам и контролю

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

Для бизнеса тут есть три практических последствия.

1. Сроки растут не на написании кода, а на согласовании смысла.
   Если контекст разбросан между Jira, Confluence, GitHub Issues и пулл-реквестами, человеку приходится сначала собрать картину, а потом ещё раз разложить её обратно по местам.
2. Риск ошибок смещается с синтаксиса на архитектуру.
   Агент может быстро сгенерировать тысячи строк, но если у команды нет общей модели системы, новые фрагменты начнут противоречить друг другу. Код будет написан, а система — расползаться.
3. Контроль над продуктом слабеет.
   В статье есть жёсткая, но точная мысль: если код понимает только агент, хаос в коде превращается в хаос в команде. Аналитик приходит уточнить, как устроена новая фича, а разработчик уже не может внятно объяснить, почему система собрана именно так.

Вот короткая рабочая рамка для оценки такого процесса:

Если у команды нет ответа хотя бы на два пункта из этой таблицы, AI-агенты, скорее всего, ускорят производство кода, но не улучшат управляемость продукта.

Как собрать рабочий цикл вокруг контекста

Практический вывод из материала простой: нужно перестроить не инструмент, а цикл работы. Не «сначала написать, потом как-нибудь объяснить», а «сначала собрать контекст, потом сгенерировать, потом вернуть знания в систему».

Для этого нужен минимальный, но дисциплинированный порядок.

1. На входе агенту нужен не только запрос, но и рамка.
В эту рамку входят: цель задачи, ограничения по архитектуре, существующие решения, стиль кода, зависимости, рискованные зоны. Иначе агент будет оптимизировать только локальный фрагмент, а не продукт как целое.

2. Генерация должна идти поверх понятного контекста.
Сама модель или инструмент вторичны. Claude Code, Codex или другой агент полезен ровно настолько, насколько точно вы объяснили ему систему. Чем слабее вход, тем дороже потом правки.

3. На выходе нужно не просто принять код, а вернуть знания обратно.
Это может быть короткое описание решения, обновление спеки, комментарий в задаче, заметка в Confluence или структурированный PR-описатель. Важен не формат, а факт: система после итерации должна знать больше, чем до неё.

4. Ответственность нужно сместить с строк кода на объяснение системы.
Разработчик в новой модели отвечает не только за то, чтобы код работал, но и за то, чтобы было понятно, почему он работает именно так. Это и есть разница между разовой генерацией и управляемой разработкой.

Если говорить языком управления, контекст — это не просто информация, а актив, который нужно поддерживать и развивать.

Как внедрить управление контекстом в команде

Переход к контекстно-ориентированной разработке требует не только изменения mindset, но и конкретных практик. Вот несколько шагов, которые помогут внедрить этот подход.

1. Создайте единое хранилище контекста.
Определите инструмент, где будет фиксироваться архитектурная информация: Confluence, Notion, внутренняя вики или даже структурированные файлы в репозитории. Важно, чтобы это было одно место, куда все члены команды обращаются за пониманием системы.

2. Введите обязательный этап сбора контекста перед задачей.
Перед тем как дать задачу агенту, разработчик должен ответить на вопросы: какую проблему решаем, какие есть ограничения, какие части системы затрагиваются. Это можно оформить как чек-лист в задаче.

3. Автоматизируйте возврат контекста.
Настройте шаблоны для PR-описаний, которые включают раздел «архитектурное решение». Используйте CI/CD для проверки, что документация обновляется вместе с кодом.

4. Проводите регулярные ревью контекста.
Раз в спринт или месяц команда должна проверять, не устарела ли документация, не появились ли новые архитектурные решения, которые не зафиксированы.

5. Обучайте команду работе с контекстом.
Проведите воркшопы по тому, как правильно формулировать задачи для AI-агентов, как документировать решения и как эффективно использовать единое хранилище.

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

Заключение

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

Источники

1. Статья Александра Некрашенко на vc.ru: Контекст важнее кода: как не потерять понимание системы при работе с AI-агентами
2. Документация Anthropic по Claude Code: Claude Code Overview
3. Статья о Codex от OpenAI: Codex: AI for Code Generation

Генерация изображения

• Модель: gpt-5-image
• Провайдер: openrouter