Claude Code arregla nuestros despliegues fallidos, y una persona fusiona el arreglo

Qué hace Fundaia, en breve

Un proyecto de Fundaia tiene servicios. Un servicio suele venir de un repositorio de GitHub: la plataforma construye una imagen, la arranca en un contenedor de podman sin root y la publica en su propia dirección. Las variables pueden apuntar unas a otras, así que una aplicación lee la dirección de su base de datos del Postgres que tiene al lado sin que nadie la copie a mano.

Cada despliegue pasa por las mismas seis etapas: la cola, la descarga del código, la construcción, el arranque, la comprobación de salud y la puesta en marcha. El contenedor nuevo solo recibe tráfico cuando pasa la comprobación de salud. Si un despliegue falla por el camino, el anterior sigue sirviendo, así que un despliegue en rojo es un problema que resolver, no una caída. Eso es lo que hace razonable dejar que un agente lo mire con calma.

Primero, un diagnóstico sin IA

Antes de cualquier modelo hay un diagnóstico hecho con reglas normales. Lee el estado del servicio y responde con un veredicto (sano, necesita atención, fallando, dormido o parado), sus hallazgos ordenados por gravedad y, para cada uno, el siguiente comando que conviene ejecutar. No llama a ningún modelo, así que no cuesta nada y da la misma respuesta dos veces.

• El último despliegue falló, en qué etapa y con qué mensaje, y si sigue sirviendo uno anterior.
• El contenedor se ha parado solo, o corre pero no responde a la comprobación de salud.
• Se ha reiniciado tres veces o más sin que nadie lo pidiera.
• Una variable apunta a otra que no existe, así que el contenedor recibe el texto literal.
• Errores que se repiten en sus logs, agrupados por su forma.

Muchos fallos acaban aquí: una variable que no apunta a nada no necesita un agente. Claude Code entra cuando la causa está en el código o en la receta de construcción, y solo si una persona lo pide.

Qué pasa al pulsar Arreglar con Claude

El despliegue fallido se convierte en una incidencia: su mensaje de error es la muestra (hasta 2.000 caracteres) y las últimas 60 líneas de su log son el contexto. A partir de ahí el arreglo sigue cuatro pasos, cada uno visible en directo en el panel: reunir el contexto, diagnosticar, reproducir y arreglar, más un quinto, abrir el pull request, que es de la plataforma y no del agente.

1. Diagnosticar. El agente lee el repositorio y responde solo con un JSON: la causa, los ficheros implicados, su confianza (alta, media o baja) y si cree que una prueba podría detectar el fallo. No cambia nada.
2. Reproducir. Escribe una prueba que falla por culpa de ese error, con el framework que ya usa el repositorio, y la ejecuta para comprobar que falla por el motivo correcto, no porque no compile.
3. Arreglar. Hace el cambio más pequeño que hace pasar la prueba, y la conserva. El prompt le pide que no reformatee, no renombre ni ordene nada de paso: quien lo revise lo está revisando precisamente porque lo ha escrito una máquina.

Cada paso es una llamada distinta al componente de Claude Code, que ejecuta claude en modo no interactivo con un límite de diez minutos por prompt. La plataforma lee la respuesta de cada paso y decide si sigue. Estas son las comprobaciones, sacadas del código:

const diagnosis = parseAnswer<Diagnosis>(answer)

if (diagnosis === null) throw new Error('El agente no devolvió un diagnóstico legible')
if (diagnosis.confidence === 'low') {
  throw new RunStopped(
    'rejected',
    'El agente no encontró la causa con los logs disponibles, y no ha tocado nada',
  )
}
// ...
if (!reproduction.reproduced) {
  throw new RunStopped(
    'notReproducible',
    reproduction.note === ''
      ? 'No se pudo reproducir el fallo, así que no se ha cambiado nada'
      : reproduction.note,
  )
}
// ...
if (!fix.fixed) throw new RunStopped('rejected', 'El agente no consiguió arreglarlo')
if (diff.trim() === '') throw new Error('El agente dijo haberlo arreglado sin cambiar nada')

Qué puede tocar el agente

Dentro de su contenedor, Claude Code trabaja con las peticiones de permiso desactivadas, porque no hay nadie para contestarlas. Eso solo tiene sentido si el límite es el propio contenedor, así que el límite está hecho por capas:

• Cada prompt trabaja sobre un clon nuevo y superficial de una sola rama (profundidad 1), con los hooks de git desactivados y el remoto borrado nada más clonar. Al acabar el prompt, el clon se borra.
• El clon usa un token de GitHub que solo puede leer el contenido del repositorio y caduca en una hora. El agente nunca tiene una credencial que pueda empujar.
• El contenedor se queda sin ninguna capacidad de Linux salvo las que necesita para dejar de ser root, no puede ganar privilegios nuevos y ejecuta Claude Code como un usuario normal.
• Lo que la plataforma recoge del contenedor es la respuesta del agente y un diff de lo que ha cambiado. Nada más.

const clone = Bun.spawn([
  'git',
  '-c', 'credential.helper=',
  '-c', 'core.hooksPath=/dev/null',
  'clone', '--depth', '1', '--single-branch', '--branch', branch,
  // ...
])
// ...
await git(target, ['remote', 'remove', 'origin'])

Aquí no hay ninguna credencial de red que pueda empujar: la plataforma toma tus cambios como un parche, los valida y abre ella misma el pull request. Editar ficheros es todo lo que puedes hacer, y basta.

El texto con el que empiezan los tres prompts (traducido del inglés)

Antes de que nada llegue a GitHub, la plataforma revisa el diff con su propio validador, sin ningún modelo. Algunas cosas paran el arreglo. Otras el validador las clasifica como cosas que necesitan a una persona: no lo paran y llegan al pull request, que nadie fusiona de forma automática. El prompt ya le pide al agente que no toque workflows de CI, hooks de git ni scripts de instalación salvo que el fallo esté literalmente en uno de ellos:

const credentialLike = [
  /(^|\/)\.env(\..+)?$/,
  /(^|\/)id_(rsa|dsa|ecdsa|ed25519)$/,
  /\.(pem|key|p12|pfx|keystore)$/,
  // ...
]

const secretPatterns = [
  /\bsk-ant-[A-Za-z0-9_-]{16,}/,
  /\bgh[pousr]_[A-Za-z0-9]{16,}/,
  /\bAKIA[0-9A-Z]{16}\b/,
  // ...
]

Solo después la plataforma aplica el parche por su lado, hace el commit y empuja la rama con un segundo token, uno que puede escribir contenido y pull requests y que nunca sale del proceso de la plataforma. Viaja en el entorno, no en la línea de comandos, donde cualquier usuario de la máquina podría leerlo.

Quién lo aprueba

Una persona, siempre. La plataforma abre el pull request en una rama propia, le pone la etiqueta autofix y escribe la descripción para quien tenga que revisarlo: qué fallaba, por qué, el comando y la salida de la prueba que fallaba antes del cambio, qué se ha cambiado y qué podría seguir saliendo mal. Empieza con una frase sin rodeos: nadie lo ha revisado todavía, eso te toca a ti.

Fundaia nunca fusiona estos pull requests. Cuando alguien del equipo fusiona uno, la rama se mueve y la plataforma lo despliega como cualquier otro push. La plataforma mira además quién respalda ese push: el autor del commit es su propio bot, Fundaia Autofix, pero que lo fusione un miembro del espacio de trabajo lo avala. Un push que nadie del espacio avala espera hasta que un miembro lo aprueba.

Cuando no consigue arreglarlo

Casi todo el diseño gira alrededor de este caso. Cada forma de pararse tiene su nombre, y en todas la incidencia vuelve a quedar abierta, así que nada se queda a medio reclamar:

Desde el mismo menú, un despliegue fallido se puede convertir en una issue de GitHub con sus pruebas: el commit, el mensaje de error y las últimas líneas del log. El token para eso solo puede escribir issues. Pedirlo dos veces enlaza la misma issue en vez de abrir otra, así que un equipo que prefiere arreglar a mano no pierde nada por probar antes con el agente.

Límites de dinero y de frecuencia

Un agente que se queda dando vueltas a un fallo terco puede gastar mucho. Estos son los valores por defecto de cada servicio:

el modo automático, hasta que alguien lo enciende

Apagado

arreglos por servicio y día, también cuando lo pide una persona

3

techo de coste por incidencia, comprobado tras cada prompt

2 €

el límite de cada prompt dentro del contenedor

10 min

• El agente se paga con crédito por adelantado. Cuando se acaba, el agente se para en vez de ir generando una factura que nadie ha visto.
• El coste se conoce cuando responde cada prompt, así que un arreglo puede pasarse del techo como mucho en un prompt, y ahí se para.
• Arreglar un despliegue fallido siempre hay que pedirlo, desde el botón, la línea de comandos o una herramienta MCP; la plataforma nunca lo empieza sola. El modo automático solo cubre errores que se repiten mientras el servicio funciona, a partir de cinco apariciones por defecto y con un arreglo por servicio cada cinco minutos como mucho.
• El modelo por defecto es Sonnet. Cada servicio puede elegir otro, y el arreglo se cobra del mismo crédito que cualquier prompt.

Lo que nos llevamos

Tenemos el autofix de errores en producción desde agosto de 2026 y el de despliegues fallidos desde septiembre. La parte que usa IA son tres prompts. El resto es código que no se fía de ella: un diagnóstico determinista primero, un contenedor que solo puede editar ficheros, un validador que lee el diff, un techo de dinero y una persona que decide.

Es el mismo reparto que usamos cuando construimos agentes de IA para los procesos de un cliente: el modelo propone, código normal comprueba lo que ha propuesto y el paso que no se puede deshacer es de una persona. También es como entendemos el mantenimiento de software: el agente ahorra la primera hora de leer logs, no la revisión. Si estás eligiendo el modelo para este tipo de trabajo, comparamos los actuales en Opus 5.5, GPT-6 Astra o GPT-6.1 Sol.