Агент читает 20 файлов ради одной функции. Лечим это графом кода: CodeGraph vs Graphify и другие невиданные твари

Мне регулярно пишут: «У тебя Max-подписка, токенов вагон — зачем городить индексацию кода? Дай агенту grep и не выпендривайся». Полгода назад я бы согласился. Сейчас — нет. Когда агент ищет «где тут авторизация», он спавнит эксплорацию, грепает по ключевым словам и читает 15-20 файлов целиком, чтобы догадаться о связях. Это сотни тысяч токенов, куча tool calls и регулярные промахи. Граф кода схлопывает этот веер чтений в один точный запрос к индексу. Я сейчас гоняю CodeGraph (лёгкий локальный индекс символов для агента), а Graphify (граф знаний всего проекта — код плюс документы, PDF и медиа) только собираюсь попробовать. Это два разных инструмента под разные боли, и их постоянно путают. В статье: чем они отличаются архитектурно, почему модель хранения индекса — следствие этой архитектуры (и как держать индекс при работе с разных машин и командой), их бенчмарки с честной пометкой «не мои цифры», кому что брать — плюс карта соседних инструментов: Gortex, CodeGraphContext, Sourcegraph MCP и Cognee.

https://habr.com/ru/articles/1042930/

#AIагенты #Claude_Code #Codex #codeintelligence #treesitter #MCP #индексациякода #Sourcegraph

Экономия токенов на grep: индекс кода для AI-агентов на Rust + tree-sitter + SQLite + MCP

История идеи проекта Сидел я и делал чанкирование разбора конфигурации 1С в PostgreSQL. Выгрузка конфы мне досталась с 43 расширениями и ноль документации по этим расширениям после 5 команд разработки. Ну, нужно было её разобрать, обогатить бизнес-терминами и превратить во что-то удобоваримое вроде как для RAG. Было всё это долго, нудно, на Питоне, с помощью локальной LLM. Сам я в настоящий момент 1с-ник, но начинал я в своё время с MSSQL-2000 (если кто-то помнит такой), T-SQL, PowerScript, Pascal и пр. романтики. Сидел я, думал о светлом будущем, когда с помощью RAG локальная моделька будет мне писать скрипты, и даже без ошибок (до некоторой степени это получилось). Ну как-то слово за слово, и мне подумалось: есть же семантический поиск по RAG, реализуется MCP-сервером. По сути это запросы — точные, но довольно медленные. А почему тогда во всех остальных случаях, работая с выгрузкой напрямую, модель раз за разом лезет в переборщики файлов — пусть правильно написанные и крайне оптимизированные, но всё же переборщики? КОТОРЫЕ ТРАТЯТ МАССУ ТОКЕНОВ ТУПО НА ЧТЕНИЕ ДЛЯ ПОИСКА?! Почему нельзя это делать запросами в базу данных — нормальными, дешёвыми, точными? И вспомнил я заодно старую идею: когда-то файловую систему в Windows (проект WinFS, времён Vista) хотели сделать похожей на БД, чтобы радикально ускорить работу с файлами. Идею потом свернули, и она как-то забылась. НО я не забыл :):) Идея-то была интересная. Итого — нужно было дать модели инструмент, который заметно экономил бы токены и ускорял поиск данных (особенно в больших массивах кода). И подумалось мне, что не один я такой — есть целый коллектив разработчиков, которому такой инструмент может пригодиться. Поэтому Бог с ним, с Питоном, будем писать на Rust, потому что Rust — это база! (с)

https://habr.com/ru/articles/1042686/

#rust #aiагенты #mcp #claude_code #sqlite #treesitter #индексация_кода #1С #bsl

Is there anywhere any "official" discussion about how to continue with nvim treesitter?

#nvim #treesitter #nvimtreesitter #Neovim

CodeGraph: граф кода для Claude Code вместо grep по файлам. Разбираю архитектуру и проверяю бенчмарки

Если вы работаете с Claude Code на больших проектах, знаете картину: задаёшь вопрос “как устроена авторизация” — и агент рекурсивно бегает по файлам через grep, жжёт токены и время. Я уже разбирал SocratiCode, который решает это через векторный поиск. CodeGraph идёт другим путём — строит граф символов через tree-sitter и хранит в SQLite. Разобрал архитектуру, проверил бенчмарки (92% меньше вызовов — правда, но с нюансами) и сравнил с альтернативами. Заодно поправил телеграм-маркетинг про выдуманного “агента Hermes”.

https://habr.com/ru/articles/1038474/

#Claude_Code #MCP #AIагенты #treesitter #SQLite #индексация_кода #CodeGraph #граф_кода

Sabe aquele tipo de bug que fica escondido na sua cara, passa em todos os testes e quando você vai ver, está gerando centenas de falsos positivos? Pois é, passei exatamente por isso recentemente trabalhando no motor de análise estática do Ollanta.

Um de seus componentes o ollanta-scanner, de repente começou a acusar que qualquer chamada de função no código JavaScript era um perigoso eval(), não importava se era uma simples renderização de view ou configuração do sistema.

Fui investigar a fundo e o buraco era bem mais embaixo, envolvendo a forma como o binding Go da API do tree-sitter funciona. O problema não estava na query em si, mas em uma única chamada de método que faltava para avaliar os predicados semânticos.

O código compilava sem reclamar e os testes continuavam verdes porque só validavam o caminho feliz da detecção. Na prática, a ferramenta estava devolvendo todos os matches estruturais crus e ignorando completamente os filtros da regra.

Acabei escrevendo um artigo em meu blog pessoal https://scovl.github.io/2026/05/08/fixgo02/ detalhando toda essa investigação, que no fim das contas virou uma baita reflexão sobre design de APIs, o perigo do acoplamento temporal e aquele viés de confirmação clássico que temos ao esquecer de escrever testes negativos.

Se você trampa com #Go, #desenvolvimento de ferramentas, ou simplesmente curte ler um post-mortem sobre caça a #bugs que dão dor de cabeça, acho que vai gostar do texto.

#go #golang #desenvolvimento #development #developers #ast #cst #treesitter #postmortem

I use #sqlx, and I wanted syntax highlighting for embedded #SQL queries in my #Rust code. Making that work in #Neovim led me to learning a few things about #Treesitter, and #NixOS packaging conventions. Here's my write-up!

Public replies to this post will appear in a comments section under the blog post.

https://sitr.us/2026/05/03/embedded-sql-highlighting-in-neovim/

Experimenting what I can do with #treesitter and #AdaLang :)

```
(compilation (compilation_unit (subprogram_body (procedure_specification name: (identifier)) (handled_sequence_of_statements (null_statement)) endname: (identifier))))
```

#Emacs repeat-mode also combines really well with #expreg (expand-region). expreg looks like a worthy successor to Magnars' `expand-region` package, which many of us have grown to love.

I have it set so `C-c y` marks the semantic 'thing' at point, and subsequent presses of `y` or `u` expand or contract to the next semantic unit.

Works well out of the box. Should work even better if/when I get my head around #treesitter.

This is my config:

(repeat-mode 1)
(defvar expreg-expand-keymap
(define-keymap
"y" #'expreg-expand
"u" #'expreg-contract))

(put #'expreg-expand 'repeat-map 'expreg-expand-keymap)
(put #'expreg-contract 'repeat-map 'expreg-expand-keymap)

(global-set-key (kbd "C-c y") #'expreg-expand)

The Helix modal editor has built-in support for treesitter, but it only ships with some of the R queries: (syntax) highlight, injection, and locals. It does not have yet queries for text objects, tags, indentation or rainbow brackets. At least three of these are available elsewhere; I wonder how hard would it be to adapt those for Helix?

#HelixEditor #RStats #treesitter