⚡ Mapea los eventos que activan agentes
El flujo básico de cualquier automatización siempre es el mismo: evento → clasificación → selección del agente → ejecución → validación → decisión → entrega. Empezar por el evento evita el error común de construir un robot sin un disparador claro.
Cómo leer: solo el núcleo en cian es realmente automático. Clasificar y decidir siguen siendo tareas de gobernanza — tuya o de una regla tuya. Automatizar el núcleo es barato; automatizar los extremos es donde los equipos salen perjudicados.
📋 Eventos que vale la pena automatizar
Disparador claro
Sin él no hay automatización
Clasificar
No todos los eventos son iguales
Validar
Siempre antes de decidir
Decisión
Tiene responsable y criterio
🔗 Integra con issues, repositorios y pipelines
La automatización debe estar donde ya se realiza el trabajo. Si el resultado del agente aparece en un chat paralelo, nadie lo revisa ni le exige resultados, y la automatización muere por desuso, no por defecto.
✓ Integración que funciona
- ✓El resultado llega como pull request, con un diff revisable
- ✓El agente tiene identidad propia (se puede filtrar y auditar)
- ✓El PR referencia el evento que lo originó
- ✓La evidencia (logs, pruebas) se adjunta, no se resume
✗ Integración que se queda en nada
- ✗Salida en un canal de chat que nadie sigue
- ✗Hacer push directamente a la rama principal
- ✗Agente que usa la credencial personal de alguien
- ✗No hay rastro del evento que disparó el cambio
El PR es la superficie
Dónde existe la revisión
Identidad
Del agente, no tuya
Rastro
Evento → cambio
Evidencia
Adjunta, no narrada
🔧 Automatiza la corrección de fallas de CI
Es el mejor caso para empezar: el activador es objetivo (el pipeline falló), el verificador ya existe (el propio CI) y el resultado es reversible (un PR que no tienes que aceptar).
🧪 Ejercicio copiable — agente que investiga un fallo de CI
Objetivo: transformar un registro de fallas en un diagnóstico y una propuesta con evidencia. Toma una falla real de tu CI y pega el siguiente prompt en el agente, con el repositorio abierto.
Contexto: o pipeline falhou. Log completo abaixo. <cole aqui o log da falha> Faça, nesta ordem: 1. identifique a falha REAL (a primeira causa, não o último erro impresso); 2. diga se é: (a) bug no código, (b) teste instável, (c) ambiente/infra, (d) dependência — e qual evidência do log sustenta isso; 3. reproduza localmente com <comando de teste> e cole a saída real; 4. só se for (a): implemente a menor correção e rode os testes de novo; 5. se for (b), (c) ou (d): NÃO corrija — descreva o problema e pare. Restrições: - não altere testes existentes; - não adicione dependências; - não faça push na branch principal; deixe tudo na branch atual.
Cómo verificar: la clasificación del paso 2 es lo que importa. Si el agente llamó "error en el código" a una falla de red intermitente, tu automatización todavía no puede ejecutarse sin supervisión, y acabas de descubrirlo gratis.
💡 Consejo práctico
La prueba inestable es el enemigo silencioso de la automatización: enseña al agente (y al equipo) a tratar el rojo como ruido. Antes de automatizar la corrección de CI, elimina o aísla las pruebas que fallan por sí solas.
Causa raíz
No es el último error
Clasificar
Antes de corregir
Inestable
Cuarentena, no reintento
Propuesta
PR, nunca push directo
📦 Gestiona las dependencias y las vulnerabilidades
Actualizar dependencias es un trabajo recurrente, tedioso y bien definido: el perfil ideal para automatizar cuanto antes. Lo que diferencia una buena automatización de un robot molesto es la evidencia que adjunta.
Lee el changelog antes de subir la versión
El agente resume lo que cambió entre las versiones y destaca los cambios incompatibles declarados. Sin eso, actualizar es apostar.
Ajustar el código roto, una dependencia por PR
Los PR con una dependencia cada uno se pueden revisar y revertir individualmente. Un PR de «actualizar todo» es imposible de revisar por construcción.
Probar con tests y adjuntar la salida
La suite completa se ejecuta contra la nueva versión y la salida real se incluye en el cuerpo del PR. Sin evidencia, la actualización no es una propuesta: es una sugerencia.
Changelog
Lectura obligatoria
Uno por PR
Revisión y rollback
Prueba
Salida real adjunta
CVE crítica
Prioridad, no cola
🚨 Usa agentes en el análisis de incidentes
En los primeros minutos de un incidente, el cuello de botella es reunir información: logs de varios servicios, cambios recientes, correlación de horarios. Es exactamente donde un agente ayuda mucho, y mitigar por su cuenta en producción es exactamente donde estorba.
🧭 Diagnóstico inicial automático
- •Recopilar logs del período y agruparlos por tipo de error.
- •Revisar los deploys, las feature flags y las migraciones de las últimas horas.
- •Correlaciona el inicio del síntoma con el cambio más cercano.
- •Presentar hipótesis ordenadas, cada una con la evidencia que la respalda.
- •Preserva las evidencias antes de que la rotación de logs las borre.
⚠️ Atención
Durante un incidente, el agente propone — quien aplica es una persona. Una mitigación automática equivocada en medio de una crisis convierte un problema en dos y destruye la cronología que necesita el análisis posterior.
Recopilar
Es el cuello de botella real
Correlacionar
Síntoma × cambio
Conservar
Antes de modificar
No mitigar
Solo, en producción
⚖️ Decide qué automatizar y qué requiere aprobación
No todas las tareas deben ser totalmente autónomas. Los cambios en producción, bases de datos, infraestructura, permisos y seguridad necesitan controles adicionales, siempre.
La matriz de decisión en dos preguntas
| reversível | irreversível
--------------------|-------------------|---------------------------
verificável | AUTOMATIZE | agente propõe, humano aplica
não verificável | agente rascunha, | NÃO AUTOMATIZE
| humano revisa |
La frecuencia viene después: dentro del cuadrante "automatiza", empieza por lo que ocurre todas las semanas.
Verificación rápida: ¿cuál de estas es la mejor primera automatización para un equipo que está empezando?
Reversible
Primer criterio
Verificable
Segundo criterio
Frecuente
Define el orden
Responsable
La automatización sin responsable se deteriora
📌 Resumen del módulo
Próximo módulo:
3.2 - Code Review con IA: por qué quien implementa no puede ser quien revisa.