За пределами grep: защита богатого контекстного ИИ-инструментария

Разработка & Кодинг Jul 21, 2026В закладки

За пределами grep: защита богатого контекстного ИИ-инструментария

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

Точка отсчёта

Конкретный случай, который пережил каждый старший разработчик: открываешь IDE, просишь помощника «рефакторинг этой функции, чтобы она использовала новый внутренний API» — и он выдаёт синтаксически чистый, правдоподобный код, но игнорирует три соглашения проекта, две внутренние зависимости и хелпер, который уже существует в тридцати строках ниже. Модель не «глупая», она просто не увидела того, что нужно было увидеть.

Именно эту идею отстаивает Винай Пернети (Augment Code) в интервью Ars Technica под названием «Beyond grep: The case for a context-rich AI coding harness»: харнес — совокупность механизмов, которые выбирают, упорядочивают и внедряют контекст в промт, — сегодня весит больше, чем выбор самой модели.

Что делает «бедный» харнес

По сути, это усовершенствованный grep:

  • наивный поиск вложений в файлах репозитория,
  • окно контекста вокруг курсора,
  • возможно, весь текущий файл.

Это работает для локальных задач (переименование переменной, исправление сигнатуры). Но ломается, как только нужно понять, почему тест падает на три модуля дальше.

Что делает «богатый» харнес

Три взаимодополняющих блока, в духе того, что защищает Пернети в Augment Code:

  1. Граф зависимостей кода — импорты, вызовы, наследование: харнес отслеживает связи, чтобы принести действительно нужные определения, а не просто текстово близкие файлы.
  2. История выполнения — трейсы тестов, логи, вывод последнего pytest или cargo test. Модель видит, что сломалось, а не только код, который ломается.
  3. Память сессии — решения, принятые в предыдущих обменах («мы выбрали библиотеку X, а не Y»), чтобы помощник не ставил их под сомнение на каждом шаге.

Недавние open-source-проекты иллюстрируют каждый из этих блоков: экосистема tree-sitter для структурного анализа, инструменты вокруг ripgrep в сочетании с семантическими индексами и фреймворки агентов, которые ведут постоянный «черновик» (scratchpad).

Почему это — ключевой фактор

Две экономические причины:

  • Цена токена падает, окно контекста растёт: можно позволить себе отправлять больше. Но нельзя отправить всё — монолитный репозиторий из 500 000 строк всё ещё недоступен. Поэтому нужно отбирать.
  • Модель лучше рассуждает над тем, что ей показывают в нужный момент, чем над тем, что ей сваливают в кучу. Харнес, который правильно приоритизирует, побеждает модель, которая плохо сортирует в своём собственном окне.

Другими словами: разница между помощником, который просто терпим, и помощником, на которого можно положиться, больше не в весе модели. Она — в инженерии программного обеспечения его среды восприятия.

Кратко

  • «Харнес» (инженерия контекста) стал настоящим дифференциатором кодовых помощников — эту идею публично отстаивает Винай Пернети в Augment Code.
  • Богатый харнес сочетает граф кода, историю выполнения и память сессии — а не только текстовый поиск.
  • Выбор инструмента сегодня — это не только оценка модели, но и оценка его харнеса.
Resources

Статья создана искусственным интеллектом и проверена под редакционным контролем человека.

Наша редакция
Была ли статья полезной?

23 чел. оценили эту статью

Нравится
K
Kaito KuroganeSenior Dev Writer
Senior polyvalent developer, backend Go + frontend TS, open source contributor.
Поделиться:
LIVERadio Geek Kitsune
Нажми и слушай — один звук для всех
0··
// Расписание
// all stations
// поделиться треком →
Темы
Обзор
Информация