- Главная
- Искусственный интелект
- Проблема исследования кодовой базы агентом
Проблема исследования кодовой базы агентом
Главный источник ошибок при работе с ИИ-агентом — не слабая модель, а разрыв между тем, что агент знает о вашей кодовой базе, и тем, что он мог бы из неё легко узнать. Когда агент не смотрит в существующий код, он уверенно предлагает решения, которые уже есть в проекте, пишет дубли и иногда ломает работающее. Разберём, как выглядит эта проблема, почему она возникает и во что обходится на практике.
Симптом: агент изобретает велосипед
Так выглядит классический велосипед: код работает, но он лишний. Симптомы проблемы узнаются без труда.
- Дублирование. Агент создаёт функцию, которая уже существует в другом файле, под другим именем или с тем же именем, но другой логикой.
- Чужой стиль. Новый код не похож на остальной проект: другие соглашения об именах, другой порядок зависимостей.
- Неверные допущения. Агент предполагает, что данные приходят в одном формате, а проект отдаёт их по-другому.
- Сломанные связи. Изменения игнорируют существующие вызовы, и работающий функционал перестаёт работать.
Самое коварное в этих симптомах — их незаметность. Код собирается, тесты проходят, задача выполнена. Проблему обнаруживают позже, когда дубликат уже влит в основной код и за него начинают платить каждым последующим изменением.
Почему агент не видит существующий код
Усугубляет ситуацию недетерминированная природа модели: один и тот же запрос может дать разные ответы, и при нехватке фактов агент достраивает картину по вероятности, а не по фактам проекта. Это близко к галлюцинациям: модель не выдумывает несуществующую библиотеку, но выдумывает несуществующий модуль, уверенно называя его частью вашего кода.
Важнее другое: даже хороший агент в этой ситуации не виноват. Ему никто не сказал, что репозиторий уже решил задачу. Проблема системная — агент работает с той информацией, которую вы ему дали, а исследование кодовой базы не было этой информацией.
Цена проблемы: контекст, время, деньги
Не забываем и про деньги. Каждый запрос агента заново отправляет модели весь накопленный контекст; а когда из-за непонимания проекта агент пишет две версии одной функции, вы платите дважды за её создание и ещё раз за исправление дубля. Цена растёт не от одного вызова, а от хвоста повторных правок, порождённых одной ошибкой на входе.
| Издержка | Когда появляется |
|---|---|
| Дублирование кода | Агент пишет функцию, уже существующую в проекте |
| Двойная поддержка | Баг чинят в одном клоне, второй остаётся со старым поведением |
| Раздутый контекст | Лишний код и лишние переписки заполняют окно сессии |
| Повторные правки | Каждое неверное допущение порождает новый цикл «напиши-исправь» |
Как провал исследования выглядит на практике
Разберём реальный сценарий. В проекте есть сервис заказов, а рядом новый коллега просит агента добавить запись в лог при создании заказа. Агент открывает файл контроллера, не заглядывая в соседние модули, и пишет самописную функцию логирования. При этом в проекте три месяца существует утилита logger.ts, через которую логируются все события.
- Шаг 1. Агент читает один файл — контроллер заказа — и решает, что знает всё.
- Шаг 2. Он не ищет существующий логгер, потому что никто не велел его искать, а его вызовы за пределами прочитанного файла.
- Шаг 3. Функция написана, тесты зелёные, коммит сделан.
- Шаг 4. Через неделю команда замечает: логи заказов приходят в другом формате, чем все остальные логи в системе.
Ключевой момент — шаг 1. Исследование остановилось на первом файле. Агент повёл себя как человек, который «не в курсе», потому что ему не дали повода узнать. Проблема не в том, что он плох, а в том, что процесс не требует исследования.
Ложные решения, которые не работают
- «Изучи весь проект». Просьба прочитать всё сразу заливает контекст тоннами ненужного и толкает сессию за границу Smart Zone ещё до начала работы. Широкое исследование без цели дороже, чем сама задача.
- Ручная вставка файлов. Вставлять весь код вручную — значит возвращаться к эпохе копипасты: объёмный контекст, ошибки в версиях. Это тот самый ручной труд, ради которого мы автоматизировали процесс.
- Надежда на модель. «Современная модель сама догадается» — опасная иллюзия. Модель рассуждает качественно, пока получает факты; там, где фактов нет, она не исследует, а домысливает.
Объединяет эти ошибки игнорирование одной вещи: исследование — это отдельная задача с собственным процессом, а не побочный эффект хорошей модели. Пока вы не дадите агенту способ узнать проект, он будет отвечать из вероятностей, а не из кода.
Простой тест на велосипед: прежде чем позволить агенту писать к этой функции, попросите его назвать файл, где она должна жить, и соседние функции, к которым она должна обращаться. Если агент не может назвать конкретный файл проекта, он не исследовал базу — и пишет с потолка.
Почему исследование — отдельная дисциплина
Умение запускать команды из оболочки даёт агенту доступ к grep, поиску по сигнатурам и спискам файлов — дёшево, точечно и без ручного копирования. Субагенты позволяют держать исследование отдельным, неперегруженным верхним контекстом: субагент изучает базу и возвращает вам только вывод, не засоряя основную сессию. А сам harness со своими командами навигации задаёт способ, которым агент передвигается по коду.
Другими словами, всё нужное у нас уже есть: команды, субагенты, дисциплина контекста. Не хватает только порядка действий — того, что заставит агента смотреть в код до того, как он напишет новый. Куда именно смотреть, как ограничить поиск и как убедиться, что агент опирается на факты, а не на догадки, — это уже технология решения, но сначала стоит зафиксировать саму проблему.
Фиксируйте случаи, когда агент изобрёл велосипед, в файле заметок проекта. Каждый такой случай — диагноз: где-то исследование прервалось раньше времени. Через несколько записей станет видно закономерность — например, что дубли рождаются в утилитах, которых агент не читает, потому что считает их «неинтересными». Слабое место найдено — значит, его можно лечить.
Итоги
Это ведёт к дублям, двойной поддержке, раздутому контексту и лишним тратам, притом что ни модель, ни команда здесь не «плохие» — просто исследование не выстроено как процесс.
В следующем уроке разберём, как превратить исследование из надежды на модель в порядок действий: куда направить агента смотреть, как ограничить поиск и как убедиться, что он опирается на реальные факты проекта, а не на догадки.
Глоссарий
- Исследование кодовой базы — процесс изучения агентом существующего кода перед написанием нового.
- Велосипед (изобретение велосипеда) — создание дублирующей сущности, которая уже существует в проекте из-за незнания его устройства.
- Дублирование кода — ситуация, когда одна сущность существует в проекте дважды.
- Двойная поддержка — издержка, при которой исправление в одном клоне не влияет на другой.
- Контекст сессии — весь текст, который отправляется модели при каждом запросе.
- Недетерминированность — свойство модели давать разные результаты на один и тот же запрос.
- Галлюцинация — правдоподобный, но не соответствующий реальности вывод модели.
- Избыточность контекста — наличие в контексте информации, не нужной для текущей задачи.
- Субагент — независимый контекст, выполняющий подзадачу, в том числе исследование, не засоряя основную сессию.
- Smart Zone — продуктивный диапазон заполнения context window, в котором агент рассуждает качественно.
- Harness — программа-оболочка, через которую пользователь взаимодействует с LLM и управляет агентом.
- Сессия (session) — один непрерывный разговор с агентом, ограниченный context window.