Dentro de una semana habrá 50 artículos sobre Caveman Mode. Este no es otro más.

Si llevas unos días moviéndote por X, LinkedIn o cualquier comunidad de desarrolladores, probablemente ya hayas visto hablar de Caveman Mode. En apenas unas horas pasó de ser un prompt compartido entre unos pocos usuarios a convertirse en una de esas tendencias que todo el mundo quiere probar. Dentro de poco habrá decenas de artículos explicando cómo activarlo, cómo adaptarlo a Claude Code, cómo utilizarlo en Cursor o incluso cómo recrearlo en cualquier otro agente. Este artículo no pretende ser uno más de esa lista.

La idea surgió después de leer el artículo de Dani Primo en Web Reactiva. Me pareció una lectura muy recomendable porque pone el foco en algo que muchos llevamos meses sintiendo mientras trabajamos con agentes de IA. Sin embargo, mientras lo leía, terminé llegando a una conclusión bastante diferente. En mi opinión, Caveman Mode no es realmente la noticia. Lo verdaderamente interesante es el problema que ha conseguido hacer visible. Y ese problema lleva existiendo desde que empezamos a utilizar agentes de programación de forma intensiva.

Los agentes hablan demasiado.

No demasiado porque consuman más tokens. No demasiado porque la factura de la API aumente unos céntimos. Hablan demasiado porque obligan al desarrollador a mantener conversaciones que, en muchas ocasiones, no aportan ningún valor al trabajo que está intentando realizar. Cuando pasas ocho horas al día programando junto a Claude Code, Codex, Cursor, GPT-5 o cualquier otro agente, descubres rápidamente que el recurso más escaso no son los tokens. Es la atención.

Durante mucho tiempo la conversación sobre inteligencia artificial se ha centrado en comparar modelos. Qué benchmark obtiene mejores resultados, cuál tiene una ventana de contexto más grande, cuál programa mejor o cuál cuesta menos por millón de tokens. Son comparaciones útiles, por supuesto, pero tengo la sensación de que estábamos mirando únicamente una parte del problema. Dos personas pueden utilizar exactamente el mismo modelo y vivir experiencias completamente diferentes simplemente porque el agente se comunica de una manera distinta.

Y ahí es donde creo que empieza la conversación realmente interesante.

El síndrome del compañero excesivamente educado#

Imagina que trabajas con un compañero que, cada vez que le pides corregir un bug, empieza diciendo algo parecido a esto:

> "Perfecto. Voy a revisar el código. Primero analizaré todas las posibles causas del problema. Después comprobaré el flujo de ejecución para asegurarme de que entiendo correctamente el contexto. A continuación modificaré el archivo afectado intentando respetar las buenas prácticas existentes. Finalmente te explicaré todos los cambios realizados y propondré algunas mejoras adicionales."

La primera vez probablemente pensarías que es una persona extremadamente profesional.

La décima empezaría a resultar pesado.

La número cien sería desesperante.

Sin embargo, eso es exactamente lo que hacen muchos agentes actuales. No porque sean malos modelos, sino porque han sido entrenados para resultar útiles, educados y transparentes. Desde un punto de vista conversacional tiene sentido. Desde un punto de vista productivo, no siempre.

Cuando estoy desarrollando una API en Symfony y detecto un error en un if, no necesito una explicación de medio minuto antes de modificar tres líneas de código. Ya sé cuál es el problema. Ya conozco el contexto. Lo único que quiero es que el agente haga su trabajo y continúe con la siguiente tarea. Cada frase adicional supone un pequeño cambio de contexto que obliga a mi cerebro a detenerse, leer, interpretar y decidir si esa información merece realmente mi atención.

Individualmente parecen segundos insignificantes.

Acumulados durante una jornada completa se convierten en una fuente constante de ruido mental.

Ese es el verdadero coste que muy pocas veces aparece cuando hablamos de inteligencia artificial.

No confundamos conversación con productividad#

Creo que una parte del problema viene de que seguimos evaluando los agentes como si fueran asistentes conversacionales. Es lógico. ChatGPT popularizó precisamente esa forma de interactuar con la IA. Hacíamos una pregunta, recibíamos una explicación extensa y continuábamos la conversación. Para aprender resulta fantástico. Para trabajar ocho horas seguidas quizá no tanto.

Un desarrollador experimentado no necesita que le expliquen continuamente por qué un foreach funciona de determinada manera, por qué una función devuelve un valor concreto o por qué se ha eliminado una línea duplicada. Necesita mantener el flujo de trabajo. Necesita entrar en ese estado de concentración donde los cambios suceden con rapidez y donde cualquier interrupción cuesta varios minutos recuperar.

Los agentes actuales todavía tienen una tendencia muy marcada a romper ese flujo. Explican demasiado. Piden confirmaciones innecesarias. Justifican decisiones evidentes. Añaden recomendaciones que nadie ha solicitado. En definitiva, se comportan más como un profesor intentando enseñar que como un compañero de equipo intentando terminar una tarea.

Y aquí es donde Caveman Mode me parece brillante.

No porque el prompt sea especialmente complejo.

No porque reduzca mágicamente el número de tokens.

Sino porque obliga al agente a cambiar de personalidad.

De repente deja de comportarse como un profesor y empieza a comportarse como alguien cuyo único objetivo es resolver el problema lo antes posible.

Ese pequeño cambio de enfoque altera completamente la experiencia de uso.

El problema nunca fueron los tokens#

Desde que empezamos a pagar por APIs parece que todo se mide en dinero. Cuántos tokens consume un modelo, cuánto cuesta una llamada o cuánto podemos ahorrar optimizando un prompt. Evidentemente son métricas importantes, especialmente cuando hablamos de aplicaciones que realizan miles de peticiones diarias.

Pero cuando trabajo como desarrollador hay otra métrica que considero mucho más importante.

¿Cuánto tiempo consigue mantenerme concentrado el agente?

Es una pregunta que rara vez aparece en los benchmarks.

Sin embargo, creo que terminará siendo uno de los factores más determinantes para elegir una herramienta u otra.

Un agente que consume un poco más de tokens pero consigue que no salga constantemente del flujo de trabajo probablemente me haga mucho más productivo que otro ligeramente más barato pero incapaz de dejar de hablar.

Y esa diferencia no depende únicamente del modelo.

Depende de cómo ha sido diseñado el agente.

Depende de su personalidad.

Depende de su forma de comunicarse.

Y ahí es donde creo que empieza realmente la siguiente generación de herramientas de desarrollo basadas en inteligencia artificial.

El verdadero descubrimiento no es Caveman Mode#

Si tuviera que resumir toda esta reflexión en una sola frase sería esta:

Caveman Mode no es una solución. Es un síntoma.

Es el síntoma de que muchos desarrolladores hemos llegado, casi al mismo tiempo, a la misma conclusión: necesitamos que los agentes cambien su forma de comunicarse dependiendo del trabajo que están realizando.

Hasta ahora parecía que la única decisión importante era elegir el modelo. GPT-5, Claude, Gemini, DeepSeek... Comparábamos benchmarks, capacidad para programar, velocidad de respuesta o tamaño de la ventana de contexto. Sin embargo, cuanto más utilizo estas herramientas, más convencido estoy de que esa decisión cada vez tendrá menos peso frente a otra mucho más interesante.

¿Qué personalidad tiene tu agente?

Puede parecer una pregunta extraña, pero creo que dentro de muy poco será tan habitual como preguntar qué IDE utilizas.

Porque la realidad es que no todos los trabajos requieren el mismo tipo de conversación.

Cuando estoy corrigiendo un bug quiero respuestas extremadamente cortas. No necesito una explicación sobre por qué un null estaba provocando una excepción. Ya lo he visto. Ya conozco el proyecto. Lo único que necesito es que el agente encuentre el error, lo corrija y continúe con la siguiente tarea.

Sin embargo, cuando estoy diseñando la arquitectura de un SaaS, tomando decisiones sobre licenciamiento o valorando si debo separar un servicio en varios microservicios, ocurre exactamente lo contrario. En ese momento sí quiero que el agente cuestione mis decisiones, compare alternativas, identifique riesgos e incluso me lleve la contraria si considera que existe una opción mejor.

Son dos formas de trabajar completamente distintas.

Y, sin embargo, hoy solemos utilizar exactamente el mismo agente para ambas.

Es como pedirle a una única persona que sea desarrollador, arquitecto, profesor, revisor de código, auditor de seguridad y DevOps al mismo tiempo. Evidentemente puede desempeñar todas esas funciones con mayor o menor acierto, pero nunca tendrá el comportamiento óptimo para todas ellas.

Creo que ahí está el verdadero cambio que vamos a vivir durante los próximos años.

No será una guerra de modelos.

Será una guerra de agentes.

Dejaremos de hablar de modelos para empezar a hablar de perfiles#

Hace apenas dos años la conversación era muy sencilla.

«¿Utilizas GPT-4 o Claude?»

Hoy la conversación empieza a cambiar.

«¿Utilizas Claude Code o Cursor?»

Dentro de unos años creo que la pregunta será completamente diferente.

«¿Qué perfil tienes cargado?»

Porque el modelo empezará a ser casi una commodity. Todos serán extraordinariamente buenos programando. Todos tendrán contextos enormes. Todos serán capaces de generar código de calidad. La diferencia competitiva estará en cómo trabajan contigo.

De hecho, si observamos la evolución de las herramientas actuales, ya podemos ver pequeños indicios de esta tendencia.

Claude Code incorpora archivos como CLAUDE.md para adaptar el comportamiento del agente al proyecto.

Cursor permite definir reglas específicas para cada repositorio.

Codex empieza a orientarse hacia flujos de trabajo más especializados.

OpenCode apuesta por agentes configurables.

Todos están avanzando en la misma dirección.

Todavía hablamos de prompts.

Pero en realidad estamos empezando a construir personalidades.

Y creo que todavía no somos del todo conscientes de ello.

Yo no quiero un único agente#

Desde hace meses tengo una idea que cada vez veo más clara.

Yo no quiero un agente inteligente.

Quiero un equipo.

Igual que en un proyecto real existen perfiles diferentes para resolver problemas distintos, creo que la inteligencia artificial evolucionará hacia exactamente el mismo modelo.

No quiero preguntarle siempre a la misma IA.

Quiero decidir con quién estoy hablando.

Cuando detecto un error quiero activar un Bug Hunter. Alguien obsesionado con reproducir el fallo, localizar la causa y proponer la corrección más sencilla posible. No necesito recomendaciones de arquitectura ni sugerencias sobre cómo reorganizar el proyecto.

Cuando termino una funcionalidad quiero pasarla a un Reviewer. Un perfil cuya única misión sea encontrar problemas de calidad, código duplicado, nombres poco claros, complejidad innecesaria o posibles regresiones.

Antes de desplegar una nueva versión quiero consultar a un Security Reviewer que piense como un atacante. Que revise permisos, validaciones, inyecciones SQL, exposición de datos sensibles o configuraciones inseguras sin distraerse con otros aspectos del proyecto.

Y cuando tengo que decidir cómo estructurar un nuevo módulo quiero sentarme con un Architect. Alguien que no escriba código inmediatamente, sino que dedique tiempo a discutir alternativas, identificar ventajas e inconvenientes y ayudarme a elegir la solución más adecuada.

Fíjate en un detalle importante.

No estoy describiendo modelos diferentes.

Estoy describiendo comportamientos diferentes.

Y creo que esa diferencia es mucho más importante de lo que parece.

Un buen desarrollador cambia de registro constantemente#

Piensa en cómo trabajas tú mismo durante un día normal.

A primera hora puedes estar revisando una Pull Request. Una hora después solucionando un bug crítico. Después participas en una reunión para definir requisitos con negocio. Más tarde preparas una estimación. Finalmente escribes documentación para otro compañero.

¿Has utilizado exactamente la misma forma de pensar durante todo ese día?

Evidentemente no.

Tu cerebro cambia continuamente de contexto.

Cuando revisas código eres extremadamente crítico.

Cuando programas intentas avanzar rápido.

Cuando explicas algo a un compañero simplificas conceptos.

Cuando diseñas arquitectura intentas mirar varios meses hacia delante.

No eres la misma persona durante toda la jornada.

¿Por qué esperamos entonces que un agente sí lo sea?

Creo que aquí está una de las mayores oportunidades de mejora de las herramientas actuales. No necesitamos modelos más inteligentes para muchas tareas. Necesitamos modelos capaces de adoptar el comportamiento adecuado en cada momento.

Y eso no se consigue únicamente afinando un prompt.

Se consigue diseñando perfiles completos con objetivos, prioridades, tono de comunicación, criterios de calidad y forma de razonar diferentes.

Ahí es donde creo que está realmente el futuro.

Mi visión: una biblioteca de agentes, no una colección de prompts#

Si algo me ha enseñado este último año trabajando con inteligencia artificial es que los prompts tienen fecha de caducidad.

Cada pocas semanas aparece uno nuevo. Unos prometen escribir mejor código. Otros generar mejores tests. Otros reducir el consumo de tokens. Durante unos días todo el mundo habla de ellos y, poco después, desaparecen para dejar paso a la siguiente tendencia.

No creo que ese sea el camino.

De la misma forma que nadie guarda cientos de comandos sueltos para Git cuando puede crear alias o scripts reutilizables, tampoco tiene sentido mantener decenas de prompts desperdigados entre notas, conversaciones o repositorios. El problema no es recordar qué prompt utilizabas para una tarea concreta. El problema es que estamos intentando resolver un problema de diseño con una simple cadena de texto.

Yo prefiero pensar en agentes.

No en prompts.

En agentes.

La diferencia parece pequeña, pero cambia completamente el enfoque.

Un prompt únicamente indica qué quieres hacer.

Un agente define quién eres mientras lo haces.

Y eso incluye muchísimas más cosas que unas pocas instrucciones.

Incluye prioridades.

Incluye objetivos.

Incluye el tono de comunicación.

Incluye la profundidad del análisis.

Incluye cuándo debe preguntar y cuándo debe asumir decisiones.

Incluye incluso qué aspectos debe ignorar deliberadamente para no perder tiempo.

Cuando empiezas a verlo de esta forma, dejas de pensar en "el prompt para revisar código" y empiezas a pensar en "mi revisor de código".

La diferencia es enorme.

El agente que corrige bugs no debería parecerse al que diseña arquitectura#

Creo que uno de los errores que estamos cometiendo es intentar construir un único agente capaz de hacerlo absolutamente todo.

Es una consecuencia lógica. Durante años hemos buscado el modelo más inteligente posible. Queríamos que respondiera cualquier pregunta, escribiera cualquier lenguaje de programación y resolviera cualquier problema.

Pero un buen desarrollador tampoco trabaja siempre igual.

Cuando aparece un error crítico en producción no me siento delante del ordenador a debatir durante veinte minutos cuál sería la arquitectura ideal.

Quiero encontrar el fallo.

Reproducirlo.

Entender por qué ocurre.

Corregirlo.

Crear un test.

Desplegar.

Fin.

Ese agente debería ser casi obsesivo.

No debería sugerirme refactorizaciones.

No debería hablarme de SOLID.

No debería recomendarme dividir el proyecto en microservicios.

Ni siquiera debería preocuparse por optimizar nombres de variables.

Tiene una misión.

Y únicamente una misión.

Resolver el problema.

Sin embargo, si estoy empezando un SaaS nuevo, el comportamiento debería ser completamente distinto.

En ese momento quiero exactamente lo contrario.

Quiero un agente lento.

Quiero que piense.

Quiero que dude.

Quiero que me diga que una decisión puede generar problemas dentro de seis meses.

Quiero que compare tres alternativas.

Quiero que cuestione mis ideas.

Quiero que me haga perder media hora si con ello me evita tres semanas de trabajo más adelante.

Ese agente no está optimizando velocidad.

Está optimizando decisiones.

Y ambos son igual de valiosos.

Así imagino mi equipo de agentes#

Con el tiempo he ido apuntando qué perfiles utilizo más a menudo. Curiosamente, coinciden bastante con los roles que existen en un equipo de desarrollo real.

Architect#

No escribe código hasta que entiende el problema.

Analiza requisitos.

Busca dependencias.

Pregunta.

Propone alternativas.

Habla mucho.

Y está bien que lo haga.

Su trabajo consiste precisamente en pensar antes de construir.

Builder#

Una vez la arquitectura está clara quiero exactamente lo contrario.

Código.

Mucho código.

Pocas explicaciones.

Si encuentra un problema importante que me lo diga.

Si no, que siga trabajando.

Quiero que mantenga el ritmo.

Bug Hunter#

Posiblemente el perfil que más utilizaría.

Su única misión consiste en localizar errores.

No le importa la elegancia.

No le importa la arquitectura.

No le importa si el código es bonito.

Quiere reproducir el fallo.

Encontrar la línea exacta.

Corregirla.

Añadir un test.

Continuar.

Reviewer#

Cuando el desarrollo termina empieza otro trabajo completamente diferente.

Aquí ya no quiero rapidez.

Quiero desconfianza.

Quiero un agente que piense que todo está mal hasta que demuestre lo contrario.

Que detecte nombres poco claros.

Código duplicado.

Métodos demasiado largos.

Dependencias innecesarias.

Complejidad accidental.

Riesgos de mantenimiento.

En otras palabras.

Quiero un compañero senior revisando mi Pull Request.

Security#

Este perfil ni siquiera debería fijarse en la funcionalidad.

Quiero que piense como un atacante.

¿Hay una validación que falta?

¿Se puede acceder a datos de otro usuario?

¿Existe riesgo de SQL Injection?

¿Estoy exponiendo información sensible?

¿Hay secretos dentro del repositorio?

Todo lo demás es secundario.

Performance#

Su trabajo tampoco consiste en escribir nuevas funcionalidades.

Quiere eliminar consultas innecesarias.

Reducir consumo de memoria.

Evitar renderizados.

Optimizar índices.

Encontrar cuellos de botella.

Es otro tipo de conversación completamente distinta.

Todos utilizarán el mismo modelo#

Y aquí aparece la parte que más interesante me parece.

No creo que dentro de unos años necesitemos veinte modelos distintos.

Creo que seguiremos utilizando dos o tres modelos excelentes.

La diferencia estará en la personalidad que carguemos antes de empezar a trabajar.

Igual que hoy cambiamos de rama en Git o abrimos un workspace diferente en nuestro IDE, mañana seleccionaremos el perfil con el que queremos colaborar durante las siguientes horas.

No elegiremos únicamente GPT-5 o Claude.

Elegiremos GPT-5 + Architect.

O Claude + Reviewer.

O Codex + Bug Hunter.

El modelo será el motor.

El agente será el compañero.

Y esa separación me parece muchísimo más interesante que la carrera actual por conseguir uno o dos puntos más en un benchmark.

¿Cómo lo estoy empezando a organizar?#

En mis proyectos llevo tiempo pensando en abandonar la idea de tener un único archivo enorme con instrucciones para el agente.

Prefiero algo mucho más modular.

Algo parecido a esto.

.ai
│
├── architect.md
├── bug-hunter.md
├── reviewer.md
├── security.md
├── performance.md
├── teacher.md
├── documentation.md
└── deploy.md

Cada archivo representa una personalidad.

No un prompt.

Una personalidad completa.

Con sus objetivos.

Su tono.

Sus prioridades.

Su forma de responder.

Las decisiones que puede tomar por sí mismo.

Y aquellas para las que debe pedirme confirmación.

Lo interesante es que esa biblioteca podría reutilizarse independientemente de si mañana utilizo Claude Code, Cursor, Codex o cualquier otra herramienta.

Porque el verdadero activo dejaría de ser el modelo.

El verdadero activo sería haber construido un equipo de agentes que ya conocen mi forma de trabajar.