# Claude Code arregla despliegues fallidos, con límites | Alher Tech

> Cómo usamos Claude Code para arreglar despliegues fallidos: una prueba que falla, un clon de solo lectura, un validador del diff y un PR que fusiona alguien.

- Canonical page: https://alhertech.com/es/blog/claude-code-arregla-despliegues-fallidos/
- Site: Alher Tech (custom software, AI agents and SEO engineering, https://alhertech.com/)
- Contact: https://alhertech.com/es/contacto/

---

IA · 26 oct 2026 · 10 min de lectura

Fundaia es la plataforma de despliegue que hemos construido para nosotros: lleva un repositorio de GitHub a su propio dominio, con base de datos. Cuando un despliegue falla, en su menú hay un botón que dice Arreglar con Claude. Al pulsarlo, el fallo pasa a Claude Code, que lee el log y el repositorio, escribe una prueba que falla por culpa del error, lo arregla y deja el cambio como pull request. Este post va de ese botón y, sobre todo, de todo lo que hay alrededor: qué puede tocar el agente, quién aprueba el cambio y qué pasa cuando no consigue arreglar nada.

## 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.

De un despliegue fallido a un pull request: la plataforma manda el log a un contenedor de Claude Code que solo edita un clon desechable, revisa el diff, abre ella misma el pull request y deja la fusión a una persona; si el agente no puede arreglarlo, se para y la persona puede abrir una issue.
Quién hace qué cuando falla un despliegue. El agente solo edita ficheros; la plataforma empuja; una persona fusiona.
- 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.
- 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.
- 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')**Primero, reproducir**

Si el agente no consigue escribir una prueba que falle, el arreglo se para y no cambia nada. Un arreglo que nadie puede comprobar es peor que ninguno, y el prompt se lo dice al agente con esas palabras.

## 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:

| El cambio | Qué hace la plataforma |
| --- | --- |
| Una ruta que apunta fuera del repositorio | Para el arreglo |
| Un fichero con pinta de credencial (.env, claves privadas, .pem, .key…) | Para el arreglo |
| Una línea añadida con forma de secreto (claves de Anthropic, GitHub o AWS, claves privadas) | Para el arreglo |
| Workflows de CI, hooks de git, .npmrc u otros ficheros que deciden de dónde vienen las dependencias | Lo deja pasar al pull request |
| Un script de instalación en package.json (preinstall, postinstall…) | Lo deja pasar al pull request |
| Ficheros binarios, más de 40 ficheros o más de 2.000 líneas añadidas | Lo deja pasar al pull request |

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.

**Solo diagnosticar**

Cada servicio puede quedarse también en solo diagnosticar. El arreglo pasa por los mismos pasos, el resultado se queda en la plataforma y no se abre ningún pull request.

## 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:

| Qué pasó | Cómo acaba |
| --- | --- |
| El agente abrió el pull request | Terminado, y la incidencia espera a que una persona revise el arreglo |
| El log no basta para encontrar la causa (confianza baja) | Descartado, sin tocar nada |
| No pudo escribir una prueba que falle | No se pudo reproducir, con el motivo del agente en una frase |
| Lo intentó y no consiguió arreglarlo | Descartado |
| Dijo que lo había arreglado, pero el diff está vacío | Fallido |
| El diff toca algo que no puede tocar | Descartado, con el fichero y el motivo |
| Llegó al techo de coste | Descartado |

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 enciendeApagadoarreglos por servicio y día, también cuando lo pide una persona3techo de coste por incidencia, comprobado tras cada prompt2 €el límite de cada prompt dentro del contenedor10 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](https://alhertech.com/es/servicios/agentes-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](https://alhertech.com/es/servicios/mantenimiento-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](https://alhertech.com/es/blog/opus-5-5-gpt-6-astra-gpt-6-1-desarrollo-de-software/).

## Preguntas

### ¿Puede la IA desplegar algo en producción por su cuenta?

No. Edita ficheros en un clon desechable y devuelve un diff. La plataforma lo valida y abre un pull request, que nunca fusiona. Un cambio solo llega a producción cuando una persona del equipo lo fusiona y el despliegue de siempre lo recoge.

### ¿Ve el agente los secretos del servicio?

Recibe el repositorio, el mensaje de error y las últimas líneas del log, no las variables del servicio. Si la aplicación escribe un secreto en sus propios logs, esa línea viaja como cualquier otra, que es un motivo más para no escribir secretos en los logs. En sentido contrario, un cambio que añade un fichero de credenciales o una línea con forma de clave para el arreglo antes de llegar a GitHub.

### ¿Y si el agente se equivoca con la causa?

Para eso tiene que reproducirlo primero. Si su diagnóstico tiene confianza baja, o no consigue escribir una prueba que falle por culpa del error, el arreglo se para sin cambiar nada. Si pasa, el pull request lleva la prueba y su salida, así que quien revisa puede comprobarlo en vez de creérselo.

### ¿Cuánto cuesta cada arreglo?

Depende del modelo y de cuánto tenga que leer, así que no damos una media. Lo que está fijo es el techo: cada incidencia tiene un límite de coste (2 € por defecto), que se comprueba tras cada prompt, y el agente funciona con crédito por adelantado que lo para cuando se acaba.

## Fuentes

- [Fundaia: Arreglos con Claude Code](https://infrastructure.fundaia.com/docs/autoreparacion)
- [Fundaia: Claude Code](https://infrastructure.fundaia.com/docs/claude-code)
- [Claude Code: Run Claude Code programmatically](https://code.claude.com/docs/en/headless)
- [Claude Code: Development containers](https://code.claude.com/docs/en/devcontainer)
- [Claude Code: Security](https://code.claude.com/docs/en/security)
- [GitHub: Generating an installation access token for a GitHub App](https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-an-installation-access-token-for-a-github-app)
- [Podman: podman run](https://docs.podman.io/en/latest/markdown/podman-run.1.html)

## Sigue leyendo

- [Opus 5.5, GPT-6 Astra o GPT-6.1 Sol: con qué modelo crear el software de tu empresa](https://alhertech.com/es/blog/opus-5-5-gpt-6-astra-gpt-6-1-desarrollo-de-software/)
IA · 25 oct 2026 · 9 min de lectura

No hay un ganador para todo. Opus 5.5 saca las mejores notas en los cambios largos y difíciles, GPT-6.1 Sol hace casi lo mismo por la duodécima parte del coste por tarea y GPT-6 Astra manda en operaciones. Cómo repartimos el trabajo entre ellos, qué pasa con los datos de tu empresa y qué traen los demás modelos de octubre.

- [Caso de estudio Leaderbrock: la app de un equipo comercial para la agenda, la ruta y los tickets](https://alhertech.com/es/blog/caso-estudio-leaderbrock/)
Casos de estudio · 26 oct 2026 · 11 min de lectura

El equipo comercial de Leaderbrock trabaja por Europa y América. Cómo sustituimos una hoja de cálculo compartida, un sobre de tickets y la falta de un mapa por un backend reactivo en Java, una app con Expo y un panel web: gastos con la foto que la IA rellena y una persona presenta, una agenda en la hora del móvil y una ruta GPS que distingue un vuelo del ruido.

- [Caso de estudio ReservPark: el móvil que sabe que dejas tu plaza](https://alhertech.com/es/blog/caso-estudio-reservpark/)
Casos de estudio · 26 oct 2026 · 12 min de lectura

ReservPark detecta por el Bluetooth del coche que has aparcado, te pregunta si te vas cuando vuelves a él y avisa a los conductores cercanos, y deja alquilar un garaje por horas o con abono. Cómo construimos la detección nativa, las reglas de la ubicación en segundo plano, las plazas libres de 30 minutos y unas reservas de garaje que no se pueden vender dos veces.

[Blog](https://alhertech.com/es/blog/)