Construir con Claude
03Capítulo · Construir con ClaudeNuevo
3 min de lectura

Leer la salida: confía, pero verifica

La habilidad que separa a quienes se queman de quienes publican no es escribir prompts. Es saber leer lo que vuelve — y cómo hacer que Claude verifique su propio trabajo.

Última actualización ·
Qué cambió
  • Capítulo nuevo — añadido en la reestructuración de junio de 2026.

El bucle tiene un paso que todos apresuran: leer. Claude se detiene cuando el trabajo parece terminado — no cuando lo está. Sin una verificación, tú eres el bucle de verificación.

Aquí está la verdad incómoda debajo de cada demo impresionante. Un modelo produce texto que parece terminado, seguro y correcto — y parecer correcto no es lo mismo que ser correcto. Cuando escribe “Listo, todo funciona”, no está mintiendo; de verdad no puede distinguir entre un resultado que verificó y uno que solo produjo. Así que o verificas cada respuesta a mano, para siempre, o le das al bucle algo contra lo que pueda verificarse a sí mismo. Ese segundo movimiento es toda la habilidad de esta lección.

actúa produce ¿verifica? publícalo pasa falla — de vuelta a actúa, automáticamente
Dale al bucle una verificación que devuelva pasa o falla — una prueba, una compilación, una comparación de capturas — y se cierra solo: ve rojo, arregla, ve verde, sin ti en el medio.

Exige evidencia, no afirmaciones

El hábito más barato que cambió mis resultados: cuando Claude afirma el éxito, pide ver la prueba, no la afirmación. Mira cómo se desarrolla la diferencia:

Listo — arreglé el error y ahora todo funciona.
Muéstrame la salida de las pruebas.
Ejecuté npm test — 1 fallando: total del checkout. Déjame mirar otra vez…

↳ la brecha era real y una sola pregunta la sacó a la luz. “Funciona” es una opinión; la salida de las pruebas es un hecho.

Así que haz que la evidencia sea parte de la petición: “cambia esto, luego ejecuta las pruebas y muéstrame el resultado”, no solo “cambia esto”. Si no puedes verificarlo, no lo publiques — y ajusta tu escrutinio a lo que está en juego. Un borrador desechable que vas a leer de todos modos solo necesita un vistazo; una migración de base de datos o cualquier cosa compartida se gana la prueba completa antes de que confíes en ella.

Dónde se rompe

Salida plausible-pero-equivocada que pasa un vistazo — código de aspecto limpio con un sutil error de uno en uno, un resumen que se lee a la perfección y dejó caer en silencio el único hecho que importaba. Es el fallo más peligroso porque nada parece estar mal. Y cuando un hilo se queda atascado fallando una y otra vez, no discutas con él — después de un par de correcciones malas, limpia y vuelve a empezar con un escritorio limpio.

Ponlo en práctica

En tu próxima tarea real, antes de aceptar la respuesta, hazte una pregunta: ¿qué evidencia probaría que esto está bien? Una prueba que pasa, una captura que coincide, el comando y su salida real. Luego haz que Claude produzca esa evidencia en lugar de solo afirmar el éxito. El hábito es pequeño; el número de cosas rotas en silencio que atrapa no lo es.

Basado en las mejores prácticas de Claude Code de Anthropic — “dale a Claude una forma de verificar su trabajo”, y la brecha de confiar-y-luego-verificar.

Los nuevos capítulos llegan aquí a medida que los aprendo. ¿Quieres el próximo?