Claude Code sin configurar vs configurado: lo que de verdad mide un experimento

Sesgo declarado: enseño Claude Code a equipos, así que me convenía que este experimento gritara "configúralo y ahorrarás un montón de tokens". Lo ejecuté de verdad —dos sesiones reales, midiendo coste y tiempo con los datos que devuelve la propia herramienta— y el resultado me corrigió en parte. Lo cuento tal cual salió, porque una guía que solo confirma lo que su autor vende no vale nada.

La pregunta no era "¿configurar sí o no?", sino qué compra exactamente la configuración — y la respuesta resultó ser distinta de la que yo habría escrito de memoria.

El montaje

El método es deliberadamente simple de reproducir en cualquier repo: dos copias del proyecto en worktrees de git, la misma feature, el mismo prompt, y medir con lo que la propia herramienta ya te da.

• El repo: esta misma web (Next.js 16, TypeScript, Tailwind, Playwright para los e2e). Dos copias limpias en worktrees de git desde la rama principal.
• La feature: añadir un filtro por tipo al catálogo de /guias — chips por categoría, estado en la URL (/guias?tipo=...), accesible, con su test e2e. Una tarea de tarde, real, del backlog.
• Las dos sesiones, mismo modelo (sonnet-4-6) y mismo prompt inicial:
  • Vanilla de verdad: el repo con todo el contexto eliminado — sin CLAUDE.md, sin AGENTS.md, sin nada que el agente pueda leer como instrucciones. Claude recién instalado y a ciegas sobre el código.
  • Configurada: el mismo repo más una configuración de nivel medio — un CLAUDE.md con las convenciones, dos skills (procedimiento de feature y patrón de tests) y un hook que pasa ESLint tras cada edición.

Medí lo que devuelve la herramienta sin maquillarlo: tokens, coste en dólares, duración y número de rondas. Yo solo hice de revisor, corrigiendo el vanilla con un guion fijo para no improvisar pedagogía a mi favor.

Qué pasó en cada sesión

Vanilla, primera entrega: mejor de lo que el cuento de "vanilla es un desastre" predice — pero con grietas en lo que no podía adivinar. Sin ningún contexto, a la primera ya venía como Server Component, con searchParams tratado como Promise (lo correcto en Next 16: eso lo sabe de su propio entrenamiento, no hace falta documentárselo), los tipos derivados de las guías, los colores con los tokens de diseño del repo —que copió leyendo el fichero que estaba extendiendo—, aria-current en el chip activo, el mensaje amable y el copy en español.

Donde se rompió fue exactamente en lo que el código no le podía enseñar: escribió el test e2e con selectores CSS (page.locator("ul li")) cuando la convención del repo es seleccionar por rol, y no pasó el formateador antes de cantar victoria. Dos correcciones, en una sola ronda de revisión. Las arregló y quedó terminado. Total: 2 rondas mías.

Configurada, primera entrega: cero correcciones, y además mejor estructurada. Hizo lo mismo, pero extrajo la lógica de tipos a la capa de datos (lib/guias/load.ts) en vez de dejarla en la página, usó selectores por rol sin que nadie se lo dijera, y se autoverificó — typecheck, lint y formato en verde— porque el CLAUDE.md lo exige y el hook de ESLint corre solo tras cada edición. No tuve nada que corregir. Total: 1 ronda mía.

Los números reales

Capturados de la propia herramienta, no estimados.

Lee bien la tabla, porque va al revés de lo que yo esperaba: la sesión configurada usó más cómputo, no menos — unas 2,4× los tokens y un tercio más de tiempo. En dólares la diferencia es pequeña (~18%) porque casi todo son lecturas de caché, baratas; en tokens, enorme.

Por qué la configuración costó más, no menos

No es un error de medición; es cómo funciona. El CLAUDE.md y las dos skills son contexto que el agente relee en cada turno interno mientras trabaja, y el hook de ESLint añade pasos: edita, lint, corrige, vuelve a lint. Esa disciplina —que es justo lo que hace que el resultado sea bueno a la primera— se paga en tokens y en segundos, en cada sesión.

Por eso conviene desactivar de entrada el mito más extendido: la configuración no es una técnica de ahorro de cómputo. En una tarea pequeña que se parece a algo que el repo ya tiene, configurar no te ahorra tokens — te cuesta más.

El error de bulto del discurso habitual es vender la configuración como ahorro de tokens. No lo es. Es una compra de calidad de primera pasada y de trabajo humano: menos rondas, cero correcciones de estilo, mejor estructura y verificación automática. Eso es lo que pagas cuando pagas esos tokens de más.

Entonces, ¿para qué configurar?

Por lo que sí cambió, que no es poco:

• La mitad de rondas humanas (1 vs 2) y cero correcciones de convención. El tiempo que ahorras es el tuyo, el del revisor — y ese es el caro. Aquí mi "revisor" fue un guion automático; una persona real tardaría minutos por ronda, y ahí la diferencia de 2 a 1 ronda pesa mucho más que quince céntimos de tokens.
• Mejor código sin pedirlo: la versión configurada salió con la lógica en su sitio. Eso no lo arregla una ronda de revisión; o sale bien de fábrica o se queda regular.
• Autoverificación: el hook cazó y corrigió cosas que en la sesión vanilla tuve que señalar yo. El agente se revisa a sí mismo.

Y un matiz importante: el vanilla acertó en todo lo que su propio entrenamiento o el código vecino ya le decían (Next 16, tokens de diseño), y falló justo en lo que solo vive en la cabeza del equipo (el patrón de tests, la disciplina de verificar). Esa es exactamente la frontera que cubre la configuración: no hace al modelo más listo, le da el conocimiento del repo que no puede deducir leyendo. Cuanto más tenga tu proyecto de ese conocimiento tácito —y cuanto menos fichero-espejo haya que copiar—, más se paga sola.

Qué llevarte

• Configurar no es ahorrar tokens. Medido de verdad, en una tarea pequeña costó ~18% más en dólares y bastante más en tokens y tiempo. Quien te venda la configuración como ahorro de cómputo no la ha medido.
• Lo que compra es calidad de primera pasada y trabajo humano: menos rondas, cero correcciones de estilo, mejor estructura, autoverificación. En tiempo de una persona real, eso vale mucho más que la diferencia de coste.
• El vanilla falla donde el código no le puede enseñar. Acierta lo que sabe de fábrica o copia del vecino; se rompe en las convenciones que solo conoce tu equipo. La configuración existe para cubrir ese hueco, y su ventaja crece con el conocimiento tácito del repo y el tamaño del equipo, no con el recuento de tokens de una feature suelta.

Preguntas rápidas

¿No me estás diciendo entonces que no merece la pena? Al contrario: mereció la pena en lo que importa (menos rondas, mejor código). Lo que digo es que merece la pena por las razones correctas. Si justificas la configuración prometiendo facturas de API más bajas, el primer experimento serio te va a desmentir.

¿Y si la tarea fuera más grande o desde cero? Es la hipótesis natural y este experimento no la cubre: aquí la tarea extendía un fichero existente, lo más favorable al vanilla. Cuanto menos "espejo" haya en el repo, más trabajo de explicación te ahorras escribiéndolo una vez. Pero eso hay que medirlo, no afirmarlo — repite el experimento con tu propio caso.

¿Por qué la sesión configurada gasta tantos más tokens? Porque el CLAUDE.md y las skills se releen en cada turno interno del agente y el hook añade ciclos de lint-y-corrige. Es el precio de la disciplina que produce el buen resultado. Cache barata, así que en dólares casi no se nota; en tokens, mucho.

¿Esto es n=1? Sí: una tarea, un repo, un modelo, con un revisor automatizado y bastante varianza de tokens entre tiradas. No es un benchmark; es una medición honesta y reproducible. Las señales robustas son las rondas (2 vs 1) y las correcciones (2 vs 0), no la cifra exacta de tokens. Reprodúcelo con tus propias tareas y tu equipo, que es donde los números empiezan a significar algo.

¿Y si esto hay que decidirlo para un equipo entero? Ahí la pregunta deja de ser "tokens sí o tokens no" y pasa a ser cómo logras que ocho personas obtengan ese código-bien-a-la-primera de forma consistente. Eso es lo que monto con los equipos en la formación en directo para empresas — midiendo sobre vuestro repo, no sobre el mío.