Почему ИИ в разработке ПО эффективен не из-за умных промптов, а из-за правильного контекста

Почему этот гайд написала Фора Софт

Фора Софт выпускает программные продукты с 2005 года и интегрирует ИИ-функции в решения клиентов с 2018 года. С 2024 года мы применяем подход Agent Engineering на каждом проекте — файлы памяти, правила, выбор модели, права доступа и переиспользуемые модули задач стали частью нашей повседневной работы. Мы известны как эксперты по интеграции искусственного интеллекта, разработчики ИИ-агентов на базе LiveKit, создатели голосовых ИИ-агентов для звонков и специалисты по ИИ-распознаванию видео.

Этот гайд — версия разговора, который мы каждую неделю ведём с инженерными лидерами, разочарованными первым внедрением ИИ. Сценарий повторяется: чат-окно, несколько неплохих ответов, тихий откат назад. Решение — почти никогда не «лучший промпт», а лучший контекст. Ниже разбираем, что такое контекст-инжиниринг на практике: что он стоит, что он даёт и где ломается.

Что такое контекст-инжиниринг на самом деле

Контекст-инжиниринг — это практика структурирования всего, что нужно ИИ-модели для эффективной работы в конкретной среде: память проекта, правила, права доступа, поиск, инструменты и соглашения. Цель — чтобы каждое взаимодействие начиналось с высокой базовой осведомлённости, а не «с чистого листа».

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

В современных ИИ-инструментах для разработки — Claude Code, Cursor, Codex, Aider, GitHub Copilot Workspace — это хранится в файлах CLAUDE.md, AGENTS.md, .cursorrules и .rules.md по папкам, а также в MCP-серверах, которые связывают модели с вашими базами данных, системами учёта задач и CI. Основная идея везде одна: задайте контекст один раз и используйте его снова и снова.

Почему одних промптов на масштабе недостаточно

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

Большая часть качества ответов ИИ зависит не от изобретательности промптов, а от качества контекста и точности настройки.

Четыре компонента промышленного уровня контекста

1. Память проекта. Небольшой набор файлов с описанием стека, архитектуры, соглашений, команд сборки и ключевых решений. Это то, что модель читает в начале сессии. Держите её небольшой и актуальной: устаревшая память хуже, чем её отсутствие.

2. Модульные правила. Включаются по условию. Правила фронтенда применяются к файлам .tsx. Инфраструктурные правила — к Docker и Terraform. Выборочная активация уменьшает количество ложных срабатываний и повышает точность.

3. Ленивая подгрузка контекста. Вместо того чтобы загружать в модель сразу 50 файлов документации, подключайте только нужные по запросу. Для этого есть инструменты вроде @docs в Cursor и ссылок на файлы в Claude. Расход токенов снижается, а точность остаётся на прежнем уровне.

4. Права доступа и инструменты. Определите, что агент может запускать. Разрешено: линтер, тесты, сборки. Запрещено: продакшен-секреты, удаление инфраструктуры, биллинговые эндпоинты. MCP-серверы предоставляют доступ к базам данных, тикет-системам и системам мониторинга в рамках чётко заданных прав.

Где контекст-инжиниринг даёт максимальный эффект — по типам задач

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

ИИ уже интегрирован во весь SDLC, а не только в инженерные процессы

Инженерия. Claude Sonnet 4.5, GPT-5 и Gemini 2.5 Pro решают 75–82% задач SWE-bench Verified — против примерно 65% год назад. Доля решённых реальных issue в репозиториях растёт параллельно.

QA. Настроенные агенты генерируют тест-кейсы, выявляют граничные случаи, анализируют трейсы и предлагают возможные причины сбоев. Благодаря контексту, который учитывает репозиторий, время анализа багов в продакшене сокращается на 40–60%. Подробнее об использовании ИИ для решения проблем QA и оптимизации тестирования — в наших отдельных материалах.

Дизайн. Генеративные инструменты за минуты создают вайрфреймы, варианты интерфейсов и черновики прототипов. Дизайнеры быстрее работают над улучшениями и остаются в процессе.

Продукт и аналитика. Модели выявляют противоречия в требованиях, предлагают критерии принятия, сокращают длинные PRD и отмечают пропущенные ограничения.

Операции. ИИ-агенты сортируют обращения в поддержку, составляют краткое содержание входящих сообщений, обрабатывают финансовые данные и пишут маркетинговые тексты — часто без кода, на low-code-платформах для агентов.

Мини-кейс: как контекст-инжиниринг применялся на проекте «Фора Софт»

Ситуация. Микросервисный бэкенд (Node.js, NestJS, MongoDB) и мобильное приложение на React Native — проект среднего размера, в команде четверо инженеров, включая двух сеньоров. Команда использовала Claude Sonnet для разовых вопросов и оценила прирост продуктивности примерно в 10%, при этом заметных изменений в скорости выпуска релизов не было.

Что мы поменяли в первую неделю. Написали CLAUDE.md на 60 строк — со стеком технологий, командами сборки, соглашениями и кратким описанием архитектуры. Добавили .rules.md по папкам: для бэкенда, мобильного приложения и общих типов. Подключили MCP-сервер для Linear, чтобы агент мог читать тикеты и создавать черновики PR. Настроили права на файлы: чтение — везде, запись — только в /src, ни в коем случае — в /infra или .env.

Что изменилось со 2-й по 6-ю неделю. Скорость спринта по числу слитых PR выросла на 35%. Медианное время разбора багов в продакшене сократилось с 3,5 до 1,4 часа. Агент нашёл утечку данных сессии при выходе пользователя, исправил OAuth-флоу в десктоп-обёртке и перенёс фильтрацию с клиента на сервер — всё это в рамках одного тикета. В режиме «только промпты» такие изменения так быстро бы не попали в релиз.

Вывод: настройка контекста заняла 1–3 дня, и изменения, которые команда заметила уже с первых дней, сохранялись до самого конца проекта.

Как выбрать подходящую модель для задачи

«Лучшего ИИ» не существует. Есть лучший ИИ для конкретной задачи. Следите за бенчмарками так же внимательно, как за производительностью инфраструктуры — объективно.

Бенчмарки, за которыми стоит следить: SWE-bench Verified, Aider Polyglot, LMArena, GPQA Diamond, ARC-AGI. Смотрите независимые сторонние рейтинги, не верьте бенчмаркам от производителей на слово.

Экономика: токены, язык и дисциплина расходов

Стоимость ИИ измеряется в токенах. На больших объёмах даже небольшие выигрыши в эффективности обработки токенов превращаются в реальные деньги.

Язык важен. Не-английский текст может занимать в 2–3 раза больше токенов по сравнению с английским. Для чат-ботов, агентов и суммирования больших объёмов данных рекомендуется использовать английский язык в системных промптах и цепочках рассуждений, а финальный ответ пользователю — на нужном языке. Такой подход даёт типовой выигрыш в 40–60% при нагрузке от 10 тысяч сообщений в день.

Кэшируйте агрессивно. Современные API (Anthropic, OpenAI) поддерживают кэширование промптов для системных сообщений и стабильного контекста. Документация, которая не меняется каждый день, должна храниться в кэше, а не передаваться в промпте.

Стройте «многоуровневую» работу с моделями. Дешёвые модели (Claude Haiku, GPT-5 mini) — для классификации и маршрутизации. Дорогие (Sonnet, Opus, GPT-5) — только для действительно сложных задач. Многие команды переплачивают, отправляя любую задачу на флагманскую модель.

Подгружайте контекст лениво. Включать в промпт 50 документов — это в 50 раз дороже, чем один релевантный. Используйте поиск (RAG) или ссылки на файлы, а не «закидывайте» всё подряд в модель.

От одного агента — к ИИ-инфраструктуре

За пределами «настроенного одиночного агента» зрелые команды теперь используют ИИ как инфраструктуру.

Переиспользуемые модули задач. Повторяющиеся сценарии — триаж багов, ревью PR, черновики release notes — хранятся в файлах задач, которые можно версионировать. Их запускают одной командой: в них заранее заданы подходящая модель, промпт и необходимые инструменты.

Интеграции через MCP. Протокол Model Context Protocol позволяет агентам взаимодействовать с внешними системами — базами данных, системами тикетов, мониторингом и поиском — в рамках чётко заданных прав. Мы подключаем MCP к GitHub, Linear, Jira, Sentry, Postgres и Slack почти на всех проектах. Подробный пример с голосовыми агентами в реальном времени описан в отдельном гайде по разработке ИИ-агентов на LiveKit.

Координация нескольких агентов. Оркестратор распределяет подзадачи между специализированными агентами параллельно: один анализирует логи, другой пишет тесты, третий формирует описание PR. Оркестратор объединяет результаты и отправляет их на ревью. Подходящие фреймворки: LangGraph, CrewAI, computer-use от Anthropic, а также кастомные внутрипроцессные пайплайны.

Событийные хуки. «На каждое открытие PR — запускаем агента-линтер. На каждый деплой в стейджинг — запускаем агента smoke-тестов». ИИ в CI/CD в 2026 году — это уже не эксперимент, а штатный режим.

Безопасность и права доступа: что чаще всего упускают

1. Права на уровне файлов. Запись разрешена только в /src. Никогда не позволяйте агенту изменять .env, инфраструктуру или миграции без явного подтверждения для каждого действия.

2. Права на уровне инструментов. Агент может запускать линтер, тесты и сборки. Деплоить, запускать миграции в продакшене или вызывать биллинговые эндпоинты — нельзя, только с подтверждением человека.

3. Дисциплина по секретам. Никаких реальных секретов — в промптах, в файлах, видимых агенту, и в ответах MCP. Используйте Doppler, Infisical или AWS Secrets Manager с чтением по ограниченным токенам.

4. Ревью результата. Любой PR, открытый агентом, должен пройти проверку человеком до слияния. Агент — не ваш начальник; это ваш быстрый джуниор.

5. Логирование и аудит. Записывайте каждое действие агента: промпт, вызовы инструментов, изменения (диффы). Эти логи пригодятся, как только что-то пойдёт не так.

График внедрения: реалистичный план развёртывания контекст-инжиниринга

Итого: примерно 12–20 рабочих дней end-to-end. Большинство команд замечают реальный прирост продуктивности уже на второй неделе.

Фреймворк решения: где инвестировать в контекст-инжиниринг — пять вопросов

1. Какова доля рутинной работы у вашей команды по сравнению с творческой? Чем больше рутины — тем выше выгода от контекст-инжиниринга. На стэках с большим объёмом шаблонного кода экономия достигает 50%+, на исследовательских задачах — 15–25%.

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

3. Куда уходят токены? Соберите статистику за неделю. Если 70% токенов тратится на один тип задач — это лучшая цель для настройки.

4. Какие применимы требования по комплаенсу? Регулируемые данные (PHI, PII, финансовые) требуют использования self-hosted моделей или подписанных BAA с вендорами, что сужает выбор моделей и влияет на организацию прав доступа.

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

Пять типичных ошибок, на которые наступают каждый квартал

1. Воспринимать ИИ как чат-бот, а не как инфраструктуру. Чат-окно — это только верхушка айсберга. Реальные выгоды дают настроенные агенты, MCP и переиспользуемые модули задач.

2. Устаревшая память проекта. CLAUDE.md, который не обновляли полгода, может привести агента к ошибочным решениям. Относитесь к памяти как к коду — пересматривайте её при каждой смене архитектуры.

3. Всегда брать флагманскую модель. Если все задачи обрабатываются на Opus или GPT-5, бюджет уходит на классификацию, которую Haiku или mini выполняют в 20 раз дешевле. Используйте модели по уровням.

4. Игнорировать права доступа. Агент с шеллом и широкими правами на запись — это потенциальная угроза. Ограничьте доступ до развёртывания, а не после.

5. Нет плана измерений. Без начального уровня по числу объединённых PR, времени на исправление багов или покрытию тестами вы не сможете подтвердить улучшения. Начинайте измерять с первого дня.

KPI, по которым видно, что контекст-инжиниринг работает

KPI качества. Доля «утечки» дефектов в PR с участием ИИ — менее 5%. Прирост покрытия тестами — более 5% за квартал. Плотность замечаний на ревью (комментариев на PR) — более 1,5: агент не должен пропускать «шлак».

Бизнес-метрики. Количество PR на одного инженера — более чем в 1,4 раза выше базового уровня. Время до первого PR по новой фиче — менее чем в 0,7 раза от базового уровня. Медианное время обработки бага — менее 1,5 часа. Расход токенов на один слитый PR — менее 225 ₽ при использовании только флагманской модели и менее 37 ₽ при многоуровневом роутинге.

KPI надёжности. Регрессии, вызванные агентом, — менее 1% релизов. Инциденты в продакшене, связанные с изменениями агента, — менее одного в квартал. Среднее время отката проблемного PR от агента — менее 30 минут.

Роли в команде с настроенным контекстом

Владелец контекста. Один ответственный инженер ведёт учёт памяти проекта и правил. Пересматривает их при каждом изменении архитектуры. Отвечает на вопрос: «Знает ли агент про X?»

Лид по инструментарию. Отвечает за интеграции с MCP, маршрутизацию моделей, дашборды стоимости и управление доступом. Часто это тот же человек, что и платформенный инженер.

Инженеры и QA. Используют настроенных агентов в повседневной работе. Выявляют проблемы с памятью и нарушениями правил. Относятся к выводу агента так же, как к PR от джуниора — с быстрым ревью и понятной обратной связью.

Инженерный менеджер. Раз в неделю проверяет дашборды KPI. Замечает рост расходов на ранней стадии. Не поддаётся искушению ввести жёсткие правила вроде «используем ИИ везде» или «запретить ИИ» — обе крайности не работают.

Когда контекст-инжиниринг — не та инвестиция

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

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

FAQ

В чём разница между ИИ-чат-ботом и ИИ-агентом?

Чат-бот отвечает на отдельные вопросы. ИИ-агент работает в настроенной среде с памятью проекта, правилами, правами доступа и инструментами. Разница — в постоянстве и глубине контекста, а не в мощности модели.

Что такое контекст-инжиниринг?

Это подход к организации памяти, правил, прав доступа и поиска, при котором ИИ-модель начинает каждую задачу с чёткой базовой информацией. Вместо того чтобы каждый раз повторять инструкции в промптах — задайте их один раз и используйте повторно. Такой порядок поддерживается в файлах CLAUDE.md, AGENTS.md, .cursorrules и в настройках MCP-серверов.

Заменяют ли ИИ-агенты разработчиков и QA-инженеров?

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

Какой реалистичный прирост продуктивности?

В структурированных средах — ускорение рутинной инженерной работы на 30–50%. На генерации тестов прирост выше, на архитектуре и глубоком рефакторинге — ниже. Точное значение зависит от зрелости исходной системы и дисциплины управления конфигурацией.

Почему конфигурация важнее промптов?

Промпты временные, а конфигурация — постоянная. Постоянный контекст уменьшает неоднозначность, помогает соблюдать соглашения и постепенно повышает продуктивность. Команда, потратившая 2 дня на настройку CLAUDE.md, правил и подключения MCP, теперь экономит время в каждом спринте.

Как удержать расходы на токены при росте объёма?

Стройте многоуровневое использование моделей: дешёвые — для рутинных задач, флагманские — для сложных. Кэшируйте стабильные системные промпты. Загружайте контекст постепенно, не подключайте сразу 50 документов. Оставляйте системные промпты и промежуточные рассуждения на английском, а финальный ответ выдавайте на нужном языке. Такой подход даёт экономию 40–60% при больших объёмах.

Какую модель выбрать для работы с кодом в 2026?

Claude Sonnet или Opus 4.х — для агентских сценариев и работы с длинным контекстом. GPT-5 — для рассуждений с использованием инструментов и голосовых агентов. Gemini 2.5 Pro — для мультимодальных задач и создания кратких описаний по большому объёму кода. Открытые модели (Llama, Qwen, DeepSeek) — для развёртывания на собственных серверах, в регулируемых отраслях и on-prem-средах. Универсальной «лучшей» модели нет — выбирайте в зависимости от типа задачи.

Как выглядит ИИ-аудит безопасности при развертывании агентов?

Права на запись доступны только в защищённых директориях. В инструментах отключены продакшен, биллинг и миграции. Секреты хранятся в менеджере (Doppler, Infisical, AWS Secrets Manager) и читаются только по ограниченным токенам. Каждое изменение от агента проходит обязательное ревью человеком. Все вызовы инструментов логируются. Всё это закладываем в плейбук развёртывания.

Что почитать дальше

Готовы воспринимать ИИ как инфраструктуру, а не просто как чат-окно?

Продуктивность ИИ в 2026 году зависит от контекста, а не от «умных» промптов. Команды, которые получают устойчивую выгоду, — те, кто потратил 1–3 дня на настройку памяти проекта, модульных правил, интеграций MCP и прав доступа, и с тех пор каждый день получают экономию. Те, кто до сих пор вводит «умные» промпты в чат, по-прежнему не понимают, почему ИИ им особо не помогает.

Фора Софт применяла такую настройку на десятках стеков — greenfield, легаси, регулируемых, мультикомандных. Мы можем провести аудит вашего контекста, описать правила и память, подключить MCP, настроить права и измерить эффект за 2-недельный спринт. Или обучим вашу команду делать это самостоятельно. В любом случае результат становится заметен уже на второй неделе.