Введение: когда ИИ-агент пошёл не по плану
Финтех-компания поставила цель: автоматизировать простые задачи разработки с помощью ИИ-агента. Результат оказался парадоксальным. Агент не выполнил ни одной боевой задачи и не внёс ни одного коммита в продакшен. При этом он закрыл более половины исследовательских запросов аналитиков и стал для них незаменимым инструментом. Ключевым продуктом оказался не сам агент-разработчик, а контекстная инфраструктура, которую построили для его работы: графы кода на tree-sitter и база знаний, синхронизируемая с коммитами.
Этот кейс - детальный разбор управленческого провала и архитектурной победы. Мы проанализируем, почему формализация «простой задачи» оказалась мифом, как отсутствие доверия к автономной работе заблокировало внедрение в regulated-индустрии и почему режим «спроси про систему» стал идеальной точкой входа для ИИ-агентов.
Анатомия провала: почему агент не смог стать разработчиком
Исходный замысел выглядел логично: передать агенту рутинные задачи, которые отнимают время у senior-разработчиков. Провал наступил на этапе определения, что считать «рутинной задачей». Две причины заблокировали проект: невозможность формализовать критерий простоты и глубинный кризис доверия к автономному агенту в финтехе.
Ловушка «простой задачи»: почему критерий оказался мифом
Задача, которая для человека выглядит тривиальной, для агента требует понимания всей системы. Добавление поля в API - классический пример. Разработчик знает: нужно обновить контракты, написать миграцию, проверить тесты, убедиться в обратной совместимости. Агент без полного контекста кодовой базы не может гарантировать безопасность ни одного из этих шагов.
Команда потратила недели на попытки описать критерии «простой задачи»: изменение текста ошибки, добавление необязательного параметра, исправление опечатки в логах. Каждый раз находился контрпример, где такое изменение ломало смежный сервис. В распределённой архитектуре финтеха даже безобидная правка требовала знания контрактов между десятком микросервисов. Формализовать это знание в промпте оказалось невозможно.
Кризис доверия: почему автономность агента пугает в regulated индустриях
Финтех живёт в парадигме documented decision-making. Каждое изменение кода должно быть объяснимо, обратимо и привязано к ответственному лицу. Автономный агент - чёрный ящик: он генерирует код, но не может объяснить, почему выбрал конкретную реализацию из десятка возможных. Для compliance-аудита это неприемлемо.
Показателен пример платформы Buzz от Block. Джек Дорси запустил среду для совместной работы людей и ИИ-агентов на протоколе Nostr. Даже там, где децентрализация заявлена как принцип, каждый агент получает отдельную криптографическую идентичность, права доступа и историю действий. Аудит действий агента - не опция, а базовая потребность любой regulated-компании. Без этого автономный агент не получает доступа к продакшен-коду.
Неожиданный поворот: как агент стал незаменимым для аналитиков
Пока разработчики спорили о критериях простоты, аналитики начали задавать агенту вопросы. И обнаружили, что контекстная инфраструктура, построенная для агента-разработчика, решает их главную боль: скорость исследования системы.
Исследовательские запросы: новая ниша для ИИ-помощников
Аналитики в финтехе постоянно отвечают на вопросы: «Какие сервисы используют этот эндпоинт?», «Где в коде реализована валидация этого поля?», «Как изменилась логика после последнего коммита?», «Кто владелец этого модуля?». Раньше ответ требовал ручного поиска по коду, опроса разработчиков и чтения документации, которая часто устаревала. Агент с контекстной инфраструктурой давал ответ за секунды.
Метрика говорит сама за себя: более 50% исследовательских запросов аналитиков закрыто агентом без привлечения разработчиков. Это не замена аналитика, а мультипликатор его возможностей. Время, которое раньше уходило на поиск информации, теперь тратится на анализ и принятие решений.
Почему контекстная инфраструктура стала ключевым продуктом
Ценность оказалась не в агенте, а в данных, которые ему скормили. Контекстная инфраструктура - это два компонента. Первый: графы кода на tree-sitter, которые дают точное статическое представление структуры проекта - вызовы функций, определения типов, импорты, зависимости между модулями. Второй: база знаний, синхронизируемая с коммитами, которая гарантирует актуальность ответов.
Generic RAG-решение по коду не дало бы такой точности. Оно ищет релевантные фрагменты по эмбеддингам и часто выдаёт устаревшие или неполные ответы. Графовый подход позволяет отвечать на структурные вопросы: «Покажи все сервисы, которые вызывают этот метод» или «Какие модули зависят от этой библиотеки». Для аналитика это принципиальная разница.
Архитектура решения: графы кода, база знаний и tree-sitter
Контекстная инфраструктура, ставшая главным продуктом, построена на трёх слоях: парсинг, индексация и синхронизация. Разберём каждый.
Tree-sitter как фундамент: от текста к семантическому графу
Tree-sitter - инкрементальный парсер, который строит конкретное синтаксическое дерево (CST) из исходного кода. Выбор именно этого инструмента обусловлен тремя свойствами. Первое: устойчивость к ошибкам - парсер не падает на неполном или синтаксически некорректном коде, что критично для работы с живой кодовой базой. Второе: инкрементальность - при изменении одного файла перестраивается только затронутая часть дерева, а не весь проект. Третье: поддержка множества языков через грамматики.
Из синтаксического дерева извлекаются семантические связи: вызовы функций, определения типов, импорты, наследование. Эти связи образуют граф кодовой базы - структурированное представление, по которому можно делать точные запросы. В отличие от regex-подхода, tree-sitter понимает контекст: он отличает вызов метода от строки с таким же именем, а объявление переменной от её использования.
База знаний, живущая в ритме коммитов
Актуальность данных - критическое требование для доверия к ответам агента. Механизм синхронизации работает через вебхуки на коммиты: при каждом пуше в репозиторий запускается инкрементальное обновление графа. Изменённые файлы перепарсиваются, новые связи добавляются, удалённые - вычищаются.
База знаний версионируется вместе с кодом. Аналитик может задать вопрос не только по текущему состоянию main-ветки, но и по конкретному коммиту или релизу. Это решает проблему «документация устарела раньше, чем её прочитали» - ответ всегда соответствует актуальной кодовой базе. Интерфейс запросов принимает естественный язык и транслирует его в формальный запрос к графу: вопрос «Где валидируется поле amount?» превращается в поиск всех узлов графа, связанных с определённым типом данных и операцией валидации.
Управленческие уроки: как превратить побочный результат в основную ценность
Кейс содержит четыре урока для руководителей, планирующих внедрение ИИ-агентов в разработку.
Почему «спроси про систему» - идеальная точка входа
Режим вопросов снижает риски до нуля и повышает доверие команды. Агент не меняет код, поэтому не может ничего сломать. При этом он демонстрирует ценность: отвечает на вопросы быстрее, чем разработчик, отвлечённый от своей задачи. Команда видит пользу и начинает доверять инструменту.
Аналогия с онбордингом нового сотрудника точна: сначала он задаёт вопросы о системе, изучает архитектуру и только потом получает права на коммиты. Агент должен пройти тот же путь. За несколько месяцев работы в режиме «спроси» накапливается обратная связь: какие вопросы задают чаще всего, где контекстной инфраструктуре не хватает данных, какие ответы требуют уточнения. Эта обратная связь бесценна для улучшения агента перед переходом к следующей фазе.
Переоценка метрик успеха: не количество закрытых задач, а качество ответов
Традиционные KPI для агентов-разработчиков - количество выполненных задач, процент успешных коммитов - ведут в тупик. В описанном кейсе агент провалил эти метрики с результатом ноль. Но по альтернативным метрикам он оказался сверхуспешным: время, сэкономленное аналитиками, точность ответов на исследовательские запросы, покрытие системы знаниями.
OpenAI Presence, корпоративная платформа для голосовых и текстовых ИИ-агентов, подтверждает этот подход. Собственная линия поддержки OpenAI на базе Presence решает 75% входящих запросов без участия человека. Метрика - не количество закрытых тикетов, а процент запросов, решённых без эскалации. Среди первых клиентов Presence - банк BBVA, телекоммуникационная SoftBank и страховая группа IAG. Все они начинали с режима ответов на вопросы, а не с автономных действий.
Остальные уроки коротко:
- Инвестируйте в контекстную инфраструктуру. Она может оказаться ценнее самого агента. Графы кода и синхронизируемая база знаний - самостоятельный продукт, который усиливает всю команду, а не только агента.
- Не пытайтесь формализовать «простые задачи» без глубокого понимания домена. Сложность задачи определяется не количеством строк кода, а количеством связей, которые нужно учесть. В микросервисной архитектуре таких связей десятки даже для тривиального изменения.
- В regulated-индустриях прозрачность и объяснимость важнее автономности. Агент, который не может объяснить свои действия, не получит доступ к продакшену. Криптографическая идентичность и аудит действий - минимальные требования.
Взгляд в будущее: агенты, протоколы и экосистемы
Описанный подход - часть более широкого тренда. Индустрия движется к агентом с контекстом и прозрачной идентичностью. Block запустила Buzz - платформу, где люди и ИИ-агенты работают в едином пространстве на открытом протоколе Nostr. Агенты получают криптографическую идентичность, права доступа и историю действий. Для подключения используется Agent Client Protocol (ACP) - открытый протокол взаимодействия ИИ-агентов с редакторами кода и рабочими средами. Buzz поддерживает Claude Code, Codex от OpenAI и фреймворк goose от Block.
OpenAI Presence идёт тем же путём: агенты встраиваются в корпоративные бизнес-процессы с чёткими правами и аудитом. Ключевая проблема везде одна - доверие и контекст. Без них агент остаётся демо-версией, которая не доходит до продакшена. Скорость генерации кода - фиктивный KPI, если код нельзя безопасно внедрить и поддерживать.
Заключение: главный продукт - не агент, а знания о системе
Побочный продукт оказался основным. Инвестиции в понимание собственной системы через графы кода и базы знаний окупаются, даже если агент-исполнитель не взлетит. Контекстная инфраструктура усиливает аналитиков, онбордит новых разработчиков и готовит почву для будущих агентов, которые когда-нибудь получат права на коммиты.
Начинайте с малого: постройте граф кодовой базы на tree-sitter, настройте синхронизацию с коммитами и запустите режим «спроси про систему». Метрика успеха первого этапа - не количество закрытых задач, а время, которое команда сэкономила на поиске информации. Архитектура самописного агента с оркестрацией LLM, памятью и инструментами - тема отдельного разбора, но фундамент всегда один: контекстная инфраструктура, которой команда доверяет.