🤖 Agentes de IA en DevOps

Lo Que la IA NO Puede Hacer en DevOps: Limitaciones Reales

📋 Contexto

Después de 6 meses usando IA intensivamente, he visto tanto sus fortalezas como sus debilidades. Este post es el contrapeso necesario a todo el entusiasmo: las cosas que la IA hace mal, los riesgos reales, y por qué tu experiencia sigue siendo irremplazable.

🚫 Limitación 1: No Entiende Tu Contexto de Negocio

El Problema

IA te da soluciones técnicamente correctas, pero sin entender:

• Presupuesto disponible
• Políticas de la empresa
• Compliance y regulaciones de tu industria
• Deuda técnica existente
• Cultura del equipo

Ejemplo Real

Yo: "¿Cómo mejorar la disponibilidad de mi app?"

IA: "Implementa multi-region en AWS con failover automático,
RDS Multi-AZ, CloudFront global, y Route53 health checks"

Reality check:
- Presupuesto: $500/mes (la solución cuesta $5000/mes)
- SLA necesario: 99% (no 99.99%)
- Equipo: 1 persona (yo)
- Tiempo: necesito algo en 2 semanas, no 3 meses

La solución es perfecta técnicamente, pero inviable en mi contexto.

🚫 Limitación 2: Hallucinations (Inventa Cosas)

Ejemplos Reales que Vi

• APIs inexistentes: "Usa aws ec2 get-instance-metrics" (no existe)
• Flags incorrectos: Sugiere --no-verify-ssl cuando es --no-verify
• Versiones mezcladas: Mezcla sintaxis de Docker Compose v2 y v3
• Packages que no existen: "Instala python3-awstools" (inventado)

Caso Real: Incidente Evitado

IA sugirió:
aws ec2 delete-snapshots --older-than 30 --confirm

Yo ejecuté:
aws ec2 help | grep delete-snapshots
→ Ese comando no existe

Si hubiera confiado ciegamente, habría pegado un comando
que no hace nada (en el mejor caso) o causa un error
que interrumpe mi script.

🚫 Limitación 3: No Puede Ejecutar ni Validar Código

IA te da código que "se ve bien" pero no puede garantizar que funcione:

• No detecta typos en nombres de variables
• No valida que las dependencias estén instaladas
• No puede testear contra tu ambiente real
• No detecta race conditions o issues de concurrencia

Ejemplo

IA generó este script bash que "se ve bien":

#!/bin/bash
INSTANCE_ID=$(aws ec2 describe-instances \
    --filters "Name=tag:Name,Values=$INSTANCE_NAME" \
    --query 'Reservations[0].Instances[0].InstanceId' \
    --output text)

aws ec2 stop-instances --instance-ids $INSTANCE_ID

Problemas reales:
1. ¿Qué pasa si no encuentra instancia? → $INSTANCE_ID está vacío
2. Falta validación de variable $INSTANCE_NAME
3. No hay error handling
4. Si hay múltiples instancias con ese nombre, solo toma la primera

IA no detecta estos edge cases porque no puede ejecutar el código.

🚫 Limitación 4: Información Desactualizada

El conocimiento de IA tiene un "cutoff date". Ejemplo:

• AWS lanza nuevo tipo de instancia (graviton4) → IA no lo conoce
• Kubernetes cambia API en v1.29 → IA sugiere sintaxis deprecada
• Herramienta nueva (2024) → IA nunca la vio

🚫 Limitación 5: Malas Recomendaciones de Seguridad

Errores Comunes de IA

IA sugiere:
1. "Usa chmod 777 para solucionar permisos"
2. "Disable SSL verification si falla el certificado"
3. "Hardcodea la password temporalmente"
4. "Usa sudo sin validación"
5. "Expone puerto directamente sin firewall para testear"

NUNCA sigas estas sugerencias sin entender las implicaciones.

Caso Real: Pull Request Rechazado

IA generó un script de deployment con:

export AWS_ACCESS_KEY_ID="AKIA..."
export AWS_SECRET_ACCESS_KEY="..."

Code review humano:
"¿Estás loco? Esto commitea credenciales en Git"

IA no entiende:
- Git history es permanente
- Secrets en repos son una vulnerabilidad crítica
- Mejores prácticas de secrets management

🚫 Limitación 6: No Puede Debuggear Incidentes Complejos

IA es útil para debugging rutinario, pero falla en:

• Issues intermitentes: "A veces falla, a veces no"
• Race conditions: Requiere entender flujo temporal complejo
• Issues de infraestructura: Problemas de red, latencia, DNS
• Performance degradation: "Antes era rápido, ahora lento"

Ejemplo Real

Incidente: App lenta cada martes a las 3 AM

IA sugiere:
- Revisar logs (ya lo hice, nada obvio)
- Aumentar recursos (no es el problema)
- Optimizar queries (ya están optimizadas)

Root cause real (encontrado por humano con experiencia):
- Backup automático de DB se ejecuta martes 3 AM
- Locks en tabla principal durante backup
- No se ve en logs de app, solo en logs de DB

IA no tiene la intuición para conectar estos puntos.

🚫 Limitación 7: No Entiende Trade-offs

IA sugiere "la mejor práctica" sin entender que todo tiene trade-offs:

Sugerencia de IA	Trade-off No Mencionado
"Usa Kubernetes"	Complejidad, curva de aprendizaje, overhead
"Implementa microservices"	Latencia de red, complejidad debugging, overhead operativo
"Agrega caching en Redis"	Cache invalidation, consistencia, nueva pieza que mantener
"Multi-region setup"	Costo 3-5x mayor, complejidad deployment

🚫 Limitación 8: No Puede Tomar Decisiones de Arquitectura

Decisiones que requieren juicio humano:

• Build vs Buy: ¿Desarrollo in-house o uso SaaS?
• Timing: ¿Migro ahora o espero?
• Priorización: ¿Qué feature desarrollo primero?
• Risk assessment: ¿Vale la pena el riesgo de esta migración?

🚫 Limitación 9: No Aprende de Tus Errores

Cada conversación es independiente (en la mayoría de los casos):

• No recuerda que ya probaste esa solución y no funcionó
• No aprende de tus preferencias
• No se adapta a tu stack específico automáticamente

🚫 Limitación 10: Puede Generar Código Inseguro o Ineficiente

Ejemplos reales de código que IA generó:

1. Loop ineficiente:
for i in $(aws ec2 describe-instances ...); do
    # Llama API una vez por instancia (n queries)
done
# Debería: Una query, parsear resultado local

2. Sin rate limiting:
while true; do
    aws s3 ls  # Sin sleep, puede causar throttling
done

3. SQL injection vulnerable:
query="SELECT * FROM users WHERE name='$USER_INPUT'"
# Falta sanitización

4. Regex con ReDoS vulnerability:
grep -E '(a+)+$' file.txt  # Puede causar DoS

🚫 Limitación 11: Riesgo de Propiedad Intelectual y Exposición de Secretos

El Problema Crítico

Cuando pegas código de tu empresa en ChatGPT, Claude, o cualquier IA pública, estás potencialmente:

• Violando NDAs: Tu contrato laboral probablemente prohíbe compartir código propietario
• Exponiendo secretos comerciales: Lógica de negocio única, algoritmos propietarios
• Filtrando arquitectura: Estructura interna de sistemas críticos
• Revelando vulnerabilidades: Bugs o debilidades de seguridad de tu empresa

Caso Real: Developer Despedido

Developer pega en ChatGPT:
"Tengo este código de nuestra API de pagos que da error..."
[código completo con lógica de procesamiento de tarjetas]

Problema:
1. Violó NDA de la empresa
2. Expuso lógica propietaria de procesamiento de pagos
3. Reveló nombres de variables/funciones internas
4. Potencial brecha de compliance (PCI-DSS)

Resultado: Despido inmediato + posible demanda legal

Lo Que Muchos No Saben

Según los términos de servicio de la mayoría de IAs públicas:

• Tu input puede ser usado para entrenar futuros modelos
• Empleados de la empresa pueden revisar conversaciones para QA
• Puede haber obligaciones legales de reportar cierto contenido
• Algunos países tienen leyes de retención de datos

🚫 Limitación 12: El "Impuesto de Revisión" - Costo Oculto

La Ilusión de Productividad

IA genera código en 30 segundos. Suena genial, ¿verdad?

El costo oculto: Revisar ese código para asegurar que no tiene race conditions, edge cases sin manejar, o errores sutiles puede tomar MÁS tiempo que escribirlo desde cero.

Ejemplo Real: El Script de Migración

IA generó script de migración de DB en 1 minuto:
"Script perfecto!" - pensé

Tiempo de revisión:
- 15 min: Leer y entender qué hace
- 10 min: Identificar que no maneja NULL values
- 15 min: Encontrar que asume orden de operaciones incorrecto
- 20 min: Descubrir que no es idempotente (falla si lo corres 2 veces)
- 30 min: Testear con datos reales
- 20 min: Agregar error handling que falta
- 10 min: Documentar lo que cambié

Total: 2 horas de "revisión"

Si lo hubiera escrito yo desde cero con el patrón que conozco:
45 minutos + 15 minutos de testing = 1 hora

Ahorro real: NEGATIVO (-1 hora)

¿Cuándo el "Impuesto de Revisión" es Alto?

Escenario	Costo de Revisión	Mejor Opción
Código crítico (pagos, auth)	MUY ALTO (2-3x)	Escribir desde cero
Código con concurrencia	ALTO (1.5-2x)	Escribir desde cero
Código en tu stack habitual	MEDIO (1x)	Depende
Boilerplate / templates	BAJO (0.3x)	Usa IA
Tech nueva que no conoces	BAJO (0.5x)	Usa IA

Lo Que Los Managers No Entienden

Manager: "Con IA, el equipo debería ser 2x más productivo"

Reality check:

• IA genera código rápido, pero SIN garantía de calidad
• Code review de código de IA toma 50-100% más tiempo que de humano
• Debugging de bugs introducidos por IA puede tomar días
• Refactoring posterior porque "funcionaba pero era malo" es costoso

La Métrica Correcta

❌ Métrica incorrecta: "Líneas de código generadas"
✅ Métrica correcta: "Tiempo desde tarea asignada hasta código productivo y confiable"

Ejemplo real:
- Con IA: 1 min generación + 2 horas revisión = 2h 1min
- Sin IA: 1 hora escribiendo con patrones conocidos = 1h

Winner: Sin IA (en este caso)

El Costo de Bugs No Detectados

El peor escenario: El código de IA "funcionaba" en testing, pero:

• Tenía un race condition que solo aparece bajo carga
• Fallaba en edge case que nadie testeó
• Tenía memory leak sutil
• No manejaba correctamente reintentos

Costo real: Incidente productivo + horas de debugging + reputación dañada + rollback de emergencia

✅ Entonces, ¿Cuándo SÍ Usar IA?

IA es excelente para:

• ✅ Boilerplate code (estructura básica)
• ✅ Explicar errores comunes
• ✅ Generar documentación draft
• ✅ Troubleshooting de problemas estándar
• ✅ Aprender nuevas tecnologías
• ✅ Refactoring de código existente
• ✅ Generar test cases

❌ Cuándo NO Usar (o Usar con Extrema Precaución)

• ❌ Código propietario de tu empresa (riesgo legal/NDA)
• ❌ Decisiones de arquitectura críticas
• ❌ Configuración de seguridad
• ❌ Debugging de incidentes productivos complejos
• ❌ Código que maneja dinero o datos sensibles
• ❌ Políticas de IAM en AWS
• ❌ Código con concurrencia/race conditions
• ❌ Disaster recovery procedures
• ❌ Compliance y regulaciones
• ❌ Cuando ya conoces bien el patrón a usar (el impuesto de revisión es alto)

📝 Checklist: Uso Responsable de IA

ANTES de compartir código con IA:

• ☐ ¿Es código propietario de mi empresa? (Si sí → NO compartir)
• ☐ ¿Contiene nombres reales de servidores/dominios internos? (Cambiar a ficticios)
• ☐ ¿Tiene datos sensibles de clientes? (Remover completamente)
• ☐ ¿Mi NDA me permite compartir esto? (Si no estás seguro → NO compartir)
• ☐ ¿Consultaría esto con Security/Legal? (Si sí → Consulta primero)

ANTES de usar código/configs generados por IA:

• ☐ Revisé línea por línea (no copiar/pegar ciego)
• ☐ Entiendo qué hace cada parte
• ☐ Medí si revisar esto toma menos tiempo que escribirlo yo
• ☐ Validé sintaxis con --dry-run o en ambiente de test
• ☐ Busqué en docs oficiales para confirmar
• ☐ Consideré edge cases y race conditions
• ☐ Agregué error handling si falta
• ☐ Verifiqué que no hay secrets hardcodeados
• ☐ Evalué impacto si algo sale mal
• ☐ Testé en ambiente no productivo primero
• ☐ Code review por humano si es código crítico

💭 Mi Postura Final

IA es una herramienta increíblemente poderosa que me hace 40% más productivo. Pero es exactamente eso: una herramienta.

IA no reemplaza:

• Tu experiencia y juicio
• Tu entendimiento del contexto de negocio
• Tu intuición al debuggear
• Tu capacidad de evaluar trade-offs
• Tu responsabilidad por el código que produces

🎯 Balance Correcto

Usa IA para:

• 🚀 Acelerar lo rutinario
• 📚 Aprender más rápido
• 💡 Generar ideas y alternativas
• 🔍 Primera línea de debugging

Confía en ti mismo para:

• 🎯 Decisiones críticas
• 🔒 Seguridad
• 🏗️ Arquitectura
• 🚨 Incidentes de producción

💭 Conclusión

No te creas el hype de "IA reemplazará a los DevOps". IA potencia a buenos DevOps, pero no reemplaza la experiencia, el juicio, y la responsabilidad.

Usa IA con inteligencia. Conoce sus limitaciones. Verifica su trabajo. Y mantén tu cerebro encendido.