Há apenas um ano, quando um agente de codificação precisava entender um projeto, a estratégia era bem simples.
Ler arquivos.
Muitos arquivos.
Quanto mais contexto entrasse na janela do modelo, melhor.
Essa abordagem funcionou… até deixar de funcionar.
Os repositórios cresceram.
As janelas de contexto também.
Mas surgiu um novo problema.
O agente conseguia ler o código.
Não necessariamente conseguia entendê-lo.
E aí começa a mudança mais interessante que estamos vendo este ano.
Os agentes de codificação estão deixando de depender de ler milhares de arquivos para começar a consultar conhecimento estruturado.
Não é uma melhoria incremental.
É uma mudança de arquitetura.
O problema do RAG para código
A primeira geração de ferramentas resolvia o problema através do RAG.
O processo era mais ou menos assim:
Repositório
↓
Embeddings
↓
Busca vetorial
↓
Fragmentos relevantes
↓
LLM
Quando o agente precisava saber como uma classe funcionava…
…buscava alguns arquivos similares e os adicionava ao prompt.
Era uma enorme melhoria em relação a enviar o repositório completo.
Mas ainda tinha limitações.
Ler não significa compreender
Imaginemos uma pergunta bastante comum.
Onde exatamente é calculado o preço final de um pedido?
A resposta provavelmente envolve:
-
vários arquivos,
-
interfaces,
-
classes,
-
dependências,
-
chamadas indiretas,
-
lógica distribuída.
Um RAG tradicional retorna os arquivos “parecidos”.
Mas não entende que:
-
uma função chama outra,
-
um símbolo foi renomeado,
-
um módulo pertence a outro domínio,
-
duas classes nunca aparecem juntas no mesmo arquivo, mas estão intimamente relacionadas.
Isso requer uma representação diferente.
Entra o Knowledge Graph
Em lugar de perguntar:
“Quais arquivos são parecidos com este?”
o agente começa a fazer perguntas muito mais interessantes.
Como, por exemplo:
“Quais funções chamam esta?”
ou
“Quem é o dono deste módulo?”
ou
“Quais mudanças quebraram esta dependência?”
Já não consulta texto.
Consulta relações.
Repositório
↓
Parser
↓
Knowledge Graph
↓
Consulta estruturada
↓
LLM
E essa diferença muda completamente a qualidade do contexto.
Já começamos a ver essa evolução
O interessante é que isso não vem de um único projeto.
Vários repositórios muito distintos estão convergindo para a mesma ideia.
Context7
Quando escrevemos sobre Context7, a proposta parecia simplesmente “melhores documentos para agentes”.
Mas na verdade faz algo mais importante.
Entrega informações estruturadas e versionadas.
O agente deixa de adivinhar APIs lendo documentação antiga.
Consulta uma fonte organizada.
ctx
ctx ataca outro problema.
Meses de conversas com Claude Code, Cursor, Codex ou Gemini CLI ficam salvos como transcripts.
Até agora isso era texto morto.
ctx os normaliza, os indexa em SQLite e permite consultá-los em milissegundos.
Não carrega milhares de linhas novamente.
Recupera exatamente o conhecimento necessário.
codebase-memory-mcp
Provavelmente o exemplo mais claro.
Constrói um knowledge graph persistente do repositório.
Funções.
Símbolos.
Dependências.
Relações.
Tudo exposto através do MCP.
O agente já não precisa percorrer a árvore completa do projeto.
Consulta diretamente o grafo.
Repowise
Repowise leva a ideia um passo além.
Não apenas entende o código.
Também incorpora informações que normalmente vivem fora do repositório.
Por exemplo:
-
propriedade,
-
hotspots,
-
histórico Git,
-
arquitetura,
-
documentação.
Ou seja.
Começa a representar conhecimento organizacional.
Orqenix
E depois aparece o Orqenix.
Seu foco principal não é o grafo.
É o runtime.
Mas volta a aparecer o mesmo padrão.
Memória persistente.
Habilidades.
Plugins.
Aprendizado.
Tudo organizado como conhecimento reutilizável.
Não como prompts gigantes.
Todos estão resolvendo o mesmo problema
Ambora pareçam ferramentas distintas…
…na verdade respondem exatamente à mesma pergunta.
Como evitamos ler o mesmo repositório uma e outra vez?
A resposta começa a ser:
Não o leiamos.
Construamos uma representação melhor.
O que o agente ganha?
Muitíssimo.
Menos tokens
Em lugar de enviar vinte arquivos…
consulta uma relação.
Mais velocidade
Uma consulta estruturada leva milissegundos.
Ler centenas de milhares de tokens não.
Melhor precisão
As relações entre símbolos sobrevivem mesmo que o formato do código mude.
Memória real
O agente pode lembrar:
-
decisões,
-
padrões,
-
arquitetura,
-
workflows,
-
propriedade,
sem precisar redescobri-los a cada sessão.
Estamos vendo a substituição do RAG?
Não exatamente.
Provavelmente estamos vendo sua evolução.
O RAG continua sendo muito útil para:
-
documentação,
-
RFCs,
-
wikis,
-
tickets,
-
especificações.
Mas para entender um repositório…
…cada vez fica mais claro que um grafo de conhecimento oferece uma representação muito mais rica.
Não substitui o RAG.
O complementa.
E em muitos casos, o supera.
O próximo passo
Acredito que durante os próximos doze meses vamos começar a falar muito menos sobre janelas de contexto.
E muito mais sobre:
-
runtimes,
-
memória,
-
grafos,
-
conhecimento estruturado,
-
MCP,
-
context engines.
A pergunta deixará de ser:
Quantos milhões de tokens este modelo suporta?
E passará a ser:
O que ele realmente sabe sobre meu projeto antes de começar a ler arquivos?
Essa diferença é enorme.
Porque um agente inteligente não é necessariamente aquele que mais lê.
É aquele que melhor se lembra.
A tendência
Se algo nos ensinaram Context7, ctx, codebase-memory-mcp, Repowise e Orqenix é que o futuro dos agentes de codificação provavelmente não passa por continuar ampliando a janela de contexto indefinidamente.
Passa por construir melhores representações do conhecimento.
Os humanos também não resolvem um problema relendo um repositório inteiro cada manhã.
Lembram de relações.
Reconhecem padrões.
Sabem onde procurar.
Os agentes começam a fazer exatamente a mesma coisa.
E acredito que essa mudança vai ser muito mais importante do que o próximo modelo com dez milhões mais de tokens de contexto.
Porque o verdadeiro objetivo nunca foi ler mais.
Sempre foi entender melhor.