Разработчик собрал локальный семантический индекс для ИИ-агента на Rails-монолите в 3,5

За последний год инструментов для агентной разработки стало столько, что в них легко потеряться. Одни обещают сохранять контекст между сессиями, другие — понимать всю кодовую базу целиком, третьи — память, планирование и автономность в одном флаконе. На GitHub каждую неделю появляются репозитории с внушительным числом звёзд, которые на поверку оказываются README-проектами; другие честно работают на демо-репозитории и падают с OOM при первой же встрече с реальным энтерпрайз-проектом. Разработчик, о котором идёт речь, прошёл этот путь на собственном монолите — US B2B SaaS на Rails в 3,5 млн строк — и в итоге сделал свой инструмент под названием TeaRAG.

Осенью прошлого года автор пользовался связкой Claude + RooCode + семантический поиск на Ollama. Связка перестала работать, и он решил полностью пересесть на Claude Code, начав искать замену семантическому индексу. Альтернативы не подошли: на монолите в 3,5 млн строк они либо индексировались часами, либо требовали отдать код в облако и заплатить за эмбеддинги, либо поддерживали Ruby номинально. Тогда он форкнул простой движок семантического поиска на Ollama + Qdrant и сделал его полностью локальным, чтобы ни код, ни его производные — индекс, эмбеддинги, граф вызовов — никуда не уезжали. На инструмент ушло больше полугода.

Какие проблемы решает TeaRAG. Первая — разрыв словарей. Агент не находит логику, которую человек находит за две минуты: grep даёт сотню совпадений, файлы читаются подряд, контекст выгорает. При этом по всей кодовой базе то, что продукт называет invoice, в коде называется bill, а payment и вовсе живёт под третьим именем. Такой разрыв никаким количеством итераций grep не берётся. Вторая — скорость индексации. У исходного проекта, который автор форкнул, полная индексация занимала от четырёх до десяти часов, инкремент по сотне коммитов — сорок минут; у Roo — пятьдесят-шестьдесят минут. Автору нужны были минуты. Третья — поддержка Ruby. Чанки резались не по AST, качество оставляло желать лучшего, а для Ruby стилистика проекта — это половина точности генерации. Разрешение вызовов в динамическом языке, где половина кода — DSL (Rails-макросы, delegate, scope, плюс DSL каждого второго гема), в инструментах для агентов тогда не делал никто.

Четвёртая проблема — агент копирует первый похожий код, а не правильный. Он не отличает стабильный код от хотспота, не знает, чей он и где чаще всего всплывают баги — то знание, которое обычно живёт в голове у сеньора. Пятая — агент не видит структуру: кто вызывает этот метод, что заденет изменение, где циклические зависимости. Для него это просто соседние файлы. Шестая — агент переизобретает существующее: N-й retry-хелпер, N-я валидация, N-й форматтер дат. Это единственный класс ущерба, у которого нет дублирующей защиты: галлюцинации ловит компилятор, стиль — ревью, регрессии — тесты, а N-й корректный способ сделать то же самое не ловит никто. Седьмая — даже с подключённым индексом агент им не пользуется или пользуется невпопад: по привычке идёт в grep, для точного имени символа зовёт семантический поиск вместо мгновенного lookup'а, игнорирует режимы ранжирования и путает параметры. Подключить MCP-сервер — ещё не рабочий процесс: знание «когда и какой инструмент» должно приезжать вместе с инструментом.

Автор подчёркивает, что эти проблемы не выдуманы им. Впервые он попробовал Claude в июне 2025 — и остался разочарован. Не потому, что модель была слабой: ей было сложно ориентироваться в большом монолите, где, чтобы найти нужную логику, надо знать, как она исторически называется. Лимит токенов сгорал за минуты в обмен на сомнительные результаты, и через пару недель подписку он отменил. Всё изменилось с появлением семантического поиска в Roo: преимущества семантического индекса стали очевидны, несмотря на недостатки, которые тогда казались мелочами. А потом, месяц за месяцем работая с индексом, он начал эти недостатки замечать по-настоящему.

Поворот случился после появления TeaRAG и его демонстрации внутри компании. CTO (ex-FAANG) задал один вопрос: «А как твой движок отличит хороший код от плохого?» Ответа в тот момент не было. С этого вопроса начался ресёрч, который не закончился до сих пор, — и по ходу выяснилось, что ни одна из проблем не придумана автором: под каждой лежит либо исследование, местами полувековой давности, либо ход кого-то из крупных игроков, либо и то и другое.

Контекст для читателя, который впервые слышит о теме. Агентная разработка — это подход, при котором ИИ-агент не просто дописывает строку в редакторе, а сам ищет по кодовой базе, читает файлы, вызывает инструменты и вносит изменения. Чтобы агент не тонул в миллионах строк, ему нужен семантический индекс: код разбивается на фрагменты, каждый превращается в вектор (эмбеддинг), и поиск идёт по смыслу, а не по точному совпадению строки. Хранят такие векторы в векторных базах — Qdrant здесь как раз один из популярных open-source вариантов, а Ollama позволяет держать модели эмбеддингов локально. Главная развилка — облако или локальная машина: облако быстрее и проще, но для энтерпрайз-кода это вопрос безопасности и денег за эмбеддинги. TeaRAG выбирает локальный путь, и в этом его отличие от большинства готовых решений.

Что это меняет для отрасли. Инструменты агентной разработки пока плохо работают на больших монолитах и динамических языках вроде Ruby — там, где половина кода это DSL и метапрограммирование. Появление локальных индексов с разбором по AST и графом вызовов закрывает сразу несколько болей: скорость, приватность и качество подсказок. Вопрос CTO про «хороший код против плохого» показывает, куда движется тема дальше: агенту мало найти похожий фрагмент — ему нужно понимать, заслуживает ли этот фрагмент копирования.