Autoaperfeiçoamento Recursivo de Linguagens: Aprimorando a Inteligência de Código em ~280 Linguagens

Os números neste post refletem o sistema no momento da publicação (maio de 2026). Consulte nossa página da equipe para números atualizados.

O Maguyva extrai símbolos, referências e um grafo de dependências a partir de código-fonte em aproximadamente 280 linguagens. Cada linguagem é um handler tree-sitter personalizado — queries, heurísticas, casos extremos — e cada handler pode estar sutilmente errado à sua própria maneira. Uma chamada de método emitida como uma leitura. Uma função atribuída ao escopo delimitador errado. Um relacionamento que simplesmente não existe.

Você não pode auditar isso manualmente. Nenhuma equipe consegue ler a saída de extração em 280 gramáticas e identificar as arestas ruins. Então a pergunta interessante não é “a nossa extração está correta” — é “como você descobre que ela está errada, nessa amplitude, sem um humano em cada loop”. Nossa resposta é o autoaperfeiçoamento recursivo de linguagens: um loop de qualidade guiado por agentes de linguagem, um LLM atuando como juiz, e uma regra que continuamos reaprendendo: verde não é o mesmo que correto.

Verde não é correto

Toda linguagem tem uma suíte de fixtures, e um gate de release a pontua em cinco dimensões — precisão, integridade estrutural, completude, qualidade e performance. Uma linguagem só fica VERDE quando, em suas fixtures, a precisão é ≥ 0,95, o recall é ≥ 0,99 e o F1 é ≥ 0,97, com pelo menos 20 arestas esperadas para confiança estatística. Abaixo disso, é AMARELA ou VERMELHA, e não vai para produção.

Esse gate é necessário, mas não suficiente. Fixtures validam contra fixtures que nós escrevemos. Elas codificam os casos que já pensamos. Um handler pode ser impecável em suas fixtures e ainda assim estropiar um padrão que só aparece em código real — um idioma de macro, um método com generic-bound, um recurso de linguagem para o qual ninguém escreveu uma fixture. VERDE significa que as fixtures passam. Não significa que um repositório real seja extraído de forma limpa. Então o loop precisa deixar as fixtures para trás e olhar para o mundo real.

O loop interno: verificação pontual, julgamento, correção, prova

O loop central roda uma linguagem por vez:

        ┌──────────────────────────────────────────────────────────┐
        │                                                          │
        ▼                                                          │
  1. corpus run ── clone real-world repos, extract relationships   │
        │                                                          │
        ▼                                                          │
  2. spot-check 100 edges (seed 42, then seed 123 to cross-check)  │
        │                                                          │
        ▼                                                          │
  3. LLM judge classifies every sampled edge:                      │
        CORRECT · FALSE_POSITIVE · TYPE_ERROR ·                    │
        SCOPE_ERROR · METADATA_ERROR                               │
        │                                                          │
        ▼                                                          │
  4. fix ONE thing — handler .py, .scm query, or config           │
        │                                                          │
        ▼                                                          │
  5. re-validate — F1 + re-classify + manifest diff (no regressions)│
        │                                                          │
   better? ──no──► revert, try a different fix ────────────────────┤
        │ yes                                                       │
        ▼                                                           │
  6. promote the fix into fixtures (a permanent regression guard) ──┘

Algumas coisas fazem isso funcionar em vez de apenas se debater.

O juiz é o agente, não uma chamada de API. Quando dizemos “LLM como juiz”, queremos dizer que o próprio agente de linguagem lê cada aresta amostrada em comparação com o código-fonte real e a classifica com uma rubrica fixa de cinco categorias: essa aresta está correta, é um falso positivo, é o relacionamento certo com o tipo errado, está anexada ao escopo errado, ou carrega metadados errados? Essa rubrica é o jogo inteiro — “taxa de erro de 23%” não significa nada até você saber se são defeitos reais ou o juiz contando errado.

Corrija uma coisa, depois prove. Cada iteração muda exatamente um ativo editável, depois roda novamente contra um harness fixo e mantém a mudança apenas se o F1 melhorar e a reclassificação parecer melhor. Se não melhorar, ela é revertida. Nada de lote de edições especulativas, nada de “deveria estar melhor”. Uma mudança conquista o seu lugar ou desaparece. E quando uma correção se mantém, ela é promovida para a suíte de fixtures — para que o bug que ela corrigiu nunca possa voltar silenciosamente. Essa etapa de promoção é o que torna o loop recursivo, e não apenas repetitivo: cada passagem endurece o oráculo contra o qual a próxima passagem valida.

A lição que continuamos reaprendendo: as métricas superestimam

Eis a armadilha, e caímos direto nela. As métricas secundárias do corpus — com que frequência um alvo extraído não tem símbolo resolvível, quantos símbolos parecem “órfãos”, e assim por diante — superestimam problemas massivamente. Na maioria das vezes, são artefatos de paradigma, não bugs.

O exemplo mais claro: llvm certa vez mostrou uma taxa de 73% de “origem sem símbolo” e foi rotulado como catastrófico. Investigamos. A precisão real era de 98,5%. Os “símbolos ausentes” eram quase todos referências externas legítimas — chamadas para a biblioteca padrão, para frameworks, para código que vive fora do repositório. A métrica estava medindo uma propriedade da linguagem, não um defeito no handler. Linguagens como Zig, COBOL e Odin mostram taxas de “órfãos” de 65–70% e estão inteiramente corretas; COBOL não tinha erros reais.

Se tivéssemos deixado esses números guiarem o trabalho, teríamos gastado semanas “corrigindo” handlers que já estavam certos e ignorando as linguagens com bugs reais e silenciosos. A conclusão é direta: as métricas agregadas são, na melhor das hipóteses, um sinal aproximado de triagem. O verdadeiro sinal de qualidade é a verificação pontual com classificação de arestas — olhar para arestas reais em repositórios reais e julgá-las uma a uma. Dados acima da intuição, mas só depois que você sabe quais dados estão dizendo a verdade.

O loop externo: uma frota, não uma maratona

Uma linguagem de cada vez levaria uma eternidade em 280 delas, então o loop interno é envolvido por um loop externo que roda muitas em paralelo.

   pick a wave of near-GREEN / high-error languages
        │
        ▼
   fan out 10–15 agents, each ISOLATED in its own git worktree,
   each grinding ONE language, committing to its own branch
        │
        ▼
   orchestrator integrates serially: file-scoped apply, then
   `manifest diff` — any cross-language regression blocks the batch
        │
        ▼
   gated push (reviewed and confirmed) ──► rotate to the next wave

Cada agente trabalha em um worktree descartável, para que não pisem uns nos outros. O orquestrador integra as correções deles uma de cada vez, cada uma atrás de uma verificação de regressão de manifesto completo: uma mudança que ajuda a sua própria linguagem, mas silenciosamente quebra três outras, não é integrada. A integração passa por um gate e é confirmada antes de qualquer coisa ser enviada — o gate de regressão decide o que é seguro, um humano ainda decide o que vai para produção. Depois o pool gira para o próximo conjunto de linguagens e tudo roda de novo.

O que ainda é imperfeito

O juiz pode errar, e o erro tem uma direção: um agente rodando com contexto insuficiente superestima. Em um lote, oito linguagens foram sinalizadas com 5–20% de erro; na inspeção, apenas uma era um bug real específico da linguagem — o resto eram erros do juiz por não captar a semântica própria da linguagem (uma linha de origem legitimamente emitindo várias arestas, vinculações de parâmetro modeladas como atribuições, linguagens com referência por identificador). É por isso que amostramos com duas seeds e fazemos verificação cruzada, e por que uma discordância entre o juiz e as fixtures é tratada como o sinal mais interessante, não como um veredito definitivo — às vezes a fixture é o que está errado.

Também somos honestos sobre a meta. O objetivo é zero erros reais, ponto final — mas “zero” é uma direção rumo à qual refinamos, linguagem por linguagem, não uma caixa que se marca. Sempre há outro repositório com outro idioma.

Conquistado, Não Afirmado

Tudo o que o Maguyva faz por um agente — encontrar um símbolo, rastrear uma dependência, responder a uma pergunta com código citado — depende de a extração por baixo estar certa. Em 280 linguagens, “certo” não pode ser afirmado; precisa ser continuamente conquistado contra código real. O loop é como conquistamos isso: um ciclo autônomo de verificação pontual e correção que trata as próprias métricas com suspeita, prova cada mudança e transforma cada correção em uma guarda contra a próxima regressão. Não é glamouroso. É o trabalho que nos permite dizer “damos suporte à sua linguagem” e realmente significar isso. Verde é fácil. Correto é conquistado.