IA hablar mucho. Tú pagar más.

Hay una cosa bastante tonta que seguimos aceptando en muchas herramientas de IA para programar: pagamos por verbosidad que no necesitamos.

No hablo solo de dinero, aunque también.

Hablo de coste en tres capas a la vez:

• más tokens de salida,
• más latencia,
• y más tiempo humano leyendo prosa que no aporta demasiado.

Si usas asistentes de código todos los días, eso se acumula muy deprisa.

Por eso me parece interesante Caveman.

No por el chiste de hacer que el modelo hable como un cavernícola.

Y tampoco porque me entusiasme convertir cualquier prompt en un meme.

Me parece interesante porque pone el foco en un problema real: muchos modelos y muchos agentes hablan bastante más de la cuenta, y esa costumbre sale cara.

Lo útil de Caveman no es el personaje. Es la compresión

La idea de Caveman es bastante simple.

Le metes al sistema una serie de reglas para recortar cortesías, hedging, conectores vacíos y explicaciones demasiado largas. La respuesta sigue siendo técnica, pero se vuelve más seca:

• menos "claro, te ayudo con eso",
• menos párrafos de calentamiento,
• menos frases dubitativas,
• y más respuesta directa.

Lo interesante es que no toca el código como tal ni los términos técnicos que sí necesitas conservar.

Toca el relleno.

Y eso, en un flujo de trabajo real, importa bastante más de lo que parece.

Porque en muchos contextos no necesitas que tu agente suene amable, pedagógico y perfectamente redactado.

Necesitas que:

• vea el problema,
• te diga la causa,
• proponga el fix,
• y deje de gastar salida en decoración.

La economía de esto es bastante obvia

Una parte del valor de Caveman es casi aburrida de explicar, porque es pura economía básica.

Si una respuesta pasa de 69 tokens a 19, o si una explicación larga de un bug se queda en una fracción del tamaño original, estás pagando menos por exactamente la misma interacción útil.

Eso no solo reduce coste.

También acelera.

Menos salida que generar suele significar menos tiempo esperando y menos texto que inspeccionar. Y en herramientas de programación, donde haces decenas o cientos de interacciones, ese peaje se repite una y otra vez.

Aquí creo que mucha gente se equivoca al mirar el problema como si fuera una manía estética.

No va de que "me gusta que la IA sea seca".

Va de que en un entorno de trabajo la verbosidad tiene coste operativo.

Y si algo tiene coste operativo recurrente, deja de ser una cuestión de estilo y pasa a ser una cuestión de producto.

Lo sorprendente es que a veces hablar menos también mejora la precisión

La parte más llamativa no es el ahorro.

Es que hay señales bastante serias de que la verbosidad no solo cuesta dinero, sino que en algunos casos también mete ruido donde no debería.

Hay un paper de marzo de 2026, Brevity Constraints Reverse Performance Hierarchies in Language Models, que encuentra algo contraintuitivo: en ciertos benchmarks, los modelos grandes empeoran no por falta de capacidad, sino por exceso de elaboración. Al forzar respuestas breves, la precisión mejora de forma notable, hasta 26 puntos en algunos casos, y se reducen bastante las diferencias negativas que parecían "limitaciones del modelo".

Dicho de forma menos académica:

a veces el modelo no falla por saber menos, sino por hablar demasiado.

Esto no significa que "cuanto más corto, siempre mejor".

No significa que cualquier output comprimido sea automáticamente superior.

Pero sí significa que deberíamos dejar de asumir que una respuesta más larga es una respuesta mejor.

Muchas veces es solo una respuesta más cara.

Y a veces, además, una respuesta peor.

Donde sí le veo utilidad real

Yo esto lo veo especialmente útil en cuatro sitios.

1. Debugging iterativo

Cuando estás afinando un bug, no quieres una mini masterclass en cada turno.

Quieres:

• hipótesis,
• evidencia,
• fix probable,
• siguiente paso.

Ahí la brevedad no solo ahorra tokens. También reduce fricción cognitiva.

2. Revisiones de código y comentarios de PR

Gran parte de los comentarios que genera una IA en revisión se podrían decir en una línea.

De hecho, muchas veces deberían decirse en una línea.

Si el problema es claro, prefiero algo tipo:

null possible aquí, añade guard

antes que tres párrafos de explicación institucional sobre por qué convendría considerar una comprobación defensiva.

3. Agentes que operan en bucle

En cuanto metes a un agente en ciclos de observación, diagnóstico, corrección y reintento, la salida innecesaria se convierte en un impuesto continuo.

Y cuanto más largo es el loop, más se nota.

4. Herramientas internas con mucha frecuencia de uso

Si un equipo usa asistentes para soporte técnico, data, ingeniería o producto todos los días, comprimir salida deja de ser una curiosidad.

Se vuelve una optimización acumulativa bastante rentable.

Donde no compraría el argumento completo

Tampoco creo que esto deba convertirse en religión.

Hay momentos donde sí quieres más desarrollo:

• cuando estás explorando una solución desde cero,
• cuando hay varias alternativas con tradeoffs reales,
• cuando alguien junior necesita contexto,
• o cuando el problema es ambiguo y conviene explicitar supuestos.

Ahí poner el modo cavernícola al máximo puede recortar demasiado.

Por eso, más que pensar en Caveman como un dogma, lo leería como una política de compresión configurable.

Ligero cuando quieres limpieza.

Fuerte cuando estás en ejecución.

Y extremo solo cuando el contexto ya está muy claro y el coste marginal de cada palabra empieza a molestar de verdad.

La lectura de producto me interesa más que la broma

Aquí, para mí, está el fondo del asunto.

Lo importante de Caveman no es el branding.

Lo importante es que convierte la brevedad en una decisión explícita del sistema.

Y eso deja bastante en evidencia algo que muchas herramientas todavía resuelven mal: por defecto optimizan la sensación de ayuda, no la eficiencia real del flujo.

Suena bien que un agente te responda con mucha educación, mucho contexto y mucha frase completa.

Pero en cuanto entras en trabajo repetitivo, esa "sensación de ayuda" puede ser solo una forma cara de meter aire en la salida.

Si yo diseñara más herramientas de este tipo, trataría la verbosidad como una palanca de producto de primer nivel:

• modo explicativo,
• modo operativo,
• modo terse,
• y quizá compresión automática según tarea.

Eso me parece bastante más serio que dejar que el tono por defecto del modelo decida cuánto vas a pagar.

Y sí, aquí también hay una crítica al ecosistema de agentes

Hay además una derivada un poco irritante.

Casi cada nuevo agente te pide su propia carpeta de skills, sus propios prompts y su propia forma de configurar exactamente la misma idea.

Al final acabas con redundancia por todas partes para resolver cosas que deberían ser capacidades reutilizables del entorno.

"Habla más corto" no debería sentirse como una mini integración artesanal distinta para cada herramienta.

Debería ser una capacidad transversal.

Esto no invalida Caveman.

De hecho, en parte refuerza su valor: hace visible un problema que estaba ahí y que mucha gente estaba pagando sin pensarlo demasiado.

Mi tesis

No creo que la lección importante aquí sea que ahora tengamos una IA que habla como un cavernícola.

La lección importante es otra:

la verbosidad de un modelo no es inocente; se cobra, ralentiza y a veces estropea la respuesta.

Caveman me interesa porque convierte esa intuición en una práctica concreta.

No es sofisticado.

No es especialmente elegante.

Pero en producto muchas veces las mejoras rentables no llegan por una arquitectura brillante, sino por coger un desperdicio obvio y dejar de tolerarlo.

Y en herramientas de IA, una parte de ese desperdicio sigue siendo esta: demasiadas palabras para demasiado poco valor.