Introducción
Durante mucho tiempo, para crecer en tecnología parecía alcanzar con una premisa bastante clara: escribir buen código.
Entender un requerimiento, entrar a un repositorio, resolver una historia de usuario, cumplir un sprint y entregar. Para muchos developers, esa fue durante años la forma natural de construir identidad profesional.
Yo también empecé ahí.
Arranqué como software developer. Mi lugar era el código. Mi forma de entender los problemas era técnica. Si había un requerimiento claro, un equipo alineado y un entorno de desarrollo disponible, el resto era trabajar, resolver y entregar.
Hoy estoy del otro lado del mostrador, como CEO de una empresa de tecnología. Pero hay algo que no cambió: sigo pensando como dev. Solo que ahora tengo una responsabilidad distinta.
Ya no se trata únicamente de resolver bien un problema técnico. Se trata de ayudar a que los equipos no se queden atrás en una ola que está cambiando la forma en que diseñamos, construimos y operamos software: Generative AI y AI Transformation.
Y en ese contexto, hay una conclusión que cada vez veo con más claridad: solo saber programar ya no alcanza.
No porque el código haya dejado de importar. Al contrario. Sigue siendo una capacidad central.
Pero el juego cambió de nivel.
De entender requerimientos a entender negocio
Uno de los cambios más importantes para los equipos de desarrollo es dejar de mirar el trabajo solo como una lista de requerimientos.
Un requerimiento puede decir qué hay que construir. Pero no siempre explica para qué existe eso, qué problema de fondo intenta resolver, qué decisión habilita o qué impacto espera generar en la operación.
Ahí aparece una diferencia clave.
Un developer que solo interpreta el requerimiento puede entregar una funcionalidad correcta desde lo técnico. Pero un developer que entiende el negocio puede detectar si esa funcionalidad realmente resuelve el problema, si está atacando una causa o apenas un síntoma.
Con Generative AI esto se vuelve todavía más importante.
Porque una solución basada en IA no funciona bien solamente porque use un modelo avanzado. Funciona bien cuando está conectada con un objetivo de negocio claro, con un flujo real de trabajo y con criterios definidos para medir si aporta valor.
Sin contexto de negocio, la IA puede convertirse en un juguete caro: interesante para mostrar, pero difícil de sostener en producción o de justificar frente a la operación.
Por eso, el rol técnico necesita ampliar su mirada. Ya no alcanza con preguntar “¿qué hay que programar?”. También hay que preguntar:
¿Qué decisión queremos mejorar? ¿Qué proceso queremos simplificar? ¿Qué fricción queremos reducir? ¿Qué impacto esperamos generar?
Ese cambio de pregunta modifica completamente el tipo de solución que se diseña.
Los datos ya no son un tema ajeno al desarrollo
Otro punto que incomoda, pero que se volvió inevitable, es el mundo de los datos.
Durante años, muchos equipos de desarrollo podían construir sistemas sin involucrarse demasiado en la calidad, el origen o la gobernanza de los datos. El dato estaba ahí. Alguien lo cargaba, alguien lo mantenía, alguien lo explotaba después.
Con IA, esa separación empieza a romperse.
Si una aplicación incorpora agentes, automatizaciones inteligentes o modelos generativos, la calidad del resultado depende directamente de los datos que alimentan al sistema.
De dónde salen. Quién los mantiene. Qué tan actualizados están. Qué permisos tienen. Qué tan confiables son. Qué pasa cuando están incompletos o mal estructurados.
Un agente de IA conectado a datos pobres no resuelve el problema. Muchas veces lo amplifica.
Es como darle mucha velocidad a un proceso mal orientado. El sistema puede responder más rápido, pero no necesariamente mejor.
Por eso, los equipos de desarrollo necesitan involucrarse más en la conversación sobre datos. No para que todos se conviertan en especialistas en data engineering, sino para que entiendan cómo impactan los datos en la calidad, la seguridad y la confiabilidad de lo que construyen.
En la práctica, esto implica hacer preguntas que antes quizás parecían fuera del rol:
¿Este dato es confiable? ¿Quién es responsable de mantenerlo? ¿Hay trazabilidad? ¿El sistema puede explicar de dónde salió una respuesta? ¿Qué pasa si el dato cambia? ¿Qué pasa si el modelo interpreta mal la información?
En un mundo donde cada vez más decisiones pueden estar asistidas por IA, esas preguntas dejan de ser accesorias. Se vuelven parte del diseño técnico responsable.
MLOps: el nuevo runtime de muchas soluciones
El tercer cambio tiene que ver con MLOps.
No creo que todos los developers tengan que convertirse en machine learning engineers. Pero sí creo que cada vez más equipos técnicos necesitan entender lo esencial de cómo viven, evolucionan y se monitorean las soluciones basadas en modelos.
Porque cuando incorporamos IA, el software deja de ser solamente código desplegado en un ambiente.
También aparecen modelos, versiones, pipelines, datasets, métricas, monitoreo, retraining, evaluación de resultados y control de desviaciones.
En otras palabras, aparece una nueva capa operativa.
Así como durante años aprendimos a pensar en logs, ambientes, despliegues, errores, performance y observabilidad, ahora necesitamos sumar conceptos propios del ciclo de vida de modelos y agentes.
No se trata de aprender MLOps como una moda. Se trata de entender que muchas soluciones inteligentes no terminan cuando se despliegan.
Empiezan a vivir ahí.
Un modelo puede degradarse. Un prompt puede dejar de funcionar bien cuando cambia el contexto. Una fuente de datos puede perder calidad. Un agente puede ejecutar acciones que necesitan límites, permisos y auditoría. Una automatización puede generar resultados correctos en pruebas, pero riesgosos en operación real.
Por eso, la mentalidad de producción también tiene que evolucionar.
Antes nos preguntábamos: “¿El sistema funciona?”. Ahora también necesitamos preguntar: “¿El sistema sigue decidiendo bien? ¿Sigue respondiendo con calidad? ¿Sigue operando dentro de los límites que definimos?”.
Ese es un cambio profundo para los equipos de desarrollo.
La actitud frente al cambio también es una habilidad técnica
Hay una frase que puede parecer defensiva, pero que hoy se volvió peligrosa: “yo solo programo”.
Durante mucho tiempo pudo sonar como una forma de foco. Hoy puede convertirse en una forma de achicarse.
La transformación que trae la IA no pide que todos sepan todo. Pero sí exige una actitud distinta frente al aprendizaje.
Más curiosidad. Más apertura. Más diálogo entre desarrollo, data, producto y negocio. Más capacidad de entender el sistema completo.
Porque las soluciones con IA no nacen solo en el código. Nacen en la intersección entre una necesidad de negocio, una fuente de datos, un proceso operativo, una experiencia de usuario y una arquitectura tecnológica capaz de sostener todo eso.
El developer que se queda únicamente en la ejecución técnica corre el riesgo de perder protagonismo.
En cambio, quien se anima a entender el contexto completo se vuelve mucho más valioso. No porque deje de ser técnico, sino porque empieza a usar su criterio técnico para diseñar mejores formas de trabajar con IA.
Ese es el punto central.
No se trata de abandonar el código. Se trata de dejar de ver el código como el único lugar donde se genera valor.
Cierre
Yo no dejé de ser técnico.
Pero entendí que, si quiero cuidar el futuro de la empresa y de los equipos, tengo que empujarlos —y empujarme— a jugar este partido completo.
Generative AI, MLOps, datos, negocio y actitud frente al cambio ya no son conversaciones separadas. Empiezan a formar parte del mismo sistema.
No espero que un equipo de desarrollo se convierta de un día para el otro en un grupo de gurús de IA. Pero sí creo que necesitamos un cambio de postura.
Menos miedo a salir de la zona cómoda del código. Más curiosidad por entender negocio, datos y operaciones. Más colaboración entre áreas. Más responsabilidad sobre el impacto real de lo que construimos.
La diferencia hacia adelante no va a estar entre quienes programan y quienes no programan.
Va a estar entre quienes solo entregan features y quienes entienden cómo diseñar, desde lo técnico, la forma en que una organización adopta IA de manera responsable, útil y sostenible.