La inevitable caída del Ingeniero de Software

Trasfondo

Cuando empecé profesionalmente en la industria de la Tecnología, hace muchos años, caí en todos los lugares comunes posibles del Ingeniero de Software: despreciaba a la gente de negocio, quienes dominaban los presupuestos y las relaciones con los clientes, por no entender de Tecnología y pretender controlarla; minusvaloraba a la gente de diseño y producto, esos pobres diablos que no sabían hacer magia con el código y se dedicaban a pintar flujos y diseños estáticos a los que yo debía dar vida; miraba por encima del hombro a los usuarios, ignorantes a los que había que corregir constantemente y que sólo provocaban molestos cambios; ignoraba al propio producto en el que trabajaba, del que no era usuario y al que veía como una entidad artificial.

Mi única obsesión era el dominio puramente técnico. Ese espacio imaginario en el que el cliente no existe, donde sólo importan los lenguajes de programación, los frameworks, las arquitecturas, los patrones y las herramientas. Donde el debate en torno a un artículo o un libro puede llevarte horas con el único objetivo de demostrar que tu inteligencia y tu conocimiento están por encima de los de otros. En ese espacio yo era un monje enfrascado en la búsqueda de la perfección técnica que debía procurarme la ascensión y la gloria. Fundé comunidades técnicas, creé grupos de estudio y de trabajo y refiné mis habilidades especializadas gracias a las cuales me gané el respeto de colegas y jefes.

Obviamente pertenecía a una casta en la que me sentía seguro. Ajena a los vaivenes de negocio, la pureza técnica tenía muchas ventajas: prestigio, remuneración económica, progresión profesional y, en la mayoría de las empresas, conllevaba (lo quisieras o no, tuvieras habilidades para ello o no) acabar asumiendo puestos de gestión de personas y de proyectos.

Ahí comenzaban los “problemas”, asumir puestos de gestión suponía empezar a alejarse de la comodidad de la pureza técnica y empezar a lidiar con la psicología de las personas a tu cargo y de los molestos clientes con sus problemas. Casi ningún técnico de pura cepa asumía este tipo de rol con ganas ni con entrega. Los buenos seniors técnicos se convertían en managers mediocres. Muchos con el tiempo abandonaron y regresaron a la seguridad del código.

En esta transición a manager tuve mucha suerte: de manera innata me apasionaba liderar y construir equipos y proyectos. Desde pequeño en primaria organizaba grupos de teatro y lideraba publicaciones científicas. Disfrutaba creando cosas en colaboración con otros. En mi caso la transición fue natural.

La formación que recibías al convertirte en manager era ”ahora eres manager” por lo que todo el aprendizaje corría a cargo de la propia experiencia del día a día, el ejemplo de otros managers y las lecturas especializadas que cayeran en tus manos, con un componente humano incalculable que predominaba sobre todo lo demás.

Al principio fui un manager técnico, que recibía instrucciones de Producto de otros y que veía el Diseño, la Usabilidad y la Gestión de Producto como dominios totalmente ajenos al mío. Yo dominaba el cómo, pero otros me procuraban el qué, muy a menudo sin entender el por qué.

Tuve la suerte, tras mi paso por consultoría saltando de proyecto en proyecto, de llegar a una empresa de Producto en la que el CEO lideraba con entusiasmo la relación con los clientes, el descubrimiento de sus problemas y el diseño de funcionalidades para resolverlos. Esta etapa me cambió la vida. Allí llegué a mi primer puesto de CTO, trabajando mano a mano con el CEO.

Por fin entendí que la Tecnología era un medio, no un fin. Que lo que realmente hacíamos era construir soluciones que resolviesen problemas reales de clientes (por lo que estos estaban dispuestos a pagar) y que tendría más impacto (algo que yo anhelaba) cuanto más cerca estuviese del espacio del Problema, no sólo del de la Solución.

Todo cobró sentido cuando empecé a entender que mi obsesión por el área técnica no era suficiente si quería tener el máximo impacto sobre los objetivos de la empresa en la que trabajaba y sobre el destino (el qué y el por qué) del equipo que lideraba. Necesitaba adentrarme en la Gestión de Producto, en el Descubrimiento de Necesidades de los clientes, en el Diseño, en la Usabilidad, en el conocimiento del Dominio de Negocio en el que me movía.

Me adentré de cabeza en entender el ciclo completo de Producto y me enamoré, con la fortuna de que siempre se me habían dado bien el Diseño de Interfaces y de Funcionalidades. Entendí que como Ingeniero mi labor no debía limitarse al cómo sino que debía incluir el qué y el por qué. Ya no podía ser un mero Ingeniero de Software, debía ser un Ingeniero de Producto. Tampoco me limité a ser un mero CTO, allí donde me era posible empecé a liderar el Producto y la Tecnología, como CPTO.

No he vuelto a mirar atrás. Me sigue apasionando el área puramente técnica pero sólo como una parte de un ciclo más grande. Actualmente ni siquiera veo la separación entre Producto y Tecnología, sólo un ciclo que va desde el descubrimiento de Problema al diseño de la Solución, su validación y su iteración.

Diseñé durante el confinamiento una metodología ágil dentro del ámbito Lean, con fuertes influencias de Lean Product Management, Lean Software Development y Extreme Programming a la que llamé Forum totalmente orientada a ayudar a los profesionales de nuestro sector a maximizar el Valor (de negocio) y el Ratio de Entrega de Valor bajo la premisa de que cada equipo debe operar tanto en el espacio del Problema (Value Discovery, Impact Mapping, Feedback, etc) como en el de la Solución (Continuous Delivery, Testing, Experimenting, etc) para entender primero el por qué, luego el qué y finalmente el cómo.

La Revolución de la Inteligencia Artificial Generativa

El 30 de Noviembre de 2022 OpenAI lanzó al mundo el chatbot conocido como ChatGPT (Generative Pre-trained Transformer) apoyado en el modelo de lenguaje GPT-3 y nuestras vidas cambiaron para siempre. Estamos ante un hecho que quedará marcado en la Historia como el de la primera imprenta de Gutenberg, un hito que nos descubrió las posibilidades de la IA Generativa. Luego llegaron modelos generativos de imágenes, de sonidos, de vídeos y, por supuesto, especializados en la generación de código.

Al principio nadie se tomó muy en serio el código generado por IA, sólo resolvía bugs sencillos y en general resultaba mediocre e inseguro. La reacción generalizada se movía entre el escepticismo de los programadores, la burla de algunos y la euforia de los no-coders. Empezaba un período de confusión que aún no ha terminado.

En cuestión de meses la calidad de los modelos avanzaba imparable y la generación de código por IA empezó a entrar de lleno en el tooling de gente técnica y menos técnica con IDEs como Cursor o Windsurf. Se empezó a entender que la IA potenciaba la productividad de los programadores y comenzaba a dar alas a los que programaban poco o incluso nada.

Algunos hace tiempo ya vislumbrábamos el futuro:

Pero lo que resultaba difícil de prever era la velocidad a la que avanzaría la IA Generativa aplicada a la programación. ¿Sería equivalente a un Desarrollador Junior? ¿Sería capaz de programar soluciones completas full stack? ¿Qué calidad tendría el código generado? ¿Sería seguro?

Seguimos en la etapa de confusión, todo sucede a trompicones, muy rápido para algunos, lento para otros y mientras una gran mayoría esconde la cabeza en la arena. Vivamos como si la IA no fuera ya capaz de programar mejor que un Desarrollador medio.

A día de hoy, Marzo de 2025, la caída del Ingeniero de Software es inevitable. Se hace cada vez más evidente que en poco tiempo nadie estará escribiendo código como antes sino guiando a la IA para que genere el código por él (en el lenguaje que sea más conveniente, con las tecnologías y frameworks más adecuados para resolver el problema, quién sabe si en código máquina cuando ya no sea supervisado). El auge de los Agentes IA hace que todos los procesos de Desarrollo de Software, desde el control de versiones, la revisión de código, la documentación o el testing ya pueda verse automatizado.

¿Cómo será el futuro cercano?

El futuro pertenece a los Ingenieros de Producto, a aquellos dispuestos a balancear su presencia hacia el espacio del Problema, ahora que el de la Solución requerirá cada vez menos esfuerzo. A aquellos dispuestos a entender el ciclo completo desde el descubrimiento de necesidades de sus clientes hasta maximizar el Valor entregado como parte de sus soluciones diferenciándose por mejores conceptos funcionales (Gestión de Producto), mejores interfaces e interacciones (UI/UX), mejores integraciones y, en general, mejor Diseño de Solución que sus competidores.

Se abre un tiempo de explosión de Productos con equipos pequeños, iteraciones cada vez más rápidas y soluciones cada vez más sofisticadas. Se abre un tiempo de software fácilmente customizable para cada cliente.

Viene un tiempo convulso de reconversión en la Industria Tech (y en la mayoría de industrias) que implicará la caída de productos y plataformas gigantes, de transformación profunda de puestos y roles, de reestructuración de grandes equipos, de emprendimiento salvaje.

Ahora que todo el mundo da por muerto Agile es cuando su esencia será más importante que nunca: la Adaptabilidad, la Mejora Continua, la Colaboración con el Cliente son la clave de este futuro. Los principios Agile están más vivos que nunca en la era de la Inteligencia Artificial.