La era de la IA nativa: el nuevo paradigma que redefine el rol del programador

Poco a poco la adopción de la Inteligencia Artificial abandona el hype para convertirse en el motor de la transformación empresarial. En el ecosistema del desarrollo de software, esta tecnología está redefiniendo cómo operan las organizaciones. El mercado vive hoy un punto de inflexión decisivo. Deloitte encuestó a varias organizaciones en Estados Unidos, de las cuales un tercio está empezando a utilizar la IA para crear nuevos productos y servicios o reinventando procesos centrales o modelos de negocio. El gran desafío de la industria no es simplemente adoptar nuevas herramientas, sino cambiar por completo los paradigmas de trabajo tradicionales.

La verdadera revolución ya no reside únicamente en implementar IA generativa sobre estructuras antiguas, sino en alcanzar la «IA nativa». Este concepto representa el nivel de madurez más alto, donde las empresas modifican sus procesos desde la base en lugar de forzar la tecnología. Mediante la «agentización» y la orquestación, múltiples agentes artificiales pueden encargarse de tareas complejas simultáneamente. Esta metodología permite que el software deje de ser un recurso caro de construir, acelerando fuertemente los tiempos de lanzamiento.

Por eso, el rol del programador que únicamente escribía código está desapareciendo rápidamente. Ahora, los desarrolladores asumen funciones de editores bajo un modelo de «humano en el medio», supervisando la calidad y validando la arquitectura. Las nuevas competencias clave incluyen el diseño de sistemas escalables y la especificación de requerimientos. De hecho, dominar herramientas agénticas es hoy una precondición mucho más valorada que conocer un lenguaje de programación específico.

A pesar de sus beneficios, la transición enfrenta obstáculos. Empresas de sectores muy regulados, como la banca tradicional, muestran resistencia por el riesgo y la falta de tiempo para experimentar. Para superarlo, el liderazgo debe apostar por la capacitación constante. En En Contxto hablamos con Pablo Gamba, VP Technology Americas de intive, sobre cómo implementar la IA nativa y el futuro del desarrollo. 

Stiven: Hola, bienvenidos a En Contxto. Hoy estamos en un nuevo episodio de Inteligencia Artificial y me encuentro entonces con Pablo Gamba de intive. Pablo, bienvenido a En Contxto, y si nos puedes contar un poco sobre lo que haces dentro de la compañía y qué hacen desde intive.

Pablo: Bien, gracias Stiven por la invitación. Un gusto estar aquí. Bueno, intive es una compañía donde ofrecemos servicios de desarrollo de software y tecnología. Es una compañía global y estamos básicamente cubriendo la región de América y la región de EMEA. Ya tiene unos cuantos años, alrededor de 20 años en el mercado. Ofrecemos una diversidad de servicios de tecnología aplicados al desarrollo de software en distintas verticales de negocios, en lo que es Automotive, Fintech, Healthcare, Media, Technology, Communications y Retail. Contamos con un abanico de tecnología totalmente abarcativo en lo que es cualquier desarrollo de las plataformas que hoy en día estamos trabajando, que va desde lo que es todo desarrollo de frontend, desarrollo de backend, arquitecturas complejas, la parte de releasing y automating con DevOps, QA (Quality Assurance) y Software Engineering. Y sobre todo, continuamente, en los últimos años hemos estado trabajando con inteligencia artificial, lo cual despegó bastante hace tres años y abrió un poquito más el abanico y la apertura en cuanto a esos servicios con clientes alrededor del globo en ambas regiones. En mi caso, estoy a cargo del área de tecnología para la región de América, liderando los equipos de ingeniería y conectando el negocio de operaciones y tecnología a través del personal con el que estamos trabajando. Últimamente, digamos en los últimos dos años, mi foco está mucho en la transformación sobre la inteligencia artificial, en cómo está redefiniendo la forma en que construimos el software y operamos las organizaciones. Así que pongo mucho foco en esa disciplina y en toda la transformación que hemos hecho aquí, ayudando a nuestros clientes.

Stiven: Qué bueno, Pablo, ahí hablabas de algo súper interesante y es que vienen trabajando con la IA. Bueno, que se volvió popular, como mencionabas, hace tres años. Creo que es un buen punto de partida porque la IA no es nueva, ¿cierto? Lo que es nuevo, o que se volvió popular, es la IA generativa. De pronto, nos puedes explicar un poco sobre en qué consiste eso de que la IA realmente no es nueva.

Pablo: Bueno, hace ya varios años que comenzó todo. Con lo que era el manejo de grandes volúmenes de datos, big data y data science, se empezó a trabajar en el procesamiento de información para tomar decisiones y poder disponibilizar estos datos a las compañías. Todo eso fue madurando, digamos, dando un salto rápido hasta la llegada de los Large Language Models, a partir de los cuales se abrió una nueva posibilidad en la época en que se generaron los transformers. A partir de ahí, la IA hasta ese momento estaba un poco orientada hacia la generación de información basada en un gran volumen de datos y el procesamiento de los mismos. Ahora, lo que es la inteligencia artificial generativa ya permite mucha más funcionalidad y empieza a atrapar a todas las disciplinas y mercados. Gracias a los volúmenes de datos, todos esos modelos de lenguaje permitieron hacer aplicaciones sobre eso, con toda la automatización que estamos viendo hoy en día, y cómo nos está impactando y cambiando los paradigmas de trabajo bastante de fondo.

Stiven: Exacto. Y en esos mismos paradigmas que mencionas de fondo, surge un nuevo concepto y es la IA nativa, ¿cierto? ¿Cómo se diferencia y cómo llega ese nuevo concepto? ¿En qué consiste la IA nativa?

Pablo: Bien, para explicar la IA nativa, por ahí nos podemos posicionar un poquito más atrás sobre cómo llegamos a ella, ¿no? Hay distintos niveles de madurez; no necesariamente hoy hay una matriz estándar, pero a mi criterio podemos tener cuatro niveles. El nivel cero sería cuando arrancás y haces las primeras experimentaciones, permitiendo que en una compañía —ya sea de desarrollo de software o de operación— otorguemos licencias, experimentemos, empecemos a incursionar y obtengamos algunos tipos de mejoras individuales en el trabajo, como desempeñarse mejor, más rápido o con mejor calidad. Eso sería un nivel inicial. El segundo nivel es donde ya empezamos a ver cómo podemos estandarizar una práctica y tener algunas cosas definidas que podamos reutilizar entre equipos o entre pares. Sería un segundo nivel, pero aún sin un gobierno o un plan muy definido de evolución y escalabilidad, con lo cual la mejora sigue siendo mucha individualmente, pero colectivamente no es tanta. Luego, cuando llegamos al nivel 3, ya establecemos un gobierno, un liderazgo que tiene un plan y métricas impuestas por las cuales vamos a estar trabajando. Empezamos a pensar y a darnos cuenta de que aplicar IA a los procesos existentes no necesariamente es lo que nos va a dar ese rédito mayormente exponencial cuando hablamos de 10x. Entonces llegamos al nivel 4, que ya sería cuando hablamos de la agentización y de la orquestación. Empezamos a hablar de estos procesos que nos permiten pensar de otra manera, y al hacerlo, necesariamente tenemos que reestructurar nuestra forma de trabajar, nuestros procesos y cambiar la mentalidad; hasta los roles y las responsabilidades cambian. Con lo cual, no sería aplicar inteligencia artificial a lo establecido, sino modificar lo establecido para luego implementar esa inteligencia artificial. Mediante esta orquestación de agentes y cambio de roles, ya estaríamos en una IA nativa, porque nativamente estamos utilizándola y nos hemos adaptado a ella, en lugar de adaptar la IA a nosotros, ¿ok?

Stiven: Ok, perfecto. Ahí me das paso al siguiente bloque, Pablo, porque es precisamente eso lo que de pronto muchas compañías no entienden: llegan a implementarla en lo que ya tienen cuando, como dices, debería ser una adaptación. Entonces, paso a la siguiente pregunta: ¿Qué falla en una compañía como la de ustedes —desde intive— con los ejemplos o los casos que han tenido? ¿Qué puede fallar o qué puede funcionar en una compañía a la hora de implementar todos estos procesos de automatización?

Pablo: Bien, podemos citar ejemplos específicamente de implementación en equipos de software. La falla principal, o no sé si la palabra sería falla, sino la problemática que hay hoy, es que el reto es que las compañías están produciendo, casi todas. Sobre todo en esta época, en estos últimos dos años, estamos produciendo a una capacidad más limitada, no tan holgada como en la pandemia, con lo cual la compañía está operando casi al 100% o más. Entonces queda muy poco lugar para la experimentación. O sea, hay experimentación, pero no necesariamente hay mucha inversión disponible como para poder hacer ese cambio fundacional: tomar un equipo, ponerlo a hacer pruebas, a elaborar y así empezar a transformarse. Entonces, el reto número uno está ahí, que es lo que vemos con nuestros clientes y es en donde nosotros entramos a ayudar. Sabemos más o menos por dónde es el camino y entendemos los casos de los clientes técnicos, pero no necesariamente tienen ni el tiempo ni la experiencia para escalar esto y que realmente el impacto sea significativo más allá del impacto individual. Una de las limitaciones de hoy pasa por ahí. Otra limitación viene de las empresas que deliberadamente no quieren innovar y llegan tarde a esa innovación porque hay mucho hype alrededor de la inteligencia artificial y hay un proceso de aceptación. Primero está la negación, después puedes empezar a probar y decir «qué bueno lo que puedo hacer con esto», y de repente ya llega la adopción, donde dices «no sé cómo trabajé sin esta tecnología antes». Pero aún así, en todos los pasos que te estoy marcando, no necesariamente son cambios fundacionales; falta que el liderazgo pueda hacer ese cambio y llevarlo adelante. Es fundamental que esos líderes estén preparados. No todos los líderes lo están, o por ahí son temerosos de hacer el cambio por la razón que fuese, ya que la situación del mercado hoy no es tan fácil. Esa es básicamente una de las limitaciones que nosotros estamos viendo hoy. Por eso ingresamos: tenemos un modelo que ofrecemos a nuestros clientes sobre cómo ingresar y ayudarlos. Empezamos a transformarlos como una capa que se suma a sus equipos, los ayudamos a escalar para que luego ellos prosigan, y por lo menos ya arrancamos ese camino por ellos para que puedan continuarlo. En este caso, lo fundamental es la capacidad de innovar. El entendimiento de que, más allá del hype y las noticias que uno ve en Twitter a diario sobre nuevos modelos, si uno entiende que es un cambio significativo en el paradigma y en la ingeniería de software, se empieza a adaptar y a hacer esos cambios de roles. Por ejemplo, que un software engineer empiece a dejar de escribir código es algo que ya debería haber sido aceptado a día de hoy. Pasa a ser más un editor y un revisor, ya que la automatización de lo que es Quality Assurance hoy es una necesidad del 100%. Antes, uno de los challenges que normalmente veíamos en los proyectos era la falta de cobertura de testing automático o la falta de una disciplina de calidad exhaustiva por temas de costos y de tiempo. Hoy lo podés acelerar con inteligencia artificial, y esos roles se empiezan a mezclar. Un ingeniero de software comienza a incorporar también prácticas de calidad. Se empieza a ver porque básicamente empieza a orquestar y a diseñar. En ese diseño, empieza a hacer la implementación ayudado por el agente, con lo cual conoce de toda la disciplina, conoce la definición de arquitectura y lo que es la ingeniería de software. Gracias a eso y al emparejamiento con inteligencia artificial, ya tenés un gran cambio, porque un rol está sumando varios roles. El mercado le está poniendo nombres a esos roles, ¿no? De Prompt Engineering van cambiando los labels; el piso se mueve constantemente, pero fundamentalmente uno tiene que entender que esto se está acelerando porque está cambiando. El software está dejando de ser algo caro de construir. Estamos en la parte disruptiva, pero va a llegar a un punto donde la limitación no va a pasar por la construcción del software, sino que va a pasar por mucho antes.

Stiven: Exacto. Ahorita mencionabas también lo de los líderes, ¿cierto? Que hay obviamente líderes que se niegan. Yo, recibiendo información de pitches y todo esto, veo mucho que uno de los sectores que de pronto es más temeroso ante todas estas innovaciones es la banca, especialmente la tradicional. Al menos hay países en los que se ve un poco de retraso en la implementación de estrategias de automatización por ese miedo o, como decías, por la capacidad de inversión que tengan. Ahí hablaste algo sobre orquestación. ¿Qué es orquestar flujos realmente, Pablo?

Pablo: Supongamos, para hacerte una correlación, que en una orquesta tenés distintos instrumentos y hay un director que la va guiando, diciendo quién toca primero, quién toca después y qué tiene que tocar. En este caso es similar. Supongamos que reemplazamos roles definidos en lo que es el proceso de ingeniería de software con agentes: un agente que define o especifica requerimientos, un agente que escribe el código y hace el desarrollo, otro agente que verifica la calidad, otro agente que valida lo implementado… En el medio se pone el orquestador que básicamente configura y actúa como lo que llamamos el «human in the loop», el humano en el medio, controlando que cada paso dentro de esta cadena sea efectivo y haciendo la validación para que el software se construya en forma adecuada, evitando la deuda cognitiva de dejar que todo suceda en automático. También existe la orquestación automática; nosotros estamos experimentando con eso y tenemos partners que también lo están haciendo. Todo es experimental porque hay muchos cuestionamientos que resolver en el medio, pero esa orquestación es justamente lo que te da la velocidad, y es el cambio significativo. Fíjate que te cambian los roles: los humanos lo hacen y lo compactan, requiriendo un nuevo skill que es lo que está transformando a la industria y la va a seguir transformando en los próximos años.

Stiven: Excelente. Sí, ahí me das el espacio para la próxima pregunta, porque la tenía justo anotada y era sobre esos sistemas agénticos: ¿hasta qué punto se puede construir un sistema que sea autónomo, cierto, pero que al mismo tiempo sea completamente verificable por un orquestador y que no pase un error o que no actúe simplemente sin rendir cuentas a un humano? ¿Cómo se construye un sistema de orquestación exitoso?

Pablo: Bien, hoy es bastante challenging que no encaje el humano. Si se hace, básicamente se configuran todos los agentes y se alimentan con modelos como Claude u otros que te proveen toda la interfaz para que los vayas configurando. Configuras estos agentes y estos skills, y vas haciendo la dinámica de loops entre ellos. También puedes configurar un meta-agente o agente orquestador para que, por ejemplo, desde el ID de un ticket de un sistema de requerimientos como Jira, tome toda la información y te entregue el software en la branch de producción. Pero insisto, creo que todavía el ser humano está en el loop; si vos no estás participando ni leyendo lo que está sucediendo, te genera esa deuda cognitiva. Luego, cuando ese software entra en producción y en algún momento falla, nadie sabe exactamente qué está haciendo ese software. Obviamente vamos a recurrir a la inteligencia artificial de nuevo para tratar de entender qué es lo que está sucediendo, pero de alguna manera estamos delegando demasiado. Y si quiero volver a lo que vos comentaste en lo que es fintech o banca, es una vertical muy riesgosa como para hacer una experimentación muy fuerte, pues estamos hablando de transacciones de dinero, de seguridad y de muchas regulaciones. Nosotros tenemos mucha experiencia en la aplicación de regulaciones en software en industrias como Fintech, Automotive —que también es muy regulada— o Salud. En estos casos hay que tener una revisión especial, porque justamente eso es materia de mucha validación. Eso es lo que le genera miedo a los líderes: ¿hasta qué punto esta tecnología está madura para yo usarla sin generar un problema? Porque en definitiva, esta nueva tecnología de GenAI agéntica lo que nos está aportando es más velocidad para sacar features, producir software y hacer más negocios. Si quiero poner nuevos features en producción, el cycle time —el tiempo desde que decido qué feature implementar hasta que sale a producción— se está reduciendo, pero no tiene que venir a costa de un riesgo o un problema posterior. Entonces ese es uno de los challenges fuertes de fintech.

Stiven: Exacto. Pablo, ¿cómo es ahora el rol de los desarrolladores? Cierto, ya no solo es escribir código, sino que también ahora pasan a ser parte de sistemas de orquestación. ¿Cómo es actual y cómo lo es en el futuro? ¿Cuáles son esos skills que debería tener un programador en el futuro?

Pablo: Excelente pregunta. Se sabe que estamos revisando constantemente y que va cambiando. Antes de lo que está sucediendo, pongámosle en los últimos 24 meses, ya algunos roles iban cambiando. Generalmente, cuando construimos un software, hablamos de software de plataforma a escala. Tenemos el desarrollo de la parte de frontend, que puede ser web o mobile, con desarrolladores específicos de frontend con JavaScript, o mobile nativo o híbrido. Luego tenés toda la parte de plataforma backend, el típico backend engineer. Siempre el proyecto está acompañado por un software architect o solution architect que diseña la solución. También llegaron los full stack; de repente se empezó a pedir «queremos full stack, no queremos un front y un back separados». Y después empezamos con «bueno, pero también queremos que tengan cualidades de QA», entonces los roles se empiezan a mezclar. Y cuando llega la IA, básicamente decís, «Ok, yo ya lo puedo mezclar todo». Porque los skills que hay que tener hoy están basados en la fundamentación de comprender lo que es la ingeniería de software, que es la disciplina que te permite construir software de calidad, bien desarrollado, que puede ser mantenible y que te permite implementar una solución para un negocio real. Entonces, en esa disciplina lo fundamental es conocer su implicancia. Hoy en día y a futuro, lo más importante para un desarrollador de software es comprender los fundamentos no solo de la programación, sino de la ingeniería de software. Los requisitos que ya se están pidiendo, y que se van a aplicar más, son comprender la arquitectura de software y poder basarse en requerimientos para diseñarla. Si bien el agente la puede llegar a diseñar, vos tenés que entender que esa arquitectura sea escalable, mantenible y cost-effective. Entonces tienes skills de arquitectura y después skills de programación, tanto de front, de back como de mobile. Hoy ya no es tan relevante saber un lenguaje en particular, llámese JavaScript, Java o Python; en este momento ya no es tan relevante porque el agente codifica por vos. Vos tenés que poder leer un lenguaje y entenderlo, y el agente te va a acompañar. Y bueno, lógicamente también entra la disciplina de calidad y la especificación de requerimientos. Poder especificar y escribir en un lenguaje natural lo que una aplicación tiene que hacer es fundamental. La parte de arquitectura, el código y la calidad son fundamentales. Esos serían los skills que hay que tener, pero por encima de todo está el juicio o el judgment fundamental para poder tomar las decisiones en ese proceso. Cuando antes uno decía «yo voy a ser programador y voy a ser solo programador», eso está cambiando y muy rápido, por lo que hay que adquirir experiencia y conocimientos laterales. ¿Cómo se especifica un requerimiento? ¿Qué es un requerimiento y para qué sirve? Muchos de los problemas que tenemos hoy cuando queremos automatizar o implementar inteligencia artificial en un proyecto, es que vamos y de repente nos encontramos con que no hay especificación de requerimientos, con lo cual no podemos implementar la calidad. Entonces tenemos que irnos más atrás en el proceso y corregirlo. Todas estas implicancias en el proceso de ingeniería de software son skills que el actual o viejo software engineer va a tener y tiene que tener para poder continuar en este mundo.

Stiven: Y ahí, Pablo, los líderes también tienen un papel importante en el tema de capacitación, porque digamos que ya hay un equipo de desarrolladores. ¿Qué podrías decir o qué herramientas deberían tener ellos para poder ir capacitando y empoderando a su equipo de arquitectos y de desarrolladores, y que no se queden de pronto en el simplemente «no los necesitamos y ahora sí vamos a buscar a desarrolladores que sepan de requerimientos y de todo esto»?

Pablo: Es también una excelente pregunta porque como líder, lo más importante que tenés es el talento. La verdad que descartar tu talento para ir a buscar talento nuevo que traiga lo que vos necesitás es complicado, porque lo que más vale hoy es la experiencia. A medida que tenés que traer talento nuevo, lo sabio y bueno es reciclar y capacitar al actual; después si querés podemos hablar del talento junior. Pero es fundamental que el líder establezca los learning paths, que entienda cómo está cambiando el mercado y provea los planes y programas para que el talento se capacite y adquiera las habilidades. Nosotros en general tenemos programas donde vos tenés tu mentor y tus objetivos anuales que se desglosan por quarter. En esa implementación tenés bien definido cuál es tu skill actual y cuál es la idea de tu gap hacia donde vamos. A partir de ahí se traza básicamente la ejecución de cursos y la realización de certificaciones, no solo en certificaciones cloud o de algún tipo de hyperscaler que utilizamos, sino que hoy en día ya empiezan a haber certificaciones de herramientas agénticas, como Claude, Cursor, GitHub Copilot y otras. Y se revisa con un curso de certificación que te valide ese conocimiento con los trainings adecuados. Así que es fundamental que el líder defina ese gap y vaya haciendo el entrenamiento de su equipo. Y bueno, el talento nuevo ya se está reclutando de otra manera también. La típica entrevista técnica ha mutado dramáticamente; hoy es un must y una precondición rigurosa la experiencia con herramientas agénticas. Deja de ser relevante el conocimiento en un lenguaje en particular y se empieza a tomar más en cuenta, para un desarrollador, si sabe especificar o si sabe lo que es la práctica de la calidad, más allá de solo el coding.

Stiven: Excelente. Cuando antes las entrevistas eran netamente basadas en pruebas de ejercicio práctico, ¿sí?, solo test y todo esto.

Pablo: Exacto.

Stiven: Bueno, Pablo, pues se nos está acabando el tiempo. No sé si hay algo más que nos quieras compartir de pronto. Un consejo para las compañías para que se preparen para esta transformación que tienen, y pues que se animen también a adaptarse y a incorporar estos sistemas de automatización.

Pablo: Bien, por ahí mi consejo para todos los ejecutivos, directores y líderes, es una capacitación constante en este mundo que está cambiando y evolucionando. El piso se mueve constantemente y hay que tener hoy en día el criterio para discernir qué es real y qué no, qué es hype y qué realmente llegó para quedarse. Y a partir de ahí informarse, porque es sumamente importante que tengan el conocimiento de lo que está sucediendo para después poder realizar cualquier contratación. Sinceramente, uno no va a modificar toda su área o aplicar una tecnología si son áreas que no son tecnológicas, pero uno tiene que poder dialogar en ese idioma para poder comprender. La democratización de la tecnología cada vez es mayor, y un área que quiera contratar servicios para modificar su operación tiene que poder conocer el idioma y entender qué le están ofreciendo. Porque también en este mundo hay muchos que ofrecen cosas que no son tan reales, y hay una inversión de por medio, y bueno, queremos reducir el riesgo y garantizar el éxito, ¿no? Por lo cual, la capacitación constante es fundamental y no hay que tener miedo; estamos en un periodo de experimentación pero ya se están viendo impactos reales en la aplicación de la tecnología, así que… por ahí va.

Stiven: Listo Pablo, pues muchísimas gracias por estar en En Contxto y por el tiempo.

Pablo: Muchas gracias a vos, Stiven, y a todo tu equipo.