# Дэвид Локер: Почему промпт-инжиниринг мертв и что такое Context Engineering Источник: https://www.youtube.com/watch?v=6Zrbs8_hjwM Канал: DeepLearning.AI Опубликовано: 03.12.2025 --- На конференции AI Dev 25 в Нью-Йорке Дэвид Локер (David Loker), директор по ИИ в компании Code Rabbit, представил новый взгляд на автоматизацию рабочих процессов разработчиков. Основной темой его выступления стало «инженерное проектирование контекста» (context engineering) — дисциплина, которая приходит на смену привычному промпт-инжинирингу в задачах ревью кода. ## 🧠 От промпт-инжиниринга к контекстному проектированию [[JUMP:00:34]] По мнению Дэвида Локера, эра простых инструкций для языковых моделей (LLM) подходит к концу [00:34]. Промпт-инжиниринг, заключавшийся в поиске «магических» формулировок, сталкивается с жесткими ограничениями: разработчик часто не знает заранее, какая именно информация понадобится модели для решения конкретной задачи в момент написания промпта [01:00]. Локер вводит термин «контекстное проектирование» как процесс динамического формирования окружения внутри контекстного окна LLM [01:54]. Это не просто подача текста на вход, а проектирование адаптивной среды, которая собирает данные из множества источников в реальном времени, чтобы модель могла действовать максимально точно [02:08]. ## 📉 Кризис ревью кода и влияние ИИ-инструментов [[JUMP:02:21]] Ситуация с проверкой кода (code review) в современных компаниях близка к критической. Локер выделяет три типа подходов: * **No Code Review (YOLO):** Типично для стартапов с одним инженером, где код летит в продакшен без проверки, что часто ведет к катастрофам [02:35]. * **Полуформальное ревью:** Коллеги проверяют друг друга «на коленке», пропуская логические ошибки и баги [02:49]. * **Корпоративный стандарт (Google, Netflix):** Тщательный процесс, требующий огромных усилий от сеньор-разработчиков и архитекторов [03:16]. Проблема усугубляется распространением инструментов генерации кода (GitHub Copilot, Cursor и др.). По данным Локера, разработчики теперь тратят от 15% до 30% своего времени на ревью [04:21]. ИИ-инструменты создают «бутылочное горлышко»: PR (Pull Requests) становятся больше и создаются чаще. Локер приводит в пример случаи PR на 15 000 строк кода, которые физически невозможно проверить человеку [04:49]. Без автоматизации процесса проверки пропускная способность команд резко падает [05:14]. ## 🛠️ Архитектура контекста: как «думает» ИИ-ревьюер [[JUMP:06:24]] Чтобы ИИ мог заменить эксперта-человека, ему нужно предоставить тот же объем данных, который senior-инженер собирает перед началом проверки. Локер перечисляет ключевые компоненты этой системы: 1. **Анализ графа кода (Code Graph Analysis):** Система «раскручивает» связи от измененных строк к зависимым функциям, переменным и импортам в других файлах [06:53]. 2. **Интеграция со статическим анализом:** Использование линтеров для поиска потенциальных ошибок, которые затем «пережевываются» и интерпретируются LLM для устранения ложноположительных срабатываний [07:06]. 3. **Внешние данные через MCP (Model Context Protocol):** Это позволяет модели обращаться к актуальной документации библиотек, внутренним гайдлайнам компании и даже к описанию задачи (Issue), чтобы проверить, соответствует ли код изначальному замыслу [07:44]. 4. **База знаний и «Обучение» (Learnings):** Система запоминает предпочтения команды (например, использование camelCase или специфические паттерны авторизации) через чат с пользователем [12:40]. ## 📝 Оптимизация контекстного окна: JSON против Тэгов [[JUMP:13:18]] Одним из технических инсайтов доклада стала критика использования JSON как формата входных данных. Хотя JSON удобен для машин, Локер утверждает, что модели обучались преимущественно на человеческих текстах [13:43]. В качестве альтернативы он предлагает «Prompt Envelope» — использование человекочитаемых XML-подобных тэгов [13:55]. Это дает два преимущества: * Снижение потребления токенов (JSON избыточен). * Лучшее понимание структуры моделью в случае огромных объемов данных [14:09]. В реальном тесте, проведенном Локером, простой «заброс» всей связанной информации в формате JSON потребовал 110 000 токенов и 38 секунд на обработку [17:07]. После оптимизации контекста (выделение только реально затронутых связей) объем сократился до 18 300 токенов (всего на 1000 больше, чем сам диф кода), при этом баг был найден так же эффективно [17:59]. ## 🧠 Агентское контекстное проектирование (ACE) [[JUMP:18:53]] Локер ссылается на недавнюю работу Стэнфордского университета — Agentic Context Engineering (ACE) [18:53]. Суть подхода в том, что вместо дорогостоящей дообучения (fine-tuning) модели, система использует агента для рефлексии над результатом. Агент анализирует: помог ли данный фрагмент контекста найти баг? Если какой-то сигнал (например, вывод конкретного линтера) постоянно игнорируется пользователями, система автоматически корректирует стратегию выбора контекста для будущих проверок [21:08]. Это превращает процесс подготовки данных из статичного промпта в обучаемую стратегию [20:41]. ## ❓ Вопросы и ответы: Будущее ИИ-разработки [[JUMP:23:45]] В ходе сессии вопросов Дэвид Локер затронул несколько важных аспектов: * **Риск самопроверки:** На вопрос о том, сможет ли ИИ будущего (например, Claude 4 или новые модели OpenAI) идеально проверять свой собственный код, Локер ответил скептически. По его мнению, нельзя позволять системе, создавшей код, его же и оценивать — она склонна подтверждать свою правоту [28:41]. * **Забывчивость моделей:** Локер отметил интересную математическую проблему: чем больше информации в контекстном окне, тем выше шанс, что модель «забудет» инструкции, данные в начале или середине [29:45]. * **Персонализация:** Если один из участников команды вносит в базу знаний «вредные» инструкции (например, в порыве гнева), система позволяет модерировать и удалять такие «обучения» через интерфейс чата [26:10]. Главный вывод выступления: «Не просто пишите промпты — стройте контекст» [23:33]. Успех ИИ в сложных инженерных задачах сегодня зависит не от модели как таковой, а от качества и чистоты данных, которые подаются в её рабочее пространство.