⏱ Tiempo estimado: 20–25 minutos
🎯 Rama / Perfil: Backend developers / DevOps / SRE
🧠 Conocimiento previo necesario: GitHub, Pull Requests, tests y CI básico.
💡 ¿Qué vas a lograr? Construirás el patrón de CI Failure → Devin → diagnóstico → corrección → nuevo commit, evitando que un fallo de CI tenga que ser investigado manualmente desde cero.
Este patrón ya aparece en las automatizaciones actuales de Devin: por ejemplo, la plantilla de CircleCI se activa ante un check_run fallido, obtiene contexto de la ejecución mediante MCP y puede trabajar sobre la misma rama.
🛠 Lo que necesitas antes de empezar
📋 Pasos
Paso 1 — Asegúrate de tener CI
Tu proyecto debe poder hacer algo parecido a:
push
↓
GitHub Actions
↓
instalar dependencias
↓
tests
↓
PASS / FAIL
Si todo pasa, perfecto.
Ahora necesitas provocar un fallo controlado.
Paso 2 — Crea un fallo intencional
Por ejemplo, cambia temporalmente:
assert calculate_total(100, 20) == 130
cuando realmente debería ser:
assert calculate_total(100, 20) == 120
Haz commit y push.
Ahora GitHub Actions debería producir:
❌ Tests failed
Paso 3 — Configura la automatización
En Devin:
Automations → Templates
Busca una plantilla relacionada con:
CI Failure Fixer
La documentación oficial de Devin incluye este tipo de automatización dentro de sus templates de CI/CD.
🔗 Plantillas de automatización de Devin
Paso 4 — Define reglas de seguridad
Este paso es más importante que conseguir que "funcione".
Configura conceptualmente estas reglas:
SI CI falla
↓
Devin investiga
↓
Identifica causa
↓
Modifica código
↓
Ejecuta tests
↓
SI tests pasan
→ commit
SI tests fallan
→ NO seguir modificando indefinidamente
→ informar
También establece:
❌ No modificar secrets
❌ No modificar infraestructura
❌ No hacer merge
❌ No modificar main directamente
✅ Trabajar sobre la rama del PR
Paso 5 — Provoca nuevamente el fallo
Ahora vuelve a introducir el error.
El flujo debería ser aproximadamente:
PR
↓
CI
↓
❌ Failure
↓
Devin
↓
lee logs/contexto
↓
investiga
↓
modifica código
↓
ejecuta tests
↓
commit
↓
CI nuevamente
El objetivo no es que Devin "adivine" la solución.
El objetivo es que pueda cerrar el ciclo de feedback de CI.
✅ Resultado esperado
Tendrás un flujo donde un fallo de CI puede iniciar automáticamente una investigación de Devin y producir una corrección sobre la rama correspondiente.
Esto transforma:
"CI falló, ahora tengo que investigar."
en:
"CI falló, Devin ya está investigándolo."
La supervisión humana sigue siendo importante: el hecho de que un agente pueda corregir un fallo no significa que la corrección sea necesariamente la solución arquitectónica adecuada.
🔥 Tu reto
Provoca tres tipos de errores:
1. Test roto
2. Error de lint
3. Error de dependencia
Observa:
¿Cuál puede resolver Devin automáticamente?
¿Cuál requiere contexto que no está en el log?
¿Cuál debería escalarse a un humano?
Esa comparación te enseñará más sobre agentes de programación que simplemente verlos generar código.
📚 Recursos para ir más lejos
- GitHub Actions — CI/CD de GitHub.
- Devin Automation Templates — automatizaciones oficiales.
- Devin API — integración programática.
Curso de Devin AI
COMPARTE ESTE ARTÍCULO Y MUESTRA LO QUE APRENDISTE
