На конференции AI Dev 25 в Нью-Йорке Дэвид Локер (David Loker), директор по ИИ в компании Code Rabbit, представил новый взгляд на автоматизацию рабочих процессов разработчиков. Основной темой его выступления стало «инженерное проектирование контекста» (context engineering) — дисциплина, которая приходит на смену привычному промпт-инжинирингу в задачах ревью кода.
🧠 От промпт-инжиниринга к контекстному проектированию 0:34
По мнению Дэвида Локера, эра простых инструкций для языковых моделей (LLM) подходит к концу . Промпт-инжиниринг, заключавшийся в поиске «магических» формулировок, сталкивается с жесткими ограничениями: разработчик часто не знает заранее, какая именно информация понадобится модели для решения конкретной задачи в момент написания промпта .
Локер вводит термин «контекстное проектирование» как процесс динамического формирования окружения внутри контекстного окна LLM . Это не просто подача текста на вход, а проектирование адаптивной среды, которая собирает данные из множества источников в реальном времени, чтобы модель могла действовать максимально точно .
📉 Кризис ревью кода и влияние ИИ-инструментов 2:21
Ситуация с проверкой кода (code review) в современных компаниях близка к критической. Локер выделяет три типа подходов:
- No Code Review (YOLO): Типично для стартапов с одним инженером, где код летит в продакшен без проверки, что часто ведет к катастрофам .
- Полуформальное ревью: Коллеги проверяют друг друга «на коленке», пропуская логические ошибки и баги .
- Корпоративный стандарт (Google, Netflix): Тщательный процесс, требующий огромных усилий от сеньор-разработчиков и архитекторов .
Проблема усугубляется распространением инструментов генерации кода (GitHub Copilot, Cursor и др.). По данным Локера, разработчики теперь тратят от 15% до 30% своего времени на ревью . ИИ-инструменты создают «бутылочное горлышко»: PR (Pull Requests) становятся больше и создаются чаще. Локер приводит в пример случаи PR на 15 000 строк кода, которые физически невозможно проверить человеку . Без автоматизации процесса проверки пропускная способность команд резко падает .
🛠️ Архитектура контекста: как «думает» ИИ-ревьюер 6:24
Чтобы ИИ мог заменить эксперта-человека, ему нужно предоставить тот же объем данных, который senior-инженер собирает перед началом проверки. Локер перечисляет ключевые компоненты этой системы:
- Анализ графа кода (Code Graph Analysis): Система «раскручивает» связи от измененных строк к зависимым функциям, переменным и импортам в других файлах .
- Интеграция со статическим анализом: Использование линтеров для поиска потенциальных ошибок, которые затем «пережевываются» и интерпретируются LLM для устранения ложноположительных срабатываний .
- Внешние данные через MCP (Model Context Protocol): Это позволяет модели обращаться к актуальной документации библиотек, внутренним гайдлайнам компании и даже к описанию задачи (Issue), чтобы проверить, соответствует ли код изначальному замыслу .
- База знаний и «Обучение» (Learnings): Система запоминает предпочтения команды (например, использование camelCase или специфические паттерны авторизации) через чат с пользователем .
📝 Оптимизация контекстного окна: JSON против Тэгов 13:18
Одним из технических инсайтов доклада стала критика использования JSON как формата входных данных. Хотя JSON удобен для машин, Локер утверждает, что модели обучались преимущественно на человеческих текстах .
В качестве альтернативы он предлагает «Prompt Envelope» — использование человекочитаемых XML-подобных тэгов . Это дает два преимущества:
- Снижение потребления токенов (JSON избыточен).
- Лучшее понимание структуры моделью в случае огромных объемов данных .
В реальном тесте, проведенном Локером, простой «заброс» всей связанной информации в формате JSON потребовал 110 000 токенов и 38 секунд на обработку . После оптимизации контекста (выделение только реально затронутых связей) объем сократился до 18 300 токенов (всего на 1000 больше, чем сам диф кода), при этом баг был найден так же эффективно .
🧠 Агентское контекстное проектирование (ACE) 18:53
Локер ссылается на недавнюю работу Стэнфордского университета — Agentic Context Engineering (ACE) . Суть подхода в том, что вместо дорогостоящей дообучения (fine-tuning) модели, система использует агента для рефлексии над результатом.
Агент анализирует: помог ли данный фрагмент контекста найти баг? Если какой-то сигнал (например, вывод конкретного линтера) постоянно игнорируется пользователями, система автоматически корректирует стратегию выбора контекста для будущих проверок . Это превращает процесс подготовки данных из статичного промпта в обучаемую стратегию .
❓ Вопросы и ответы: Будущее ИИ-разработки 23:45
В ходе сессии вопросов Дэвид Локер затронул несколько важных аспектов:
- Риск самопроверки: На вопрос о том, сможет ли ИИ будущего (например, Claude 4 или новые модели OpenAI) идеально проверять свой собственный код, Локер ответил скептически. По его мнению, нельзя позволять системе, создавшей код, его же и оценивать — она склонна подтверждать свою правоту .
- Забывчивость моделей: Локер отметил интересную математическую проблему: чем больше информации в контекстном окне, тем выше шанс, что модель «забудет» инструкции, данные в начале или середине .
- Персонализация: Если один из участников команды вносит в базу знаний «вредные» инструкции (например, в порыве гнева), система позволяет модерировать и удалять такие «обучения» через интерфейс чата .
Главный вывод выступления: «Не просто пишите промпты — стройте контекст» . Успех ИИ в сложных инженерных задачах сегодня зависит не от модели как таковой, а от качества и чистоты данных, которые подаются в её рабочее пространство.
