No le tengas miedo a la IA, estudia los fundamentos
La IA no te va a sustituir. La falta de fundamentos, sí.
Cada semana aparece un post nuevo en LinkedIn o “Insta” diciendo que “la IA va a acabar con el empleo de sysadmin” o que “la infra va a ser toda gestionada por agentes autónomos en dos años”. La gente de redes se pone nerviosa. El equipo de cloud queda ansioso. Y quien trabaja con sistemas operativos empieza a cuestionar si debería haber estudiado Derecho o Medicina. Yo mismo, hace algún tiempo, anduve un poco asustado con todo esto, pero ahora puedo decir:
Calma. Calma, joven. Calma, respira, respira y tranquilízate.
La verdad es más simple y, al mismo tiempo, más exigente de lo que sugiere el hype. La IA no elimina la necesidad de conocimiento técnico. En realidad, amplifica la diferencia entre quien tiene fundamentos sólidos y quien solo sabe escribir prompts sin objetivo. Si entiendes lo que está debajo del capó, la IA se vuelve una herramienta bastante poderosa. Si no entiendes, se vuelve un generador de problemas a escala industrial y te va a enredar educadamente.
En este post, quiero conversar sobre por qué los fundamentos técnicos de un profesional DevOps nunca fueron tan importantes, cómo la IA cambia (y no cambia) el trabajo de infra, y qué creo que deberías estar estudiando.
El cuello de botella cambió de lugar
Antiguamente, el cuello de botella era la producción. Escribir un script de automatización, montar un template de infraestructura, documentar un runbook, etc., todo eso llevaba tiempo. La IA comprimió ese tiempo drásticamente. Hoy le pides un módulo Terraform al ChatGPT, Claude o cualquier otro asistente y escupe algo funcional en 30 segundos.
Pero aquí hay un punto importante. El cuello de botella se movió de la creación hacia la confianza, lo explico mejor.
¿El módulo Terraform compila? Probablemente sí. ¿Sigue las buenas prácticas de seguridad de tu entorno? Probablemente no. ¿Lida bien con los “IFs” y “ELSEs” de tu red? Probablemente no. ¿Respeta las políticas de compliance de tu organización? Probablemente no, por eso ya es otra conversación.
Es exactamente lo que sucede cuando una organización automatiza sin mejorar el sistema alrededor de la automatización. El trabajo llega más rápido, pero las filas de revisión de código explotan. Los entornos de prueba quedan inestables. Las decisiones de deploy quedan más difíciles porque la evidencia es incompleta.
La IA genera artefactos que parecen completos mientras cargan suposiciones ocultas, patrones inseguros o atajos arquitectónicos. ¿Quién va a identificar eso? Tú, el profesional que entiende los fundamentos.
Tu papel cambiará, pero no desaparecerá
Los profesionales de infra están migrando de “quien escribe el primer borrador” a “quien valida, integra y garantiza que funciona en producción”. Eso no es menos importante. Eso es más serio, tiene mucho más valor.
Vamos a pensar juntos nuestro día a día.
Un SRE ahora necesita decidir si el resumen de incidente generado por la IA coincide con la telemetría real.
Un ingeniero de cloud necesita evaluar si la arquitectura sugerida respeta los límites de costo, latencia y compliance.
Un analista de seguridad necesita juzgar si la remediación propuesta realmente reduce el riesgo o si es solo texto bonito.
El trabajo se volvió más colaborativo con la IA, pero la responsabilidad profesional permanece contigo. La IA no firma el postmortem. No responde a la auditoría. No se despierta a las 3h de la mañana cuando el cluster cae. Y no recibe el valor de las horas extras de guardia 😄.
La calidad de la salida de la IA depende directamente de la calidad del contexto que proporcionas. Prompt malo, documentación desactualizada, conocimiento arquitectónico incompleto… todo eso produce salida débil. Los equipos maduros tratan el contexto como un activo de ingeniería. Mantienen documentación actualizada, catálogos de servicio, contratos de interfaz y runbooks justamente porque eso mejora tanto el trabajo humano como el asistido por IA.
Qué estudiar ahora, de verdad
Si la IA amplifica a quien tiene fundamentos, la pregunta práctica es simple. ¿Cuáles fundamentos?
Independientemente del nivel en el que estés, existen fundamentos técnicos que son innegociables para quien trabaja con infraestructura, DevOps o SRE. Esa es la base que diferencia a quien usa IA como palanca de quien acepta cualquier salida sin cuestionar.
Networking de verdad. DNS, BGP, TCP/IP, segmentación, firewalls stateful vs stateless. La IA puede generar una ACL, pero si no entiendes el modelo de tráfico, vas a aceptar una regla que abre un agujero en la red.
Linux y sistemas operativos. Procesos, memoria, I/O, systemd, namespaces, cgroups. La base de todo lo que corre en contenedor y en cloud. Sin eso, eres rehén de abstracciones que no entiendes.
Seguridad aplicada. No necesitas ser pentester, pero entiende la superficie de ataque, el principio del menor privilegio, la gestión de secretos, el control de acceso. La IA puede generar código con credenciales hardcodeadas sin ningún remordimiento.
Observabilidad y telemetría. Métricas, logs, traces. Cómo instrumentar. Cómo correlacionar señales. Cómo distinguir ruido de señal real. Eso es lo que te permite confiar (o no) en lo que la IA produce.
CI/CD y automatización. Pipelines, pruebas, validación automatizada, policy as code. Ese es el sistema de control que garantiza que los artefactos generados por IA pasen por el mismo rigor que cualquier otro código.
Arquitectura de sistemas distribuidos. Resiliencia, consistencia eventual, circuit breakers, backpressure. La IA puede sugerir una arquitectura, pero decidir los trade-offs sigue siendo trabajo humano.
Visión crítica sobre tu papel como freno técnico
Hay una cosa de la que poca gente habla o que todavía estamos entendiendo. Los profesionales técnicos necesitan entrar en el proceso de adopción de IA con visión crítica. No se trata de estar en contra de la tecnología. Se trata de cuestionar técnicamente cómo se generan las cosas y bajo qué restricciones se aplican.
Sin frenos, la IA va a generar basura. Mucha basura. Y basura que parece código legítimo es peor que no tener nada, porque alguien va a necesitar revisar, probar, corregir y eventualmente limpiar el desorden en producción.
Piénsalo así. Si hoy un dev junior abre 15 PRs por día con código superficial, el equipo ya se queja de la carga de revisión. Ahora imagina una IA generando artefactos en volumen industrial, como Terraform modules, Dockerfiles, playbooks Ansible, políticas de IAM, todo sin ningún filtro de calidad antes de llegar a la fila de review. El resultado es sobrecarga en los revisores, fatiga de decisión e, inevitablemente, cosas malas pasando desapercibidas.
El profesional técnico necesita ser el contrapeso. Necesita preguntar.
- ¿Bajo qué premisas se generó esto? La IA no sabe que tu entorno tiene restricciones de red específicas, que existe un compliance regulatorio, o que aquel servicio tiene un SLA de 99.99%.
- ¿Qué falta aquí? ¿Rollback? ¿Monitoreo? ¿Tratamiento de error? La IA optimiza para completitud aparente, no para operabilidad real.
- ¿Esto escala? Un script que funciona con 10 registros puede explotar con 10 millones. La IA no prueba bajo carga del mundo real.
- ¿Quién es responsable cuando se rompa? Si nadie revisó críticamente, la responsabilidad se diluye, y la dilución de responsabilidad en producción es receta para incidente grave.
Rechazar salida de IA no es falla de adopción. Es madurez técnica. Los equipos que saben decir “esto no sirve” ahorran más tiempo que los equipos que se quedan puliendo sugerencias malas por horas.
Resumen
La IA no sustituye a quien tiene fundamentos. Amplifica la diferencia entre quien entiende lo que está haciendo y quien solo reproduce comandos. El cuello de botella del trabajo técnico salió de la producción y fue hacia la confianza. Generar artefactos se volvió trivial, pero validar, integrar y operar con seguridad sigue exigiendo gente competente.
Tu papel no desapareció. Cambió de forma. Dejaste de ser quien escribe el primer borrador para ser quien garantiza que el resultado final funciona en producción. Eso exige más conocimiento, no menos.
El mensaje es: revisa tus fundamentos, identifica dónde estás débil y usa la propia IA como herramienta de estudio.
Es incorrecto creer que la IA te va a sustituir. Es más incorrecto todavía quedarte parado mientras el estándar de exigencia sube; es bueno que lo sepas. Los fundamentos son tu diferencial competitivo, y nunca fueron tan valiosos.
¡Un abrazo!
¡Larga y próspera vida a todos!
Referencias
- https://infraascode.com.br/meu-amigo-robo/
- https://infraascode.com.br/linux-troubleshooting-com-chat-gpt/
Entre em contato:
NewsLetter - https://engineeringmanager.com.br/Linkdin - linkedin.com/in/leonardoml/
Twitter: @infraascode_br
Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!
|
|
