No estás usando Claude Code bien si no haces esto

Si estás leyendo esto es porque usas o te estás planteando usar Claude Code para programar. Y si es así, entonces amigo quédate porque vamos a revisar un flujo completo y te voy a demostrar que quizá no le estás sacando el máximo rendimiento que podrías.

Programar con IA ya es una realidad. Cada vez hay herramientas mucho mejores y más rápidas para ayudarnos a lanzar productos de una forma más sencilla y a una velocidad vertiginosa.

Pero toda esa velocidad te sirve de bien poco si no compruebas lo que estás haciendo, si no demuestras que realmente funciona.

La locura organizada de Boris Cherny

Recientemente vi un hilo en Twitter de nada más y nada menos que Boris Cherny, el creador de Claude Code. Y el tío está loco, pero de la mejor manera posible.

Boris tiene 5 instancias de Claude Code corriendo a la vez en su PC, pero además tiene de 5 a 10 más en la nube. Usa Opus 4.5 como no podía ser de otra forma, y tiene un fichero claude.md para escribir las reglas del proyecto.

Pero lo que más me llamó la atención es que muchas de sus sesiones empiezan siempre en modo plan.

El poder de planificar antes de codear

Antes de escribir una sola línea de código, se pone a discutir con Claude el plan: qué se va a tocar, por qué, qué opciones hay y cuál es la mejor. Y hasta que ese plan no le convence, no pasa a ejecutar nada.

Cuando el plan está claro, cambia al modo de aceptar cambios automáticamente y, según él, muchas veces Claude lo saca a la primera. Literalmente dice que un buen plan lo es casi todo.

Luego habla de que usa slash commands para cualquier flujo repetitivo que hace muchas veces al día. Todo eso lo mete en comandos versionados dentro del proyecto, para no tener que repetir prompts ni explicaciones una y otra vez.

Es decir, no está “hablando” con Claude constantemente, está reutilizando comportamientos.

Lo que nadie está hablando: validación

Y aquí viene lo interesante. En todo este hilo, Boris habla de planificación, de reglas, de agentes, de workflows… pero en ningún momento entra en detalle sobre testing como tal.

No habla de tests unitarios, no habla de pipelines, no habla de coverage. Habla de verificar, de comprobar que todo funciona, pero siempre desde un punto de vista más global.

Por eso quiero enseñarte lo que uso yo para validar todo lo que Claude Code me genera.

TestSprite: testing real para código generado por IA

Uso nada más y nada menos que un MCP (Model Context Protocol). Si todavía no sabes lo que es un MCP, en pocas palabras es básicamente el conector para que tu asistente hable con herramientas externas.

Y la herramienta a la que vamos a conectar es TestSprite, un MCP que nos va a ayudar a hacer nuestros tests, probarlos y darnos resultados tangibles.

Instalación en Claude Code

Primero necesitas una API key de TestSprite. Te creas una cuenta, vas al apartado de API keys y la copias.

Ahora, te vas al directorio de tu proyecto:

cd /path/to/your/project

Y ejecutas el comando para añadir el MCP server a Claude Code:

# En PowerShell (Windows)
$env:API_KEY = "tu-api-key-aqui"

# Añadir el MCP
claude mcp add-json testsprite-mcp '{
  "type": "stdio",
  "command": "npx",
  "args": ["@testsprite/testsprite-mcp@latest"],
  "env": {
    "API_KEY": "${API_KEY}"
  }
}'

Para verificar que todo está bien:

claude mcp list

Y listo, ya tienes la instalación completa.

El flujo completo: de código a evidencia

Para la demo voy a usar un frontend con un par de flows típicos: login, navegación y un mini checkout. Lo importante es que lo voy a levantar en local:

npm run dev

El comando mágico

Y ahora viene la parte que a mí me gusta, porque es muy de “vale, hazlo”. Me voy al chat de Claude Code y le digo:

“Can you test this project with TestSprite?”

Y aquí pasa algo clave: Claude ya no está opinando. Está llamando herramientas.

Te abre una configuración en navegador donde tú defines:

Type: frontend
URL: tu localhost
Scope: puedes elegir codebase para que haga una pasada completa
Y si hay login, le das credenciales de test (nunca uses tu cuenta real)

Y a partir de aquí… yo literalmente no hago nada. El agente analiza el proyecto, genera un PRD normalizado si le das uno, y empieza a preparar los tests.

Resultados tangibles, no opiniones

Cuando termina, te deja una carpeta en el proyecto con resultados y reportes. Y esto a mí me gusta porque es tangible: no es “me lo ha dicho la IA”, es que hay artefactos.

Te genera reportes en Markdown y en HTML. Y en el report tienes lo que todo el mundo quiere ver:

Cobertura de tests
Qué ha fallado
Por qué ha fallado
Y el dato estrella: pass rate

Y aquí es donde te das cuenta de algo: lo que tú creías que estaba “bien”… a veces está medio bien.

El poder de los bugs visuales

Pero lo más bestia es cuando hay un bug visual. Porque aquí la mayoría de herramientas te dicen: “element not found”, “timeout” y ya.

Aquí tienes preview/reproducción de cómo se ejecutó el test. O sea, tú lo ves.

Y esto es importantísimo para UI, porque hay bugs que son literalmente:

“El botón existe, pero está tapado”
“En móvil se descoloca”
“El modal bloquea el click”

Puedes ver el test intentando hacer click y fallando. Y en el vídeo de reproducción entiendes en dos segundos qué pasó. Esto es lo que yo llamo: “no opinión, evidencia visual”.

Cerrando el loop: test → fix → retest

Ver el bug está bien, pero lo que queremos es cerrar el loop completo:

test → fallo → fix → retest

Así que vuelvo a Claude Code y le digo:

“Please fix the codebase based on TestSprite testing results.”

Y ahora Claude hace lo que mejor se le da: tocar el código. Pero ya no a ciegas. Lo toca con un objetivo: arreglar el fallo que el test ha demostrado.

El momento de la verdad

Re-ejecutas el flujo y vuelves a mirar el reporte. Y el momento satisfactorio es cuando ves:

Menos fallos
Mejor pass rate
Y el bug visual ya no aparece

Y esto, para mí, es la diferencia entre “hice vibe coding” y “shippeé con confianza”.

La reflexión final

Te dejo una idea para que te la quedes.

Boris optimiza el loop de construir: plan mode, múltiples agentes, guidelines… Pero si no optimizas el loop de validar, tu velocidad es peligrosa.

Porque la calidad no se negocia. Lo que pasa es que antes la calidad te la daba el tiempo. Y ahora, como vas rápido… necesitas un sistema.

Y para mí, estas integraciones de testing con MCP son exactamente eso: un sistema de verdad.

¿Quién es responsable?

Y ahora te pregunto yo a ti: Si hoy tu código lo escribe un agente… ¿quién es responsable de que funcione?

Porque “yo creía que iba” no vale en producción.

Prueba TestSprite

Si quieres probarlo, TestSprite tiene plan Free y el Starter que para empezar está genial porque el primer mes te sale gratis. Te dejo el link en la descripción del video.

Y si lo pruebas, cuéntame en los comentarios: ¿qué bugs te ha encontrado? Porque te juro que a veces saca cosas que ni habías considerado.

Nos vemos en el próximo post.

¿Qué te ha parecido?

Déjame tu opinión, pregunta o sugerencia. Los comentarios se sincronizan con GitHub Discussions .