Checklist de simulación antes de dejar que Claude Code despliegue a producción

Un viernes por la tarde le dije a Claude Code: “publica esta corrección en producción”. La respuesta fue una sola línea, “Publicado”, con una marca de verificación verde. Me fui tranquilo a casa. A la mañana siguiente, la portada del sitio estaba en blanco.

La causa era ridícula: nadie había abierto la vista previa. Claude Code solo miró el log de que el build había pasado y decidió que era un “éxito”. Pero la página real cargaba la plantilla de otro artículo y salía vacía. Como el servidor devuelve un HTTP 200, mecánicamente parecía una “publicación correcta”.

Ese día entendí algo: rapidez y seguridad no son lo mismo. Cuando delegas el despliegue entero, parece que termina en un instante. Pero si no queda registro de qué se comprobó, cuando algo se rompe no sabes qué hay que revertir. Hoy escribo el remedio que uso: antes de dar permisos de producción, hacer una “simulación en seco” (dry run) para reunir evidencia.

Puntos clave

• La mayoría de los accidentes al delegar despliegues en Claude Code vienen de saltarse la comprobación previa a tocar producción.
• Antes de dar permisos reales, verifica en seco cinco cosas: build, diff, URL de preview, responsable del rollback y qué quedó sin tocar.
• Separar “lo que una máquina puede comprobar” de “lo que una persona debe mirar con los ojos” reduce los accidentes nocturnos.
• Te dejo una plantilla de prompt para copiar y pegar, y código que verifica el resultado de forma automática.
• No necesitas reglas perfectas desde el principio. Pruébalo con una sola corrección y añade a la checklist cada sitio donde te tropieces.

Los accidentes de despliegue no vienen de la “inteligencia”, sino de no comprobar

Claude Code es muy capaz. Pero ser capaz y poder operar con seguridad en producción son cosas distintas.

Es como el estudiante que saca diez en todos los exámenes y rompe la caja registradora en su primer día de trabajo: no es un problema de capacidad, es un problema de andamiaje. En despliegue, el andamiaje es “qué compruebas antes de tocar producción”.

Los despliegues de sitios estáticos fallan en silencio. Si el build pasa y el HTTP devuelve 200, a simple vista parece que todo salió bien. Aunque el contenido esté vacío o la página se haya cambiado por otra, si solo miras el código de estado no te enteras. Por eso no basta con “¿el código funcionó?”: hay que mirar con los ojos, una vez, “¿está saliendo la página correcta y bien?”.

Los 5 pasos de la simulación antes de tocar producción

El procedimiento que uso ahora es solo esto. El orden importa, así que va de arriba abajo.

1. Primero pasa el build en local. Si esto falla, hablar de producción es prematuro. Antes de tocar producción, separa si el problema es del código o del entorno.
2. Lee el diff. Comprueba con tus ojos que no se haya colado información sensible (claves de API, tokens) ni cambios que afecten a la facturación.
3. Abre la URL de preview. Verifica en la pantalla real que el encabezado (h1), la URL canónica (canonical) y el destino del botón de registro sean los esperados.
4. Decide quién hace el rollback y cómo. Si algo falla, quién y con qué comando vuelve al estado anterior. Si no lo decides antes, te quedas paralizado en el momento del accidente.
5. Pide los permisos de producción solo cuando tengas la evidencia. Solo cuando salen los resultados del 1 al 4, le pides a Claude Code el despliegue real.

Con solo respetar este orden, el accidente del principio (la portada en blanco) prácticamente no ocurre. Porque en el paso 3 siempre abres la preview.

Qué delegar en la IA y qué decides tú

No se trata de delegar todo en la IA, ni de volver a hacerlo todo a mano. Se reparten los roles. La tabla de abajo es la línea que trazo en mi día a día.

Situación	Qué delego en Claude Code	Evidencia que mira la persona
Publicar un artículo	Lanzar antes la comprobación automática del build de dist y de la URL pública	Resultado del build, diff, URL
Cambiar el botón de registro	Cotejar en preview el destino del enlace y el flujo de contacto	Resultado del build, diff, URL
Corregir un Worker	Sacar solo el log de la simulación, sin tocar variables de entorno	Resultado del build, diff, URL

La clave es este reparto: leer, ordenar y comprobar de forma automática se lo dejas a la IA; las operaciones que hacen cambios irreversibles en producción las aprueba una persona. Borrar, escribir en la base de datos de producción, cobrar y los force push: al principio déjalos todos en “preguntar a la persona”. Solo asciendes a automático, más tarde, las operaciones que ya sabes que son seguras.

Si quieres trazar la línea de permisos con más detalle, te sirven la guía de configuración de permisos de Claude Code y la auditoría de permisos antes del despliegue.

Plantilla de prompt para copiar y pegar

El truco no es soltar el encargo a ciegas, sino dejar explícito “todavía no lo saques a producción”. Puedes pegar esta plantilla tal cual.

Convierte este cambio en una "checklist de simulación" previa al despliegue a producción.
Devuélveme en una tabla los siguientes puntos:
- Resultado del build (éxito / fallo y el resumen del log)
- Riesgo del diff (si incluye información sensible, facturación o borrados)
- URL de preview
- Responsable del rollback y comando de rollback
- Áreas que no se han tocado
- Condiciones para reintentar
No ejecutes todavía el despliegue a producción. Espera a que yo confirme la checklist.

Las dos últimas líneas son las que hacen el trabajo. Si escribes “todavía no lo ejecutes” y “espera a que yo confirme”, evitas que Claude Code se ponga servicial y publique por su cuenta. Cómo redactar los prompts para inclinar la balanza hacia el lado seguro lo recojo en diseño de prompts para usuarios avanzados.

Script de verificación que funciona al copiar y pegar

Si el resultado de la comprobación lo juzga una máquina en vez de “tu intuición”, se te escapan menos cosas. El siguiente script recibe el objeto con el resultado de la simulación y devuelve un booleano que dice si ya puedes pedir permisos de producción. Si tienes Node.js, funciona tal cual.

// Resultado de la simulación. Aquí pones lo que comprobaste de verdad.
const deployCheck = {
  build: "passed",              // si el build local pasó
  diffReviewed: true,           // si revisaste el diff con los ojos
  previewUrl: "https://example.pages.dev", // URL de preview
  rollbackOwner: "Masa",        // responsable del rollback
  changedAreas: ["content", "cta-copy"],   // áreas tocadas
};

// Portero que decide si ya puedes pedir permisos de producción
function canRequestProductionAccess(check) {
  return (
    check.build === "passed" &&          // el build pasó
    check.diffReviewed &&                // revisaste el diff
    /^https:\/\//.test(check.previewUrl) && // la URL de preview existe y es https
    check.rollbackOwner.length > 0 &&    // hay responsable de rollback
    !check.changedAreas.includes("secrets") // no se tocó el área sensible
  );
}

const ready = canRequestProductionAccess(deployCheck);
console.log({ ready });
// Hasta rellenar los campos donde "ready" sea false, no pidas el despliegue a producción

El valor de este código está en que devuelve false en el instante en que changedAreas contiene "secrets". Si tocaste información sensible sin querer, jamás llegas a pedir permisos de producción. Aunque la persona ande con prisas y se le pase, el portero te frena.

Tres situaciones donde de verdad funcionó

La primera, publicar un artículo. Con solo “saca el blog”, en cuanto pasa el build se va corriendo hasta publicar. Si metes la simulación en medio, abres antes la URL pública y compruebas que el encabezado y el contenido coinciden, así que el accidente de la pantalla en blanco del principio se detiene.

La segunda, sustituir el botón de registro. Basta con teclear mal una letra del enlace para que ese flujo, tan trabajado, caiga en un 404. Desde que metí el paso de pulsar el botón de verdad en preview para verificar el destino, los enlaces rotos pasaron a cero.

La tercera, corregir un Cloudflare Worker. Aquí, con borrar una sola variable de entorno, producción se cae. Por eso en la simulación no dejo que toque las variables de entorno y solo saco el log. Los detalles propios de Workers los recojo también en el artículo sobre integración con Cloudflare Workers.

Trampas habituales y cómo arreglarlas

Tres fallos que cometí de verdad, con su arreglo.

Trampa 1: lanzar el comando de producción antes del build. Si arrancas directo con wrangler deploy, cuando falla no puedes separar si la culpa es del código o del entorno. El arreglo es simple: pasa siempre primero el build local. Con cambiar un solo paso de orden, encontrar la causa se vuelve mucho más rápido.

Trampa 2: no decidir quién hace el rollback. Si empiezas a debatir “¿quién revierte?” después de que falle, esos minutos los pagan los usuarios de lleno. El arreglo es dejar por escrito, ya en la simulación, el responsable y el comando de rollback. Con solo anotar el previousDeployId, la recuperación va más tranquila.

Trampa 3: fiarte solo del código de estado sin abrir la preview. El HTTP 200 solo significa “el servidor devolvió algo”, no “salió la página correcta”. El arreglo es abrir siempre la URL de preview una vez en el navegador y mirar con los ojos el encabezado, la URL canónica y la imagen de portada. Esta fue la única forma de cazar la pantalla en blanco del principio.

Deja la evidencia como una “nota reutilizable”

Lo que compruebas en la simulación, si en lugar de borrarlo lo resumes en una nota corta, hace que el siguiente trabajo vaya mucho más rápido.

Basta con guardar esto: el primer texto del encargo, qué rango leyó Claude Code, qué no tocó, qué comandos de comprobación ejecutaste, la URL pública o las capturas, y los puntos donde dudaste al decidir. No hace falta un acta larga. El objetivo se cumple si luego puedes rastrear “por qué tomé esta decisión”.

Lo que más ayuda es escribir en una línea “el punto de bifurcación”. Por ejemplo: “la URL de preview es correcta, pero no hay responsable de rollback, así que producción todavía no”. La próxima vez que hagas el mismo trabajo, tú u otra persona podréis reproducir la misma comprobación. La misma idea sirve para otras automatizaciones más allá del despliegue, así que si lo lees junto con la introducción a Claude Code para no programadores, creo que cogerás el pulso a cómo delegar.

Preguntas frecuentes

P. ¿La simulación no es al final solo trabajo extra? Al principio lo sientes así. Pero cuando ocurre un accidente, se te van horas en recuperar y averiguar la causa. La simulación son unos minutos. La sigo haciendo porque es un seguro que sale a cuenta.

P. Si el build local pasa, ¿puedo no mirar la preview? No. Aunque el build pase, ocurren cambios de plantilla y páginas vacías. Un HTTP 200 y “la página correcta” son cosas distintas, así que la revisión visual no se puede saltar.

P. ¿Tiene sentido decidir el responsable del rollback si trabajo solo? Sí. Aunque seas uno solo, dejar por escrito de antemano “si falla, revierto con este comando” hace que no dudes cuando llega el accidente. Decidirlo ya es, en sí, parte del procedimiento.

P. Si Claude Code dice “Publicado”, ¿puedo creerle? Mira la evidencia de la simulación más que la respuesta en sí. Decide según si están el build, el diff, la preview y el responsable del rollback. Las palabras son ambiente; la evidencia es un hecho.

P. ¿Hace falta llegar a tanto en un sitio pequeño? Piénsalo por “¿puedo revertir?” más que por el tamaño. Aunque sea pequeño, si producción se cae, te complica la vida. Empieza por meter solo el paso de abrir la preview y notarás el efecto.

Lo que pasó al probarlo de verdad

Después del accidente de la pantalla en blanco del principio, incorporé este procedimiento de simulación a la operación de mi propio blog.

Comprobé tres cosas. Una: al imponer la regla de abrir siempre la URL de preview, las páginas vacías por cambio de plantilla pasaron a cero. Dos: al lanzar el script de verificación de arriba antes de publicar, los cambios que tocaban el área sensible se frenaban con ready: false y ya no llegaban a la petición de permisos de producción. Tres: al anotar cada vez el responsable y el comando de rollback, incluso en los momentos de susto pude volver al estado anterior en unos minutos.

Más que delegar todo en una IA muy lista y rezar, prefiero construir antes un andamiaje donde, si me caigo, no me hago daño. Parece un rodeo, pero mi conclusión hoy es que al final es lo más rápido. Empieza por el paso de abrir la preview y añade un portero a tus despliegues.

Si quieres ordenar con tu equipo la línea de despliegue a producción y todo el sistema de revisión, en formación y consultoría lo convertimos juntos en un procedimiento. Para los criterios oficiales de operación, consulta también la documentación oficial de Claude Code de Anthropic.