Эволюция AI-кодинга: от Markdown-файла до context engineering — 12 мая 2026 г. в 07:30:58.990
Эволюция AI-кодинга: от Markdown-файла до context engineering Год назад основным инструментом настройки AI-кодинговых агентов был Markdown-файл с инструкциями. Он загружался в контекст при каждом старте сессии. За двенадцать месяцев AI-ландшафт изменился настолько, что для описания новой практики потребовался отдельный термин — context engineering. Он появился в середине 2025 года и быстро закрепился как обозначение системного подхода к управлению информацией, которую видит модель. Смысл в том, что качество результата определяет не промпт, а архитектура контекста. 📁 Как это выглядит на практике Вместо монолитного файла с правилами — модульные skills: папки с инструкциями, документацией и скриптами, каждая со своим описанием. Модель получает только описания, а полное содержимое загружает по необходимости — lazy loading контекста. Это принципиальный сдвиг: контекстное окно перестает забиваться нерелевантной информацией на старте сессии. По данным с QCon London 2026, даже пустая сессия Claude Code еще до первого запроса пользователя занимает 15% контекстного окна — это: ▪️системный промпт, ▪️описания skills, ▪️интерфейсы инструментов. 👥 Subagents: решение двух проблем Второй значимый элемент — subagents. Основной агент порождает дочерние процессы для задач, требующих обработки большого объема данных: исследование кодовой базы, code review, анализ логов. Результат возвращается в основную сессию в сжатом виде, без переноса всей промежуточной работы в основной контекст. Это решает сразу две проблемы: ✅ деградацию качества при заполнении контекстного окна; ✅ рост стоимости (каждый цикл взаимодействия отправляет весь накопленный контекст). 🔧 MCP vs CLI: практичный выбор Третий сдвиг менее очевиден, но, возможно, наиболее практичен. Многие команды начали отказываться от MCP-серверов в пользу CLI-инструментов и скриптов, которые уже установлены на машине разработчика. Агенту достаточно описать доступные команды — и он использует их напрямую, без промежуточного слоя. Это проще в эксплуатации и не требует отдельного процесса. ⚠️ Обратная сторона: amplifier в обе стороны Context engineering работает как усилитель в обе стороны: ✅ Хорошо спроектированный контекст усиливает правильные паттерны (архитектурные решения, модульность, конвенции кода). ❌ Плохо спроектированный — масштабирует ошибки и дрейф. Команда OpenAI, пять месяцев работавшая над проектом в режиме минимального ручного вмешательства, зафиксировала нарастание энтропии кодовой базы даже при наличии продвинутой настройки. Для борьбы с этим потребовались дополнительные агенты, непрерывно выполняющие «сборку мусора» в коде. 🛠️ Harness engineering: проектирование обвязки Это приводит к более широкой идее, которую в сообществе начинают называть harness engineering — проектирование обвязки вокруг агента. В эту обвязку входят: ▪ структурные тесты ▪ кастомные линтеры ▪ архитектурные ограничения Все, что дает агенту детерминированную обратную связь и снижает зависимость от вероятностного поведения модели. Практика показывает, что сообщения об ошибках линтеров и тестов тоже становятся частью context engineering: в них встраиваются подсказки для агента о том, как интерпретировать нарушение, а не просто исправить его. 💡 Главный вопрос для команд теперь звучит так Не «какую модель выбрать», а «как спроектировать контекст и обвязку для своего стека и типа приложений». И это уже задача системного проектирования, а не настройки промптов. #радар_трендов