Sebastian Schkudlara
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
████████████████████████████████████████████████
██ ██████ ██████ ███████
██ ██◉ ◉██ ██ ██ ██
██ ██ ▽▽ ██ ██████ █████
██ ██ ◡◡ ██ ██ ██
██████ ██████ ██ ███████
████████████████████████████████████████████████
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
any cli implements · any cli validates
Hoy lanzamos Lope como open source: un runner de sprints autónomo con un ensemble de validadores multi-CLI. Un CLI de IA escribe el código. Otro diferente lo revisa. La mayoría vota si la fase se aprueba. Sin el punto ciego del modelo único.
GitHub: github.com/traylinx/lope · Licencia MIT · v0.3.0 (primer lanzamiento público) · Cero dependencias Python.
El problema del punto ciego que nadie quiere admitir
Esto ocurre todos los días en cualquier codebase que use asistentes de IA. Claude escribe una función. Le preguntas a Claude si la función es correcta. Claude dice que sí. La despliegas. Se rompe en producción porque el caso límite que Claude no pensó al escribir es también el caso límite que Claude no pensó al revisar.
Esto es fallo correlado. La misma lógica que produjo el bug aprueba el bug. No es un problema específico de Claude. GPT-4 lo tiene. Gemini lo tiene. Todos los modelos lo tienen cuando revisan su propio output, porque los puntos ciegos de su distribución de entrenamiento aparecen en ambos lados del bucle.
Los humanos resolvimos esto hace mucho. Lo llamamos code review, y el punto central 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. Eso no es un defecto del proceso. Es el mecanismo.
Lope aplica ese mismo principio al código escrito por IA. Distintos modelos tienen distintos puntos ciegos. Ponlos a trabajar entre sí y las brechas afloran.
Qué hace Lope exactamente
Lope es un runner de sprints. Le indicas un objetivo. Redacta un documento de sprint estructurado (fases, entregables, criterios de éxito), lo envía a los CLIs de IA que hayas elegido para revisión, revisa hasta que todos pasen, y luego ejecuta el sprint fase a fase con otra ronda de validación tras cada fase.
Así se ve desde dentro de Claude Code:
Tú: /lope-negotiate "Añadir autenticación JWT con refresh tokens"
Ronda 1 el drafter propone sprint doc (4 fases)
Ronda 1 opencode + vibe + gemini revisan... NEEDS_FIX (0.78)
- Falta rate limiting en el endpoint de refresh
- Sin test para el caso límite de token expirado
Ronda 2 el drafter revisa
Ronda 2 opencode + vibe + gemini revisan... PASS (0.93)
Guardado: SPRINT-JWT-AUTH.md
Tú: /lope-execute SPRINT-JWT-AUTH.md
Fase 1 scaffold ................ PASS 0.95 12s
Fase 2 core-middleware ......... PASS 0.91 34s
Fase 3 refresh-rotation ........ PASS 0.88 28s
Fase 4 integration-tests ....... PASS 0.94 19s
4/4 PASS | confianza media 0.92 | 93s
Ese es el bucle completo. Negociar, ejecutar, auditar. Cada fase produce un bloque de veredicto con estado, confianza e instrucciones específicas de corrección en caso de fallo. Tres intentos por fase antes de escalar. Todo queda registrado en un archivo de journal para que puedas buscar “por qué falló la fase 2 el martes pasado” seis meses después.
12 validadores integrados, infinitos personalizados
Lope incluye adaptadores para 12 CLIs de IA desde el primer día. Todos son binarios estándar, sin modificaciones: sin plugins, sin gestión de API keys dentro de lope. Si claude --print "hola" funciona en tu terminal, Claude es un validador de Lope.
Los doce:
| CLI | Qué es |
|---|---|
| Claude Code | El CLI de programación de Anthropic |
| OpenCode | El agente terminal del equipo de SST |
| Gemini CLI | El CLI de Google |
| OpenAI Codex | El nuevo CLI de programación de OpenAI |
| Mistral Vibe | El flamante CLI de programación de Mistral (adaptador de primera clase) |
| Aider | El clásico coder nativo en git |
| Ollama | Modelos locales, sin autenticación |
| Goose | El agente open source de Block |
| Open Interpreter | El intérprete de código original |
| llama.cpp | Inferencia local más rápida |
| GitHub Copilot CLI | El comando gh copilot de GitHub |
| Amazon Q | El asistente para desarrolladores de AWS |
Y si quieres algo que no está en esa lista, lo añades con cinco líneas de JSON en ~/.lope/config.json. Dos tipos de proveedor cubren cualquier backend de IA: subprocess para herramientas CLI y http para endpoints API. Seguridad garantizada (sin interpolación de shell, sin filtraciones de variables de entorno a argv). Ese es todo el mecanismo de extensión.
Groq, API de Anthropic, API de OpenAI, endpoint autoalojado o binario local poco conocido: mientras responda en texto, Lope puede votarlo.
No solo código: ingeniería, negocio, investigación
Esta es la parte que más nos sorprendió cuando lo usamos internamente. El mismo bucle validador que detecta bugs también detecta brechas en un brief de marketing, un proceso de cierre financiero trimestral, una revisión sistemática de literatura, un entregable de consultoría o una auditoría de cumplimiento del RGPD.
Pasa --domain business y el rol del validador cambia. En lugar de un ingeniero staff senior revisando bugs, obtienes un responsable de operaciones senior revisando realismo de plazos, asignación de presupuesto, definición de KPIs y adecuación a la audiencia. Pasa --domain research y obtienes un investigador principal revisando rigor metodológico, sesgo de muestreo y reproducibilidad.
# Ingeniería
lope negotiate "Añadir rate limiting al API gateway"
# Negocio
lope negotiate "Campaña de marketing Q2 para el segmento enterprise" --domain business
# Investigación
lope negotiate "Revisión sistemática de técnicas de eficiencia en transformers" --domain research
Mismo bucle central. Diferente prompt de rol, diferentes etiquetas, diferentes comprobaciones. Tenemos un post dedicado a esto próximamente, pero el resumen es: si puedes escribirlo como fases con entregables y criterios de éxito, lope puede validarlo.
Modo caveman inteligente
La frase es un guiño. El modo suena primitivo (quita artículos, habla en fragmentos) pero la compresión es lingüísticamente precisa. Código, rutas, números de línea, mensajes de error y comandos permanecen exactos. Solo la prosa envolvente se comprime.
Antes, respuesta del validador:
“He revisado la propuesta con detenimiento y creo que hay algunos problemas que probablemente deberían abordarse antes de continuar. Concretamente, he notado que el middleware de autenticación no parece manejar el caso en el que el token acaba de expirar…”
Después, mismo validador, modo caveman activo:
“Auth middleware falla en caso de token expirado. Añadir rate limit en /refresh. Corregir en middleware/auth.go:142.”
60 tokens vs 22 tokens. 50 a 65 por ciento menos tokens por respuesta, misma información. En un sprint con 3 validadores, 4 fases y 1 reintento de media, son 36 llamadas a validadores. El ahorro se acumula rápido en APIs de pago.
Activado por defecto. LOPE_CAVEMAN=off si prefieres respuestas detalladas. Crédito donde corresponde: las reglas de concisión provienen de JuliusBrussee/caveman (MIT). Lope las integra en el pipeline de inyección de prompts al validador.
Novedades en v0.3.0
v0.3.0 es el primer lanzamiento público, y trae tres decisiones arquitectónicas que la mayoría de bucles validadores que he visto omiten:
Revisión validadora en dos etapas por fase. Tras cada fase, los validadores primero hacen una pasada de conformidad con la especificación (“¿este output coincide con el objetivo de la fase?”) y luego una pasada separada de calidad de código (“¿está bien construido?”). Un NEEDS_FIX en la especificación corta la pasada de calidad, por lo que nunca desperdicias una revisión de calidad en código que ni siquiera cumple el requisito. Esto impide que “código pulido que no cumple el objetivo” se cuele a través de un diff con buena pinta.
Gate de evidencia antes de completar. Cualquier validador que devuelva PASS con una justificación sin evidencia — sin referencia archivo:línea, sin output de test, sin bloque de código, sin frase de verificación explícita — se degrada automáticamente a NEEDS_FIX, con una instrucción sintetizada para “proporcionar evidencia”. Esto elimina el rubber-stamping a nivel de framework. No tienes que confiar en que tus validadores sean rigurosos; el framework lo impone.
Lint de no-placeholder en borradores. Si el negociador produce un sprint doc que contiene TBD, TODO, XXX, FIXME, puntos suspensivos sin más, tokens <placeholder> o fases con listas de artefactos/comprobaciones vacías, el lint se activa y el drafter vuelve a iterar con instrucciones de corrección específicas antes de que ningún validador lo vea. Mucho más barato que pagar a los validadores para que digan “olvidaste rellenar la fase 3.”
Además, v0.3.0 añade:
- Un hook SessionStart que informa automáticamente a tu agente de IA de que lope está disponible, para que los usuarios no tengan que recordar slash commands
- Una skill de auto-trigger
using-lopeque reconoce descripciones en lenguaje natural de trabajo multifase (“planifica el refactor de auth”, “define el alcance de la migración de datos”) e invoca lope en tu nombre - Archivos de manifiesto plugin para Claude Code, Cursor y Gemini CLI para que lope aparezca en el formato de marketplace de plugins de cada host
- Instalación por pegar un prompt (ver abajo)
Instalar: pega una línea en cualquier agente de IA
Sin pip. Sin virtualenv. Sin infierno de dependencias. Python stdlib puro.
Copia esta línea y pégala en cualquier agente de IA que ya uses — Claude Code, Codex, Gemini CLI, OpenCode, Cursor:
Read https://raw.githubusercontent.com/traylinx/lope/main/INSTALL.md and follow the instructions to install lope on this machine natively.
Tu agente obtiene INSTALL.md, sigue los seis pasos cortos, detecta automáticamente qué CLIs ya tienes instalados y escribe slash commands y skills en el directorio nativo de cada host en el formato que ese host espera. Unos 30 segundos de principio a fin. Te informa cuando está activo.
Tras la instalación, estos slash commands funcionan dentro del CLI que elijas:
/lope-negotiate— redacta un sprint doc con revisión validadora multi-ronda/lope-execute— ejecuta fases del sprint con reintentos validadores en el bucle/lope-audit— genera un scorecard con veredictos por fase
O usa el CLI directamente:
alias lope='PYTHONPATH=~/.lope python3 -m lope'
lope status
lope configure
lope negotiate "Tu primer objetivo de sprint"
No tienes que escribir slash commands
Los slash commands están ahí para quien los quiera. Pero la mayoría de usuarios describirá el trabajo en lenguaje natural — “planifica con cuidado el refactor de auth”, “define el alcance de la migración de datos”, “negocia la campaña de Q4, tiene que salir bien” — y la skill using-lope reconoce esas expresiones e invoca lope automáticamente. Palabras clave que la skill detecta: planifica, negocia, define el alcance, redacta, despliega, trabaja con cuidado, sin romper nada, tiene que salir bien.
No necesitas memorizar slash commands.
De dónde viene Lope
Construí lope porque me cansé de desplegar código de IA que solo un modelo había revisado. Cada vez que algo se rompía en producción, volvía al sprint y a la pasada de validación y observaba cómo la misma lógica que produjo el bug aprobaba el bug en la revisión. Juicio de modelo único. Fallo correlado. Los puntos ciegos aparecen en ambos lados del bucle y se cancelan mutuamente.
Monté un bucle validador ensemble como herramienta interna, lo usé durante varios meses en una mezcla de sprints de código y artefactos que no son código (planes de marketing, revisiones de presupuesto, protocolos de investigación), y lo vi atrapar cosas que yo habría pasado por alto. Cuando el bucle empezó a aportar valor también en trabajo que no era código, lo extraje como primitiva standalone.
El nombre, por cierto, viene de Lope de Vega, el dramaturgo del Siglo de Oro español que escribió más de 1.800 obras de teatro coordinando un ensemble estructurado de colaboradores. Boceto, reparto, revisión, fusión, estreno. El modelo de un prolífico escritor rodeado de revisores encajaba perfectamente con la herramienta.
Pruébalo, rómpelo, abre issues
Esta es la v0.3.0 — el primer lanzamiento público. Funciona bien para el caso de uso que resuelve (validación multi-CLI de sprints en dominios de ingeniería, negocio e investigación) pero estamos aprendiendo activamente de los usuarios. Si encuentras un problema, abre un issue. Si encuentras un patrón que deberíamos codificar, abre un PR. Si construyes un validador personalizado para un CLI que no soportamos aún, comparte el JSON en las discusiones del repo para que otros puedan usarlo.
El repo está en github.com/traylinx/lope. Dale una estrella si te gusta. Úsalo si lo necesitas. Cuéntanos qué se rompe.
— Sebastian