vord: un juez que el agente no puede convencer

El problema

Un agente de código propone un cambio, decide que el cambio está bien y lo da por terminado. La verificación suele ser otra llamada al mismo modelo: el agente se corrige sus propios deberes. Con la IA escribiendo cada vez más código, la velocidad sube y, sin una red, también la inestabilidad: capas que se saltan, dependencias circulares, entradas de usuario que acaban en una shell.

Los linters y los analizadores llegan tarde a esa conversación. Contestan «¿qué está mal en este código?» cuando el código ya está escrito, en la PR o en CI. Yo quería contestar otra pregunta, dentro del bucle del agente y antes de que los bytes toquen el disco: ¿puede ocurrir esta escritura?

Decisiones

Un juez determinista y separado del escritor. vord hook se engancha al ciclo de edición del agente (Claude Code, Codex o un pre-commit) y evalúa cada escritura contra una política. Si la deniega, el motivo vuelve al contexto del agente para que corrija. El juez no es un prompt: son reglas que leen el árbol sintáctico, así que no hay forma de convencerlo.

Estructura, no texto. Todas las reglas leen el AST neutral que producen los parsers de tree-sitter, no cadenas. Un comentario o un string que se parece a una comprobación de tipo no puede generar un hallazgo.

La arquitectura como regla ejecutable. Además de seguridad y complejidad, vord aplica capas hexagonales sin configuración, pureza del dominio frente a frameworks, métricas de componentes de Martin, SOLID y DDD táctico. Las métricas no son nuevas (vienen de CodeQL, SonarQube o Martin); lo nuevo es que se pueden hacer cumplir, en un solo motor y en varios lenguajes.

Un binario y nada más. Sin JVM, sin servidor, sin base de datos y sin red, salvo que configures un proveedor de LLM para el agente. Se instala con un script, npm, Homebrew, cargo o Docker, y como plugin de Claude Code.

Las excepciones las decide una persona. Una escritura bloqueada puede escalarse y aprobarse una sola vez con vord hook approve, y cada decisión no silenciosa queda en un registro que se consulta con vord hook audit.

Qué hay construido

• Más de 300 reglas en 18 crates: OWASP y taint analysis entre archivos, code smells, arquitectura, DDD, Rust, WordPress, mutation gaps y más.
• 24 lenguajes con tree-sitter, detrás de un AST común.
• vord agent: un agente de código que no puede aprobar su propio trabajo; termina cuando el analizador no ve nada nuevo, no cuando el modelo lo decide.
• Cobertura de flujos (vord flow add) para declarar secuencias críticas que el análisis estático no puede reconstruir solo.
• Importación de SARIF de otras herramientas (Oxlint, Ruff, Clippy) al mismo quality gate, servidor MCP e informes de cumplimiento.

Lo que no hace

vord no tiene comprobador de tipos ni borrow checker. Una escritura que pasa todas las reglas puede seguir fallando en cargo build o tsc. Es un complemento del compilador y de los tests, no un sustituto: el agente debe seguir ejecutándolos antes de dar algo por terminado.

Lo que aprendí

La pregunta útil no era «¿cómo hago que el modelo sea más cuidadoso?», sino «¿qué infraestructura hace que el descuido no llegue a ningún sitio?». Poner el límite fuera del modelo hace que la autonomía sea auditable.