4

Meus 2 cents,

Parabens pelo post !

De fato eh uma ideia um tanto diferente - nao lembro de ter visto este tipo de abordagem usando o tree-sitter como um app separado.

Mas confesso que achei que ficou faltando no post a "cola" do uso do tree-sitter com o LLM.

Voce comenta de passar primeiro pelo tree-sitter e com a saida aplicar no LLM, mas nao vi (ou pelo menos para mim nao ficou claro) como voce implementou o uso dele (talvez copia e cola a saida no prompt ?): se voce puder esclarecer mais o uso especifico seria bem legal (na verdade estou imaginando como ficaria uma skill com uso da tool para integrar isso).

Obrigado por compartilhar !

Saude e Sucesso !

Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS

Carregando publicação patrocinada...
2

Up. To curioso pra saber como foi essa implementação. Eu nunca usei tree-sitter (exceto em plugins do Neovim), mas imaginaria q o autor pegou a saída do tree-sitter na linha de comando e de alguma forma jogou esses dados no LLM?

1

Quase isso! Não é a saída crua do CLI: uso py-tree-sitter como biblioteca, num script que percorre a AST e monta o grafo em dois dicionários Python (callers e callees). O blast radius é só um BFS nesse grafo.

O que vai pro LLM no fim é o conteúdo dos 7 arquivos da lista, concatenado no prompt. A árvore em si fica toda do lado de cá.

1

Verdade, essa parte ficou implícita no post mesmo. No meu setup é um script Python com py-tree-sitter: ele percorre a AST de cada arquivo, monta dois dicionários (quem chama / quem é chamado) e roda um BFS a partir do arquivo do diff. A saída é a lista de arquivos afetados, e é o conteúdo desses arquivos que entra no prompt de revisão, concatenado. O modelo nunca vê AST nenhuma.

Sobre a skill: é o próximo passo que eu quero dar, expor o blast radius como tool em vez de montar o contexto na mão. Valeu pela troca!