Consejos clave — Con saber esto, ya puedes dar instrucciones
Que los agentes solo manejen el código no es el final. Para delegar builds, despliegues y monitoreo a los agentes, el sistema entero debe ser legible por los agentes. No necesitas entender los internos de Docker. El agente maneja todo.
Al agente: “Agrega un endpoint /health al servidor. Que devuelva el estado de conexión a la DB, la tasa de error y el uptime como JSON.”
Esta sola frase le da al agente ojos para leer el estado del sistema. Con /health, el agente puede verificar mecánicamente “¿el servidor está vivo?” Sin ello, es un cirujano operando a ciegas.
Al agente: “Configura este proyecto como docker-compose.yml. Incluye servidor de la app y DB. Todo debería arrancar con docker compose up.”
No necesitas saber qué es Docker. Solo saber que es una herramienta que empaqueta apps en una caja para que funcionen igual en cualquier lugar es suficiente. El agente maneja desde la instalación hasta la configuración.
Al agente: “Configura rollback automático en caso de fallo del deploy. Si /health falla, revierte a la versión anterior.”
Los agentes inevitablemente cometerán errores. Los errores deben ser reversibles. Esta sola frase es la red de seguridad.
Tres frases. Dale ojos al servidor, declara el sistema, tiende la red de seguridad. El agente hace el resto.
Prueba rápida
Abre cualquier proyecto (o la app de la Clase 1) con Claude Code:
“Agrega un endpoint /health al servidor. Que devuelva el estado de conexión a la DB, la tasa de error y el uptime como JSON. Todos los tests Hurl existentes deben pasar.”
Después de que el agente agregue el código:
“Crea un test Hurl que verifique que /health devuelve 200. Verifica también que la respuesta JSON tenga los campos db, status y uptime.”
Este es el inicio de la Observabilidad. El agente ahora puede leer mecánicamente el estado del sistema.
Por qué debes dar instrucciones de esta manera
Introducción: Más allá del código
En la Clase 8 hicimos que el código fuera legible y editable por agentes. Dividimos archivos con filefunc, aseguramos tests con tsma, rastreamos historial de cambios con whyso.
¿Pero es suficiente que solo el código sea agent-operable?
Después de modificar código, hay que compilar. Después de compilar, desplegar. Después de desplegar, monitorear. Si algo falla, revertir. Si cualquiera de estos pasos requiere acción manual humana, el alcance autónomo del agente termina en “editar código.”
Todo este proceso manual debería estar conectado como un solo pipeline. El agente edita código, ejecuta tests, compila, despliega, monitorea — los humanos solo presionan el botón de aprobación.
Esto es Agent Operable System.
Del código al sistema
El código es una parte del sistema. El sistema es la totalidad de código + infraestructura + pipeline de despliegue + monitoreo + procedimientos operativos.
Si algún eslabón de esta cadena es opaco para el agente, todo lo que sigue se convierte en responsabilidad humana. Un eslabón roto derrumba toda la automatización.
4 condiciones para Agent Operable System
Condición 1. Observabilidad — Todo estado mecánicamente observable
Los agentes no tienen ojos. No pueden ver pantallas. No pueden leer dashboards. Para que un agente conozca el estado del sistema, ese estado debe salir como texto.
# Observación del agente
$ curl -s localhost:8080/health | jq .
{
"status": "ok",
"db": "connected",
"uptime": "3h42m",
"error_rate_5m": 0.02
}
→ ¿error_rate > 0.05? → Alerta
Núcleo de la observabilidad: no lo que los humanos ven, sino lo que las máquinas pueden parsear.
Un sistema sin observabilidad es un cirujano operando a ciegas.
Condición 2. Declarativo — Todas las acciones definidas declarativamente
Cuando le dices a un agente “despliega”, ¿qué hace?
Sin sistema declarativo: El agente adivina “normalmente se hace así.” SSH al servidor, git pull, reiniciar proceso… y se le olvida algo.
Con sistema declarativo: Todo está escrito en archivos. Sin adivinación. Los archivos son la verdad.
# docker-compose.yml — Qué servicios ejecutan
services:
app:
build: .
ports: ["8080:8080"]
environment:
DATABASE_URL: ${DATABASE_URL}
# Makefile — Qué comandos hacen qué
deploy:
docker compose up -d
curl -sf localhost:8080/health || (docker compose logs && exit 1)
El principio SSOT de la Clase 4 se aplica idénticamente aquí. Docker es una herramienta que empaqueta apps en una caja para que funcionen igual en cualquier lugar. Terraform gestiona servidores como archivos de código. No necesitas entender los internos. El agente se encarga.
Condición 3. Reversible — Todos los cambios verificables y reversibles
Si el agente desplegó y el servicio murió, se necesitan dos cosas: poder saber qué salió mal, y poder revertir al estado anterior.
Los cambios irreversibles no se pueden delegar a agentes. Los agentes cometerán errores — y lo harán inevitablemente — así que los errores deben ser reversibles.
Condición 4. Human-in-the-loop — Las puertas de aprobación son explícitas
La más importante de las cuatro condiciones. Estructura donde el agente juzga y el humano aprueba. No “humano instruye, agente ejecuta” sino “agente propone, humano aprueba.”
| Tarea | Auto-ejecutar | Necesita aprobación |
|---|---|---|
| Ejecutar tests | O | |
| Formateo de código | O | |
| Deploy a staging | O | |
| Deploy a producción | O | |
| Cambio de esquema de DB | O | |
| Cambio de variables de entorno | O | |
| Rollback (pre-aprobado) | O |
Las tareas reversibles pueden auto-ejecutarse. Las de difícil reversión o alto impacto deben pasar por aprobación.
El pipeline completo: De “agrega funcionalidad” al despliegue
En un proyecto con Agent Operable System, decir “agrega funcionalidad de consulta de historial de pedidos”:
1. Edición SSOT
Agente: Agrega ListOrders a features.yaml
Agente: Define GET /orders en OpenAPI
Agente: Define tabla orders en DDL
Agente: Declara flujo de servicio en SSaC
Agente: Escribe escenario de prueba en Hurl
2. Validación de consistencia
Agente: yongol validate → 0 errores
3. Generación de código
Agente: yongol generate → Controlador Go, consultas sqlc, componente React
4. Tests pasan
Agente: go test → PASS
Agente: Tests Hurl → PASS
5. Compilación
Agente: docker build → Éxito
6. Despliegue (puerta de aprobación)
Agente: "Todas las validaciones pasaron. Solicito aprobación para deploy a staging."
Humano: "Aprobado"
Agente: deploy staging → verificación /health → Normal
7. Deploy producción (puerta de aprobación)
Agente: "30 minutos sin errores en staging. Solicito aprobación para deploy a producción."
Humano: "Aprobado"
Agente: deploy producción → verificación /health → Normal
8. Completado
Agente: "Funcionalidad ListOrders desplegada.
Monitoreando. Rollback automático ante anomalías."
Lo que hizo el humano: “Agrega funcionalidad de consulta de historial de pedidos” + “Aprobado” dos veces. Lo que hizo el agente: Todo lo demás.
Esta es la forma completa del escalamiento del vibe coding.
Visión — El final del escalamiento del vibe coding
Clase 1: "Agrega funcionalidad" → Aparece código → Se derrumba a 5 funcionalidades
Clase 9: "Agrega funcionalidad" + "Aprobar"
→ Generación de código → Tests pasan → Compilar → Desplegar → Monitorear
→ Todo el pipeline dirigido por el agente
Una estructura donde personas sin formación en ingeniería de software pueden mantener, desplegar y operar 100+ endpoints.
Pero aún falta algo. Estructuramos el código, estructuramos el sistema. ¿Pero los datos?
La Clase 10 completa el último puzzle.
Ejercicio
Ejercicio obligatorio (no técnicos)
Objetivo: Agregar un endpoint /health y verificar con Hurl.
Paso 1 — Establecer observabilidad
Al agente: "Agrega un endpoint /health al servidor.
Que devuelva el estado de conexión a la DB, la tasa de error y el uptime como JSON.
Todos los tests Hurl existentes deben pasar."
Paso 2 — Escribir test Hurl
Al agente: "Crea un test Hurl que verifique que /health devuelve 200.
Verifica también que la respuesta JSON tenga los campos db, status y uptime."
Verificar:
- ¿/health devuelve 200?
- ¿El test Hurl pasa?
Ejercicio de desafío (opcional)
No necesitas instalar Docker tú mismo ni entender los archivos de configuración. Dile todo al agente.
Paso 1 — Docker Compose
Al agente: "Si Docker no está instalado, instálalo.
Configura este proyecto como docker-compose.yml.
Incluye servidor de la app y PostgreSQL.
Todo debería arrancar con docker compose up.
Agrega comandos build, deploy, test al Makefile."
Paso 2 — Pipeline CI/CD
Al agente: "Crea un workflow de GitHub Actions.
Al hacer push a la rama main:
1. Ejecutar go test
2. Ejecutar tests Hurl
3. Docker build
4. Desplegar a staging si todo pasa
Pero el deploy a producción requiere aprobación manual."
Paso 3 — Demo de integración
Pide al agente agregar una funcionalidad. Demuestra el pipeline completo desde la edición SSOT hasta el deploy a staging, con solo el deploy a producción requiriendo aprobación manual.
Artículos relacionados
Curso completo de Reins Engineering
| Clase | Título |
|---|---|
| Clase 1 | Cómo dirigir la IA |
| Clase 2 | Cómo desconfiar de la IA |
| Clase 3 | Aplicaciones irrompibles |
| Clase 4 | Decisiones fuera del código |
| Clase 5 | IA con riendas |
| Clase 6 | Si pasa, se bloquea |
| Clase 7 | Invertir la adulación |
| Clase 8 | La fábrica de agentes |
| Clase 9 | Automatización más allá del código |
| Clase 10 | La ley de los datos |
Fuentes
- Referencia Clase 8: Stanford “Lost in the Middle” (2024), Amazon “Context Length Alone Hurts LLM Performance” (2025) — El contexto innecesario degrada el rendimiento del agente un 30-85%
- Principios de observabilidad — La salida estructurada parseable por máquinas (endpoints /health, logs JSON) como prerequisito para operación por agentes
- Docker Compose — Configuración declarativa de servicios para que agentes lean y ejecuten sistemas sin adivinar
- Terraform — Infraestructura como Código, definición declarativa y cambios reversibles del estado de infraestructura
- CI/CD (GitHub Actions) — Automatización declarativa de pipelines de compilar-probar-desplegar
- Diseño Human-in-the-loop — Auto para tareas reversibles, puerta de aprobación obligatoria para tareas de alto impacto