Un responsable de DevOps presenta nib: un agente que divide los despliegues en AWS en etapas, comprobaciones y planes de reversión

«Despliega un nuevo servicio web en AWS y configura los jobs de despliegue». Una sola línea en el gestor de incidencias. Detrás hay una red, contenedores, una base de datos, secretos, una CDN, dos flujos de trabajo y decenas de pequeñas acciones que el ingeniero retiene en la cabeza. Mientras nadie te interrumpa, funciona. Pero después de una llamada ya no recuerdas si cerraste el puerto de la base de datos, y la única respuesta honesta a «¿cuánto tardará?» es «un día o dos».

El autor del análisis dirige un equipo de DevOps en un estudio de videojuegos y tiene 15 años de experiencia. Formalizó su método de planificación y se lo encomendó a un agente llamado nib (Neuro Infrastructure Builder).

Cómo planifica un ingeniero experimentado

Primero se recopila el contexto: de qué proyecto se trata, cómo está organizada la infraestructura actual y qué se sabe de los productos implicados en la tarea. Después, la tarea se divide en grandes etapas: código de infraestructura, flujos de compilación y despliegue, creación de recursos, despliegue y verificación. Más importantes que la propia lista son las dependencias entre etapas, que determinan qué puede hacerse en paralelo.

Cada etapa se desglosa en acciones elementales: modificar un archivo, ejecutar un comando o hacer una llamada a una API. Cada acción necesita una comprobación y un procedimiento de reversión. Por ejemplo, después de terraform plan, el diff no debe contener ninguna operación destroy y, tras apply, RDS debe estar en estado available. La columna «Reversión» suele dejarse vacía. El autor pregunta: ¿cuándo fue la última vez que escribiste un plan de reversión antes de necesitarlo?

El proceso falla en tres puntos. Algunas tareas se olvidan al cambiar de contexto: el autor trasladó una vez buckets de recursos entre nubes y se olvidó de CORS. Las comprobaciones se recortan cuando se acerca la fecha límite, porque omitirlas no rompe nada de inmediato. Y falta una estimación del volumen de trabajo: mientras la tarea no esté desglosada, «un día o dos» es una sensación, no una estimación.

Qué hace nib

La herramienta funciona en tres modos. Decompose plantea preguntas aclaratorias e identifica las etapas y sus dependencias. Plan pone en marcha un agente por etapa; estos detallan en paralelo las acciones y comprobaciones, mientras otro agente elabora el plan de reversión. Execute realiza una acción mediante las herramientas conectadas o proporciona instrucciones detalladas al operador.

Una base de conocimiento aporta el contexto que normalmente maneja el ingeniero: descripción de la empresa, VCS, CI/CD, topología de red y convenciones de nombres. Al completar el plan, nib redacta un informe y actualiza la base, de modo que la siguiente tarea parte de lo que el agente aprendió en la anterior.

La instalación es local: git clone, make setup, Docker y una clave de cualquier proveedor compatible con OpenAI. Las herramientas se conectan mediante MCP con transporte HTTP: GitHub, la API de AWS y SearXNG para buscar documentación. El servidor de AWS expone solo dos herramientas —una para invocar la CLI y un asistente de comandos—, mientras que GitHub ofrece un par de docenas. Para evitar que el contexto crezca demasiado, nib selecciona únicamente las categorías de herramientas necesarias durante la descomposición.

Dónde es fácil equivocarse

La configuración de seguridad del ejemplo es permisiva. READ_OPERATIONS_ONLY: false permite cambios, y REQUIRE_MUTATION_CONSENT: false elimina la confirmación del lado del servidor MCP. El botón Execute del propio nib sigue siendo el paso de confirmación. AUTH_TYPE: no-auth solo es aceptable porque el puerto no está expuesto al exterior y el servicio únicamente es visible dentro de la red de Docker.

Los secretos se guardan en dos lugares. El contenedor aws-mcp necesita las claves de AWS, por lo que estas van en .env. El token de GitHub se envía en una cabecera desde nib al servidor MCP y se almacena en los secretos de nib con una lista de hosts permitidos. GitHub requiere un token clásico con los permisos repo y workflow; sin el segundo, el agente no puede hacer commits de archivos en .github/workflows.

La conclusión práctica

El principal valor está en la disciplina: una acción, una comprobación y un procedimiento de reversión en cada paso. Incluso sin nib, conviene preparar esta tabla antes de empezar, y una estimación basada en el número de acciones es más honesta que «un día o dos». Si pruebas la herramienta, utiliza una cuenta de AWS independiente para pruebas y concede al agente solo los permisos que necesite. Esta entrega cubre únicamente la base de conocimiento; el autor promete abordar las reglas y las habilidades en el próximo artículo.