Sebastian Schkudlara
Hay un modo en Lope llamado caveman inteligente. Está activo por defecto. Reduce el coste en tokens de cada respuesta validadora entre un 50 y un 65 por ciento sin perder ni un número de línea, ni una ruta, ni un mensaje de error. También es un chiste bastante malo, y voy a explicar por qué el chiste malo importa.
El juego de palabras
“Caveman inteligente” es un guiño. El modo suena primitivo: quita artículos, habla en fragmentos, di lo mínimo posible. La compresión es, en realidad, lingüísticamente precisa. Código, rutas, números de línea, mensajes de error, comandos y hashes permanecen exactos. Solo la prosa envolvente se comprime. Conciso como un cavernícola, preciso como un lingüista.
Todo el truco es una sola directiva que se inyecta al principio de cada prompt del validador:
Responde de forma concisa. Elimina artículos (un, una, el, la), relleno (simplemente, básicamente, literalmente), cobertura de dudas (creo, quizás, podría), amabilidades (claro, encantado de ayudar). Los fragmentos están bien. Mantén exactos: código, rutas, números de línea, comandos, mensajes de error. Justificación = 1 a 3 frases cortas, no párrafos.
Eso es todo. Sin fine-tuning. Sin pipeline de postprocesado. Solo un prefijo de prompt que le dice al validador que deje de escribir ensayos de 400 palabras cuando un ingeniero senior señalaría directamente la línea.
Antes y después
Sin modo caveman (LOPE_CAVEMAN=off):
justificacion: 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, lo cual podría provocar algunos fallos edge case en
producción. Además, sugeriría añadir rate limiting para prevenir el abuso del
endpoint de refresh.
Aproximadamente 65 tokens.
Con modo caveman (LOPE_CAVEMAN=full, el defecto):
justificacion: Auth middleware falla en caso de token expirado. Añadir rate limit
en /refresh. Corregir en middleware/auth.go:142.
Aproximadamente 22 tokens. La misma información. Un 63 por ciento menos de tokens.
Fíjate en lo que se conservó exactamente: middleware/auth.go:142. La ruta del archivo y el número de línea no se “comprimieron”. La compresión es deliberadamente asimétrica. La prosa humana es comprimible. Los identificadores técnicos no lo son, y la ingeniería de prompts de lope le indica al validador exactamente cuál es cuál.
Por qué esto importa a escala
Lope lanza N validadores × M fases × hasta 3 reintentos por sprint.
Un sprint típico tiene 3 validadores, 4 fases y una media de 1 reintento en algún punto. Son 36 llamadas a validadores. Cada llamada genera una respuesta. Cada respuesta se parsea en un bloque de veredicto.
Multiplica 65 tokens por 36 y obtienes 2.340 tokens de pura prosa envolvente por sprint. Multiplica 22 tokens por 36 y obtienes 792. Son 1.548 tokens de ahorro por sprint, por usuario.
Con un validador local (Ollama, llama.cpp) el ahorro es en latencia. Con una API de pago (Groq, Anthropic, OpenAI) el ahorro es en dinero. En cualquier caso, se acumula rápido cuando un equipo está ejecutando docenas de sprints a la semana.
Y todos esos prompts — los built-ins configurados de fábrica (claude, opencode, gemini, codex, aider), los CLIs auto-provisionados (ollama, goose, interpreter, llama-cpp, gh-copilot, amazon-q) y los proveedores personalizados que añadas mediante providers en config.json — reciben la directiva al principio. Sin excepciones, sin validadores omitidos, sin ramas sin tocar.
Por qué los identificadores técnicos permanecen exactos
Esta es la parte que lo convierte en caveman “inteligente” en lugar de solo “caveman”.
Los LLMs son reconocedores de patrones. Cuando les dices “sé conciso”, algunos sobre-comprimen y empiezan a quitar rutas de archivos o a aproximar números de línea. La directiva de Lope es explícita sobre qué no debe comprimirse:
- Fragmentos de código (incluyendo bloques de código inline)
- Rutas de archivo
- Números de línea
- Comandos de shell
- Mensajes de error
- Hashes e IDs
- El formato del bloque
---VERDICT---...---END---
Todo lo que está fuera de esa lista es prosa envolvente y puede comprimirse. El formato del bloque VERDICT no cambia porque el parser depende de él. Si el modo caveman rompiera el parser, todo el ensemble colapsaría, así que tratamos esa estructura como un contrato.
Tres modos
| Modo | Variable de entorno | Cuándo usarlo |
|---|---|---|
full (defecto) |
LOPE_CAVEMAN=full |
Máxima compresión. Quita artículos, relleno, cobertura de dudas. Fragmentos permitidos. |
lite |
LOPE_CAVEMAN=lite |
Solo quita relleno y cobertura de dudas. Mantiene frases completas. Úsalo cuando quieras algo más de contexto. |
off |
LOPE_CAVEMAN=off |
Desactiva completamente. Respuestas detalladas. Úsalo cuando estés depurando lope en sí mismo. |
Configuración por invocación:
LOPE_CAVEMAN=lite lope negotiate "build auth"
Configuración persistente en tu shell:
export LOPE_CAVEMAN=full # ~/.zshrc o ~/.bashrc
Cuándo desactivarlo
Respuesta corta: pocas veces.
Respuesta algo más larga: si estás usando lope para escritura externa donde la prosa del validador es en sí misma el entregable — por ejemplo, revisando una comunicación para el consejo de administración o un documento de consultoría cara al cliente donde quieres que el validador produzca frases pulidas en lugar de fragmentos — establece LOPE_CAVEMAN=off para esa sesión. El bloque de veredicto sigue funcionando, solo que obtienes prosa con forma humana en el campo de justificación.
Para todo lo demás (revisión de código, validación de sprints, auditorías de fases, revisión de metodología, comprobaciones de presupuesto) mantenlo activo. El ahorro es real y la relación señal-ruido mejora notablemente. Los validadores en modo caveman te dicen qué está mal, dónde y cómo arreglarlo, sin el “creo que” y el “quizás” que hace que el output de los LLMs parezca inseguro incluso cuando es correcto.
Crédito
Las reglas de concisión — “quita artículos, mantén el código exacto, patrón cosa-acción-razón” — vienen de JuliusBrussee/caveman (licencia MIT). Julius construyó un CLI standalone de modo caveman que comprime cualquier prompt de generación de texto. La contribución de Lope es integrar esas reglas en el pipeline de inyección de prompts al validador, donde el ahorro se acumula a través de la revisión ensemble multi-ronda.
Si tienes otra herramienta de IA donde pagas por token, lee el repo de Julius. Las ideas son portables.
Consulta ACKNOWLEDGEMENTS.md en el repo de lope para la atribución completa.
El chiste meta
Voy a ser honesto sobre el nombre. Cuando construí esta funcionalidad por primera vez, la llamé “token-savings-mode” porque soy un adulto aburrido. Ahorraba tokens, funcionaba, a nadie le importaba.
Luego una tarde estaba mirando fijamente una respuesta del validador que decía “He revisado esto cuidadosamente y creo que podría haber posiblemente una preocupación menor…” y murmuré “simplemente gruñe.” Y el nombre se reescribió solo. “Modo caveman” se quedó porque todo el mundo entendió inmediatamente lo que significaba sin necesitar un párrafo de documentación.
“Caveman inteligente” es el recordatorio de que la superficie primitiva esconde ingeniería precisa debajo. Prompt conciso, payload exacto, sin contenido técnico descartado, ahorro de costes medible. El chiste tiene peso.
Instala lope, ejecuta un sprint, observa cómo los validadores gruñen y cuenta los tokens que no pagaste.
Pega 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.
— Sebastian