Nunca me he considerado experto en AWS.
He aprendido lo que necesitaba sobre la marcha: desplegar, mirar logs, entender por qué un entorno no levantaba, perseguir una latencia rara, revisar costes, distinguir si el fallo venía de aplicación, infraestructura o base de datos.
Ese aprendizaje práctico sirve. Pero AWS es enorme. Siempre hay una métrica que no sabías que existía, una capa que no estabas mirando o una relación entre servicios que todavía no habías conectado.
Ahí Codex me ha cambiado bastante la sensación de capacidad.
No porque de repente yo sepa AWS en profundidad. Sino porque puedo convertir una intención operativa en una secuencia accionable:
quiero entender qué ha pasado en esta ventana;
quiero saber si esto es aplicación o infraestructura;
quiero una hipótesis con evidencias;
quiero que esto sea repetible la próxima vez.
Este artículo forma parte de la serie AI Product Engineering sin humo, donde estoy ordenando aprendizajes de producto, arquitectura y equipos al llevar IA a sistemas reales.
Empecé a convertir Codex en una especie de copiloto DevOps hacia mediados de febrero de 2026. El primer hito claro fue el 17 de febrero, cuando pasé de pedir análisis sueltos a construir runbooks y scripts para capturar evidencias de AWS, logs de infraestructura, señales de aplicación y resúmenes reproducibles.
La tesis fuerte es esta:
Codex no se vuelve útil en DevOps por tener una terminal. Se vuelve útil cuando cada incidente ayuda a construir una forma mejor de diagnosticar el siguiente.
De analizar a convertir en herramienta
La primera petición suele ser simple:
analiza este incidente.
Codex puede ayudar ahí. Puede leer logs, mirar métricas, cruzar timestamps, buscar errores, comparar eventos de despliegue y proponer una hipótesis.
Pero el salto importante viene justo después:
¿qué script o herramienta podríamos crear para que este análisis sea repetible?
Esa pregunta cambia el trabajo.
El incidente deja de ser solo un problema que hay que resolver. Se convierte en material de entrenamiento operativo.
Si para entenderlo hizo falta mirar salud del entorno, logs de aplicación, eventos de despliegue y señales de base de datos, entonces la siguiente versión del sistema debería capturar todo eso de forma automática. Si faltó una métrica, se añade. Si cruzar dos logs fue lento, se crea un correlador. Si una comprobación manual fue útil, se convierte en script.
La mejora no está en que Codex “sepa AWS”. Está en que ayuda a transformar una investigación puntual en tooling reutilizable.
El ciclo que cambia el juego
El patrón que mejor me está funcionando es este:
- Analizar un incidente real.
- Identificar qué evidencias fueron útiles.
- Crear scripts para capturarlas otra vez.
- Ejecutar esos scripts contra el propio incidente.
- Ver si realmente ayudan a detectar o explicar lo que pasó.
- Ajustarlos.
- Dejar el runbook mejor que antes.
Esto parece obvio, pero cambia mucho la relación con la operación.
Antes, cada incidente podía sentirse como una investigación casi artesanal: abrir consola, buscar entorno, bajar logs, mirar métricas, saltar entre capas, reconstruir una línea temporal y confiar en no olvidar nada importante.
Ahora el objetivo es distinto. Resolver el incidente importa, claro. Pero también importa que el siguiente análisis empiece un escalón más arriba.
No se trata de crear una plataforma enorme. Se trata de acumular pequeñas herramientas que saben mirar lo que ya aprendimos que importa.
La unidad útil es el bundle
Una de las piezas más valiosas es el bundle de incidente.
No una respuesta suelta.
No una captura mental.
Un paquete local con la foto relevante: estado del entorno, eventos recientes, versión desplegada, logs de aplicación, logs de infraestructura, métricas, errores destacados y un resumen legible.
Con eso Codex puede trabajar mucho mejor.
Puede buscar offline. Puede parsear JSON. Puede comparar timestamps. Puede volver sobre la evidencia sin repetir llamadas. Puede explicar por qué cree que una hipótesis encaja y qué señal falta para confirmarla.
Y el equipo gana algo igual de importante: trazabilidad.
Una semana después puedes volver al paquete y entender qué se vio. Puedes comparar incidentes. Puedes mejorar el script. Puedes convertir un patrón en una alerta o una mitigación.
La IA no responde mejor solo porque sea lista. Responde mejor porque le has dado una superficie de trabajo estable.
Read-only primero
Hay un guardrail que para mí es básico:
diagnóstico primero, mutación explícita después.
Codex puede mirar, descargar, comparar, resumir, correlacionar y proponer opciones. Pero cambiar configuración, desplegar, hacer rollback o tocar datos requiere una intención explícita.
Esto no es miedo a la automatización. Es operación responsable.
En AWS, muchas acciones tienen efectos laterales reales: coste, disponibilidad, tráfico, estados transitorios. Por eso el modo read-only es tan potente. Permite ganar velocidad sin convertir cada diagnóstico en un riesgo.
Primero capturas evidencia. Luego entiendes. Después decides. Y solo entonces actúas.
El multiplicador
Para alguien que ya domina AWS profundamente, Codex puede ser una aceleración.
Para alguien como yo, que lo ha aprendido por necesidad, es algo más fuerte: desbloquea conocimiento que no sabía ni que tenía que pedir.
La diferencia entre estas dos frases es enorme:
mira los logs.
Y:
captura una ventana, cruza señales de infraestructura y aplicación, dime qué hipótesis explica mejor el patrón y proponme cómo harías este análisis repetible.
La segunda frase no sale de la nada. Sale de haber construido un sistema donde Codex sabe qué significa “mirar bien”.
Ese es el multiplicador real. No hacer más rápido lo que yo ya sabía hacer, sino ampliar el espacio de cosas que puedo intentar con criterio.
La lección
El gran descubrimiento no fue darle acceso a AWS a Codex.
Fue usar cada incidente para construir una forma más robusta de mirar el siguiente.
Análisis. Script. Validación contra el propio caso. Ajuste. Runbook. Repetición.
Poco a poco, esa rueda convierte experiencia suelta en sistema operativo.
Dicho en limpio:
un agente se vuelve mucho más potente cuando no le pides que improvise la operación, sino que le das un ciclo para convertir intención en evidencia, evidencia en hipótesis e hipótesis en tooling reutilizable.
Para mí, ese ha sido el salto: pasar de “no sé exactamente qué mirar en AWS” a “puedo construir una forma fiable de mirarlo, validarla con incidentes reales y mejorarla con cada vuelta”.