Checklist para verificar el trabajo de Claude Code con pruebas reales

Un viernes por la noche le pedí a Claude Code: «escribe un artículo y déjalo publicado», y me fui a dormir. A la mañana siguiente leí el registro y, con total seguridad, decía: «Completado. Artículo publicado». Tranquilo, abrí la URL pública y lo que aparecía en pantalla era el título del artículo anterior.

El build había pasado. La URL devolvía 200. Pero la etiqueta h1 seguía siendo la de otra página. Había delegado por completo la revisión del diff a la IA y yo solo me fié de la palabra «funcionó».

En ese momento entendí algo: el problema no era la inteligencia de Claude Code, sino mi forma de «cerrar el trabajo». Cuanto más amplías lo que delegas a la IA, más necesitas dejar a mano una prueba de qué se verificó de verdad. Si no, vas a caer una y otra vez en informes de finalización que son mentira.

En este artículo te muestro ese «patrón para dejar pruebas», junto con código que puedes copiar y pegar.

Puntos clave

• No te creas el «listo» de la IA. Usa como base de la finalización solo pruebas verificadas por máquina: build, URL pública, h1 y CTA.
• Antes de empezar a editar, decide en una frase qué vas a verificar en este trabajo, y deja elegido también el comando de verificación.
• Tras publicar, revisa siempre en el mismo orden (h1 → canonical → inicio del cuerpo → CTA). Fijar el orden reduce los descuidos.
• Si dejas la prueba (captura, URL, próximo número a vigilar) en una nota de una línea, tu yo de mañana o la automatización no repetirán la misma decisión.
• Publicar un artículo verificable mañana es más sólido, en términos de operación, que sacar un artículo perfecto a la primera.

Por qué el «listo» a secas provoca accidentes

Claude Code resume con texto el avance del trabajo. Y ahí está la trampa: el resumen vuelve con casi la misma cara cuando todo salió bien y cuando salió mal.

Que el build haya pasado solo prueba que «la sintaxis no está rota». Que la URL pública devuelva 200 solo prueba que «el servidor devolvió algo». Si ese algo es el artículo que se suponía que ibas a crear, eso es otra historia.

Mi accidente del viernes superó tanto el build como el 200. Lo único roto era un punto: si la URL y el contenido de la página coincidían. Y eso no lo estaba mirando nadie.

Por eso la decisión de finalización no se apoya en las palabras de la IA, sino en el resultado de ir tachando uno a uno los puntos de comprobación que tú decidiste. Si todavía no tienes firme la base del flujo de revisión, conviene dejar primero ordenado lo básico con la guía de primeros pasos de Claude Code, y así estos pasos te entrarán mejor.

Un bucle de verificación de 15 minutos

Si revisas cada vez con pasos distintos, en un día con prisas seguro que te saltas algo. Fija el orden y déjalo en una forma que puedas recorrer sin pensar.

1. Escribe en una frase qué hay que comprobar para dar el trabajo por terminado. Ejemplo: «que el artículo de este slug aparezca en la URL pública con el h1 correcto».
2. Antes de empezar a editar, decide los comandos que usarás para comprobar (build, mostrar el diff). No los busques al terminar.
3. Cuando cambies algo, mira en este orden: diff → build → URL pública. Aunque cambies de idea a mitad, no rompas el orden.
4. En la URL pública, comprueba con la vista que h1, canonical, el inicio del cuerpo y el CTA estén como esperabas.
5. Deja en una sola línea el riesgo que queda y «el próximo paso mínimo a hacer».

Lo importante aquí es separar desde el principio lo que delegas a la IA y lo que decides tú.

Etapa	Puedes delegar a la IA	Decide la persona
Elegir tema	Leer títulos existentes y proponer candidatos	Cuál escribir al final
Redacción	Borrador de cuerpo, código y titulares	Si hay datos falsos o desactualizados
Verificación	Ejecutar el build, resumir el diff	Confirmación final del contenido de la URL
Publicación	Ejecutar el comando de publicación	Aprobar operaciones irreversibles (borrar, desplegar a producción)

Las operaciones irreversibles déjalas todas, al principio, en «preguntar a la persona». Solo cuando una operación demuestre ser segura la asciendes a automática más tarde. Esta forma de trazar la línea la detallo en la guía de gestión de permisos.

Plantilla de petición lista para copiar y pegar

Si cada vez expresas la verificación con palabras desde cero, según el ánimo del día se te escaparán cosas. Si dejas la petición a Claude Code como una plantilla, los puntos de comprobación se estabilizan.

He publicado este artículo. Antes de informar de que está completado, comprueba lo siguiente y devuelve el resultado en una tabla.
- Si el build tuvo éxito (escribe también el comando y el código de salida).
- Si el h1 de la URL pública coincide con el título del artículo de este slug.
- Si el canonical apunta al mismo slug.
- Si el inicio del cuerpo no es un reciclado del artículo anterior o de la portada.
- Si los CTA (PDF gratis, material de formación, consultoría) están en un orden acorde a la situación del lector.
Los puntos que no hayas podido verificar, escríbelos con honestidad como «sin verificar». No escribas «OK» por suposición.

La última frase es la que funciona. Si no dejas explícito «no escribas OK por suposición», la IA te devuelve un «sin problemas» con buena cara incluso en puntos que no comprobó. Si quieres mejorar la propia forma de construir tus peticiones, échale un vistazo también a la ingeniería de prompts avanzada.

Script de verificación que funciona copiando y pegando

Esto es el núcleo de hoy. Va a buscar la URL pública y juzga de forma automática si el h1 es el título esperado. Funciona solo con Node.js (18 o superior). La base de la finalización no es el «listo» de la IA, sino el veredicto de este script.

// verify-publish.mjs
// Uso: node verify-publish.mjs <URL pública> "<título h1 esperado>"
// Ej: node verify-publish.mjs https://claudecode-lab.com/es/blog/foo/ "Título del artículo"

const [url, expectedH1] = process.argv.slice(2);

if (!url || !expectedH1) {
  console.error("Pasa los dos valores: la URL y el título h1 esperado.");
  process.exit(2);
}

// Descarga la página pública
const res = await fetch(url, { redirect: "follow" });
const html = await res.text();

// Extrae h1 y canonical de forma aproximada (no hace falta un parser estricto)
const h1 = (html.match(/<h1[^>]*>(.*?)<\/h1>/is)?.[1] ?? "")
  .replace(/<[^>]+>/g, "")
  .trim();
const canonical = html.match(/<link[^>]+rel=["']canonical["'][^>]+href=["']([^"']+)["']/i)?.[1] ?? "";

// Tacha los puntos de comprobación uno a uno
const checks = {
  http200: res.status === 200,
  h1Coincide: h1 === expectedH1,
  canonicalCoincide: canonical.includes(new URL(url).pathname),
};

console.table(checks);

const allOk = Object.values(checks).every(Boolean);
if (!allOk) {
  console.error("Hay puntos sin verificar o que no coinciden. No des la publicación por terminada todavía.");
  console.error(`h1 obtenido: ${h1 || "(vacío)"}`);
  process.exit(1);
}

console.log("Pruebas reunidas. Puedes darlo por terminado.");

Ejecutarlo es solo esto.

node verify-publish.mjs https://claudecode-lab.com/es/blog/foo/ "Título del artículo"

Si h1Coincide es false, estás justo en el mismo estado que mi accidente del viernes: la URL está viva pero el contenido es otro. Mientras el código de salida no sea 0, no llames «terminado» a la publicación. Solo con convertir esto en regla, el informe de finalización falso se detiene antes de tiempo.

Dónde resulta útil esto

1. Trabajo de publicación de artículos Es la escena donde confundes fácilmente «HTTP 200» con éxito. Si con el script de arriba compruebas que h1 y canonical apuntan al mismo slug, descartas antes de publicar el reciclado del artículo anterior o el fallback a la portada.

2. Cambiar un CTA Cuando muevas un botón hacia el PDF gratis o el material de formación, deja en la misma línea de nota la captura y «el próximo número a vigilar». Después podrás seguir «¿ese cambio aumentó los registros?» con el registro y no con la memoria.

3. Cambios de configuración o permisos Es justo al cambiar CLAUDE.md o la configuración de permisos cuando hay que pasar el mismo comando de verificación antes y después. Si te queda inseguridad sobre cómo escribir la configuración, ten primero ordenadas las buenas prácticas de CLAUDE.md para que la premisa de la verificación cuadre.

Trampas y cómo corregirlas

Te lo digo con honestidad: caí muchas veces en los mismos hoyos antes de asentar este patrón.

La primera es intentar arreglarlo todo en un solo trabajo y crear un diff tan grande que no se puede revisar. Un diff de 40 archivos no lo lee entero ni una persona ni una IA. La corrección es sencilla: limita a una frase lo que vas a comprobar en cada trabajo. Si crece hasta un tamaño que no puedes verificar, divide el trabajo.

La segunda es dar por terminado en el momento en que el build local pasa. Que funcione en local y que aparezca correctamente en la URL pública son cosas distintas. La corrección es pasar siempre una vez el script de arriba después de publicar. Hasta que lo incorporé al procedimiento, yo también publiqué varias veces contenido equivocado.

La tercera es solo añadir CTA sin explicar adónde debe avanzar el lector. Aunque pongas tres botones en fila, si no se puede elegir no sirve de nada. La corrección es añadir en el cuerpo una frase sobre qué CTA conviene según la situación del lector (todavía inseguro con los comandos / cansado del trabajo repetitivo / pensando en una adopción de equipo).

Preguntas frecuentes

P. Si el build pasa, ¿ya está terminado? El build solo es prueba de que la sintaxis no está rota. Si el contenido de la URL pública es el de este artículo es otro problema. Solo está terminado cuando miras hasta el h1 y el canonical.

P. ¿El script de verificación hay que ejecutarlo a mano cada vez? Al principio, a mano basta. Cuando el procedimiento se estabilice, lo haces crecer hasta que se ejecute automáticamente justo después del comando de publicación. Si el código de salida no es 0, detén la publicación: con esa operación se reducen los accidentes.

P. ¿No puedo delegar también toda la verificación a la IA? Leer y resumir sí puedes delegarlo. Pero el juicio final sobre «si el contenido de la URL pública es correcto» y la aprobación de operaciones irreversibles las mantiene la persona. Si entregas esto, ya no queda nadie que detenga el informe de finalización falso.

P. ¿Puede alguien sin perfil técnico recorrer esta comprobación? Sí. El script funciona copiando y pegando, y el procedimiento visual es solo memorizar un orden. Si los comandos en sí te dan inseguridad, empieza por la explicación para perfiles no técnicos y no se hará cuesta arriba.

P. ¿Qué basta con dejar en la nota? Con tres cosas llega: «lo que verifiqué esta vez», «el riesgo que queda» y «el próximo paso mínimo». No hace falta un acta larga. El único objetivo es que tu yo de mañana no rehaga la misma decisión.

Lo que comprobé al probarlo de verdad

Después de aquella publicación con contenido equivocado del viernes, cambié el criterio de finalización de «qué dijo la IA» a «si el código de salida del script es 0».

Al pasar de verdad verify-publish.mjs por unas diez publicaciones, en dos de ellas h1Coincide devolvió false. Ambas devolvían 200 y a simple vista no se notaba. Sin el script, habría vuelto a publicar una página reciclada.

Fijar el orden de la revisión visual también funcionó. Al mirar siempre en el mismo orden, h1 → canonical → inicio del cuerpo → CTA, casi desaparecieron los descuidos del tipo «anda, esto también me lo salté antes». La sensación es que la comprobación nocturna se volvió más ligera en la medida en que saqué el juicio fuera de mi cabeza y lo dejé en el procedimiento.

Antes que buscar una IA más lista, coloca primero un mecanismo que te avise aunque tropieces. Parece un rodeo, pero mi conclusión hoy es que ese es el camino más rápido.

Si estás en la fase de querer convertir este patrón de verificación en el estándar de tu equipo, o de integrarlo en el flujo de publicación de tu empresa, lo diseñamos juntos en formación y consultoría. La documentación oficial de Claude Code puedes consultarla en la documentación de Anthropic.