Autosuperación recursiva de lenguajes: afinando la inteligencia de código en ~280 lenguajes
> Damos soporte de inteligencia de código para ~280 lenguajes. Ningún humano puede auditar eso a mano. Así que construimos un bucle de autosuperación recursiva de lenguajes — verificación puntual, LLM como juez, corregir una cosa, revalidar — y lo ejecutamos con una flota de agentes aislados hasta que la extracción sea realmente correcta, no solo verde.
Las cifras de esta publicación reflejan el sistema al momento de su publicación (mayo de 2026). Consulta nuestra página del equipo para ver las cifras actuales.
Maguyva extrae símbolos, referencias y un grafo de dependencias del código fuente en aproximadamente 280 lenguajes. Cada lenguaje es un handler de tree-sitter personalizado — consultas, heurísticas, casos extremos — y cada handler puede estar sutilmente equivocado a su propia manera. Una llamada a método emitida como una lectura. Una función atribuida al alcance envolvente equivocado. Una relación que simplemente no existe.
Eso no se puede auditar a mano. Ningún equipo puede leer la salida de extracción en 280 gramáticas y detectar las aristas malas. Así que la pregunta interesante no es «¿nuestra extracción es correcta?» — es «¿cómo descubres que está mal, a esta escala, sin un humano en cada ciclo?». Nuestra respuesta es la autosuperación recursiva de lenguajes: un bucle de calidad impulsado por agentes de lenguaje, un LLM que actúa como juez, y una regla que seguimos reaprendiendo: verde no es lo mismo que correcto.
Verde no es correcto
Cada lenguaje tiene un conjunto de fixtures, y una compuerta de lanzamiento lo puntúa en cinco dimensiones — precisión, integridad estructural, completitud, calidad y rendimiento. Un lenguaje pasa a VERDE solo cuando, en sus fixtures, la precisión es ≥ 0.95, el recall ≥ 0.99 y el F1 ≥ 0.97, con al menos 20 aristas esperadas para tener confianza estadística. Por debajo de eso es AMARILLO o ROJO, y no se publica.
Esa compuerta es necesaria, pero no suficiente. Los fixtures se validan contra fixtures que nosotros escribimos. Codifican los casos que ya se nos ocurrieron. Un handler puede ser impecable en sus fixtures y aun así estropear un patrón que solo aparece en código real — un modismo de macro, un método con un límite genérico, una característica del lenguaje para la que nadie escribió un fixture. VERDE significa que los fixtures pasan. No significa que un repositorio real se extraiga limpiamente. Así que el bucle tiene que dejar atrás los fixtures y mirar el mundo real.
El bucle interno: verificación puntual, juicio, corrección, prueba
El bucle central se ejecuta para un lenguaje a la 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) ──┘
Hay algunas cosas que hacen que esto funcione en lugar de dar vueltas sin avanzar.
El juez es el agente, no una llamada a una API. Cuando decimos «LLM como juez», nos referimos a que el propio agente de lenguaje lee cada arista muestreada contra la fuente real y la clasifica con una rúbrica fija de cinco categorías: ¿esta arista es correcta, es un falso positivo, es la relación correcta con el tipo equivocado, está unida al alcance equivocado, o lleva metadatos equivocados? Esa rúbrica es todo el juego — un «23% de tasa de error» no significa nada hasta que sabes si son defectos reales o el juez contando mal.
Corrige una cosa, y luego pruébalo. Cada iteración cambia exactamente un activo editable, luego se vuelve a ejecutar contra un arnés fijo y conserva el cambio solo si el F1 mejora y la reclasificación se ve mejor. Si no, se revierte. Nada de lotes de ediciones especulativas, nada de «debería estar mejor». Un cambio se gana su lugar o desaparece. Y cuando una corrección se mantiene, se promueve al conjunto de fixtures — para que el bug que corrigió nunca pueda volver en silencio. Ese paso de promoción es lo que hace que el bucle sea recursivo y no simplemente repetitivo: cada pasada endurece el oráculo contra el que se valida la siguiente pasada.
La lección que seguimos reaprendiendo: las métricas sobrerreportan
Aquí está la trampa, y caímos de lleno en ella. Las métricas secundarias del corpus — con qué frecuencia un destino extraído no tiene un símbolo resoluble, cuántos símbolos parecen «huérfanos», etcétera — sobrerreportan masivamente los problemas. En su mayoría son artefactos de paradigma, no bugs.
El ejemplo más claro: llvm mostró en un momento una tasa del 73% de «fuente sin símbolo» y fue tildado de catastrófico. Investigamos. La precisión real era del 98.5%. Los «símbolos faltantes» eran casi todos referencias externas legítimas — llamadas a la biblioteca estándar, a frameworks, a código que vive fuera del repositorio. La métrica estaba midiendo una propiedad del lenguaje, no un defecto del handler. Lenguajes como Zig, COBOL y Odin muestran tasas de «huérfanos» del 65–70% y son totalmente correctos; COBOL tuvo cero errores reales.
Si hubiéramos dejado que esos números guiaran el trabajo, habríamos pasado semanas «arreglando» handlers que ya estaban bien e ignorando los lenguajes con bugs reales y silenciosos. La conclusión es tajante: las métricas agregadas son, en el mejor de los casos, una señal aproximada de triaje. La señal de calidad real es la verificación puntual con clasificación de aristas — mirar aristas reales en repositorios reales y juzgarlas una por una. Datos por encima de la intuición, pero solo una vez que sabes qué datos están diciendo la verdad.
El bucle externo: una flota, no un maratón
Hacerlo de a un lenguaje a la vez tomaría una eternidad en 280 de ellos, así que el bucle interno se envuelve en uno externo que ejecuta muchos en 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 trabaja en un worktree desechable para que no se pisen entre sí. El orquestador integra sus correcciones de a una, cada una detrás de una verificación de regresión de manifiesto completo: un cambio que ayuda a su propio lenguaje pero rompe silenciosamente otros tres no se integra. La integración está controlada y confirmada antes de que se publique nada — la compuerta de regresión decide qué es seguro, un humano sigue decidiendo qué se lanza. Luego el pool rota hacia el siguiente conjunto de lenguajes y todo el proceso se repite.
Lo que todavía es imperfecto
El juez puede equivocarse, y el error tiene una dirección: un agente que corre con muy poco contexto sobrerreporta. En un lote, ocho lenguajes fueron marcados con un 5–20% de error; al inspeccionarlos, solo uno era un bug real por lenguaje — el resto eran errores del juez por no captar la semántica propia del lenguaje (una línea de fuente que legítimamente emite varias aristas, enlaces de parámetros modelados como asignaciones, lenguajes con una referencia por identificador). Por eso muestreamos con dos semillas y hacemos verificación cruzada, y por eso un desacuerdo entre el juez y los fixtures se trata como la señal más interesante, no como un veredicto definitivo — a veces lo que está mal es el fixture.
También somos honestos sobre el objetivo. La meta es cero errores reales, punto — pero «cero» es una dirección hacia la que nos esforzamos, lenguaje por lenguaje, no una casilla que se marca. Siempre hay otro repositorio con otro modismo.
Ganado, no afirmado
Todo lo que Maguyva hace por un agente — encontrar un símbolo, rastrear una dependencia, responder una pregunta con código citado — descansa en que la extracción de base sea correcta. En 280 lenguajes, «correcto» no se puede simplemente afirmar; hay que ganárselo continuamente contra código real. El bucle es cómo nos lo ganamos: un ciclo autónomo de verificación puntual y corrección que trata sus propias métricas con sospecha, prueba cada cambio, y convierte cada corrección en una guardia contra la próxima regresión. No es glamoroso. Es el trabajo que nos permite decir «damos soporte a tu lenguaje» y decirlo en serio. Verde es fácil. Correcto se gana.
Lectura relacionada
Más del registro de build de Maguyva
Por qué actualizamos la búsqueda de código a voyage-4-large_
Migramos nuestros embeddings de código a voyage-4-large — actualmente en la cima de la tabla pública de RTEB para recuperación de código. La versión honesta: el compromiso que hacemos, qué indexamos realmente, y por qué pagamos por embeddings premium.
Búsqueda por fusión multimodal: eligiendo el recuperador correcto para cada consulta_
Una consulta como 'dónde está definido parseConfig' necesita una búsqueda distinta a 'cómo funciona la autenticación'. Maguyva clasifica la intención, pondera en consecuencia cuatro modalidades de recuperación, y fusiona los resultados con Reciprocal Rank Fusion ponderada.
Observabilidad de agentes: hooks, Alloy y Grafana_
Conectamos Claude Code y Codex a un único stack de Grafana con OpenTelemetry y Alloy, y luego usamos trazas y registros para encontrar y corregir problemas de comportamiento de los agentes en su origen.