Por qué construí Lope: el punto ciego del modelo único del que no podía escapar

Una historia de origen corta, porque varias personas han preguntado de dónde vino lope y por qué me molesté en construir otro sprint runner cuando ya hay suficientes.

La respuesta honesta es: no me propuse construir un sprint runner. Me propuse dejar de desplegar código de IA que solo un modelo había revisado, y el bucle que construí para hacerlo resultó ser lo suficientemente útil como para extraerlo.

El problema que no desaparecía

Estaba ejecutando sprints de desarrollo estructurado con asistencia de IA. El patrón era el mismo cada vez: describir el trabajo, hacer que el agente redactara un plan, pedirle al agente que ejecutara el plan fase a fase. Funcionaba lo suficientemente bien como para que dejara de escribir código a mano para nada rutinario.

Pero seguía desplegando cosas que se rompían de formas que el modelo debería haber detectado.

Cada vez que ocurría, volvía al sprint y a la pasada de validación y los leía con cuidado. Y cada vez, la misma lógica que produjo el bug aprobaba el bug en la revisión. El modelo no notó el caso límite cuando escribió el código, y no lo notó cuando revisó el código, porque el punto ciego estaba en el mismo lugar en ambos lados del bucle.

Esto es fallo correlado. No es un problema de Claude ni de GPT ni de Gemini. Es lo que ocurre cuando un solo modelo juzga su propio trabajo. Los puntos ciegos en su distribución de entrenamiento aparecen dos veces, y se cancelan mutuamente.

Los humanos resolvimos esto hace mucho. Lo llamamos code review, y todo el mecanismo es que un segundo par de ojos, con un marco diferente, atrapa lo que el primero pasó por alto. Dos ingenieros senior que se formaron en empresas distintas encontrarán bugs diferentes en el mismo diff. No es un defecto de la revisión humana, es el punto central.

El bucle con el que terminé

Monté un bucle validador ensemble. Cuando el CLI principal redacta un sprint, envía el borrador a otros CLIs — de diferentes familias, diferentes proveedores, diferentes datos de entrenamiento — para revisión independiente. Cada validador vota PASS, NEEDS_FIX o FAIL con una puntuación de confianza y una justificación. La mayoría decide. En NEEDS_FIX, el drafter revisa con instrucciones de corrección específicas. En FAIL, el sprint escala.

El mismo patrón corre después de cada fase durante la ejecución. Distintas familias de modelos detectan distintos problemas. Claude Code y Codex tienen cierto solapamiento (ambos entrenados en EE.UU., ambos de propósito general), pero Gemini atrapa cosas que ellos pasan por alto. Mistral Vibe señala cosas distintas de nuevo. Aider aporta una perspectiva nativa en git. Ollama corriendo un modelo local tiene un perfil de puntos ciegos totalmente diferente. Cinco CLIs estándar revisándose entre sí produce mejor juicio que cualquiera de ellos por separado.

Los primeros sprints que ejecuté a través del bucle detectaron bugs que habría desplegado. Luego empezaron a detectar problemas estructurales, no solo bugs. Planes de rollback ausentes. Límites de fase ambiguos. Criterios de éxito que no coincidían con lo que la fase estaba realmente probando. Scope creep que el drafter no había notado que se colaba.

Ahí me di cuenta de que el bucle no era realmente sobre código. Era sobre revisión de trabajo estructurado con juicio multi-modelo independiente, y el trabajo estructurado está en todas partes.

No solo código

Empecé a ejecutar el bucle en artefactos que no son código. Un plan de marketing para un proyecto paralelo. Una revisión de presupuesto trimestral. Un protocolo de investigación para un paper que estaba redactando. Una revisión legal sobre la que estaba nervioso. Mismo bucle, diferente prompt de rol. Los mismos tipos de detecciones.

El plan de marketing volvió NEEDS_FIX porque los validadores señalaron que el primer borrador confundía las métricas de la semana de lanzamiento con las métricas de retención a largo plazo. La revisión de presupuesto volvió NEEDS_FIX porque un validador notó que el plan de cierre no tenía ningún paso de validación de doble entrada en medio de una migración de sistema. El protocolo de investigación volvió NEEDS_FIX porque otro validador preguntó si los criterios de inclusión manejaban papers en idiomas distintos al inglés.

Cada una de esas detecciones vino de un modelo diferente al que redactó el documento. Ninguna era un bug en el sentido de “el código se cuelga”. Eran brechas en el razonamiento, y distintas familias veían distintas brechas.

Ahí supe que el bucle pertenecía fuera de mi flujo de trabajo personal.

El nombre

Rebauticé el proyecto como lope por tres razones.

Primera, “lope” suena como “loop” en inglés, que es la abstracción central. Todo es un bucle: redactar, revisar, revisar, ejecutar, revisar, revisar, auditar.

Segunda, y esta es la que más me gusta, Lope de Vega, el dramaturgo del Siglo de Oro español, escribió alrededor de 1.800 obras de teatro ejecutando un proceso ensemble estructurado con colaboradores. Redactaba un esquema, repartía piezas a escritores de confianza, fusionaba sus revisiones, estrenaba. El modelo de un prolífico redactor rodeado de un ensemble de revisores encajó perfectamente con la herramienta. Un ingeniero español que construye una herramienta de IA y la nombra en honor a uno de los mayores creadores prolíficos de la historia española: la simetría me pareció demasiado buena para ignorarla.

Tercera, el nombre de trabajo anterior era jerga SaaS aburrida y estaba harto de mirarlo.

Cómo se ve v0.3.0

v0.3.0 es el primer lanzamiento público. Las cosas que realmente uso todos los días:

• Tres modos. /lope-negotiate redacta el sprint doc. /lope-execute ejecuta las fases. /lope-audit genera el scorecard.

• Revisión validadora en dos etapas por fase. Primero una pasada de conformidad con la especificación (“¿coincide esto con el objetivo?”), luego una pasada de calidad del código (“¿está bien construido?”). La pasada de especificación corta el circuito en NEEDS_FIX para que nunca desperdicies una revisión de calidad en trabajo que no cumple el objetivo desde el principio.

• Un gate de verificación antes de completar. Cualquier validador que devuelva PASS con una justificación sin evidencia — sin referencia archivo:línea, sin output de test, sin frase de verificación explícita — se degrada automáticamente a NEEDS_FIX. Elimina el rubber-stamping arquitectónicamente.

• Un lint de no-placeholder en borradores. Si el negociador produce un sprint doc con TBD, TODO, [insertar aquí], o fases con listas de artefactos vacías, el drafter vuelve a iterar antes de que ningún validador lo vea. Más barato que una ronda de validadores.

• 12 adaptadores CLI integrados. Claude Code, OpenCode, Gemini CLI, Codex, Mistral Vibe, Aider, Ollama, Goose, Open Interpreter, llama.cpp, GitHub Copilot CLI, Amazon Q. Más infinitos personalizados mediante cinco líneas de JSON en ~/.lope/config.json.

• Tres dominios, no solo código. engineering, business, research. Mismo bucle, diferente prompt de rol, diferentes etiquetas de artefactos.

• Modo caveman inteligente. Prompts de validador eficientes en tokens que quitan artículos y cobertura de dudas manteniendo el código, las rutas, los números de línea y los mensajes de error exactos. Aproximadamente un 50-65% de ahorro de tokens por llamada al validador. Adaptado de JuliusBrussee/caveman con crédito.

• Un hook SessionStart que informa automáticamente a los agentes de que lope está disponible, para que los usuarios no tengan que recordar slash commands.

• Una skill de auto-trigger using-lope que reconoce lenguaje natural como “planifica el refactor de auth” e invoca lope en nombre del usuario.

• Instalación por pegar un prompt. Una línea en cualquier agente de IA:

  Read https://raw.githubusercontent.com/traylinx/lope/main/INSTALL.md and follow the instructions to install lope on this machine natively.
  

  El agente obtiene INSTALL.md, sigue los pasos, informa de vuelta. Agnóstico al CLI: escribe skills y comandos en el directorio nativo de cada host en el formato que ese host espera.

• Cero dependencias Python externas. Stdlib puro. Funciona en Python 3.9+ sin venv. El motor tiene alrededor de 2.000 líneas de código legible.

Qué sigue

La lista para v0.4 y más allá:

• Un ejemplo de integración CI adecuado para que los equipos puedan bloquear PRs en el consenso de validadores
• Más presets de dominio (legal, salud, finanzas) con prompts de rol pre-escritos
• Un registro público de configuraciones de validadores para que la gente comparta sus bloques providers personalizados
• Mejor manejo de sprints muy largos donde las ventanas de contexto empiezan a importar

Si quieres ayudar, el repo está en github.com/traylinx/lope. Abre un issue, manda un PR, o simplemente ejecuta un sprint contra algo que de otro modo redactarías a mano esta semana y cuéntame qué se rompió.

— Sebastian