¿Cómo será el futuro de la ingeniería de software en la era de la IA?

Hace 25 años: el Manifiesto Ágil

En febrero de 2001, un grupo de 17 expertos en software —Martin Fowler entre ellos— se reunieron en estación de esquí de Snowbird, en las montañas de Utah (EEUU), para buscar alternativas a los métodos tradicionales, que consideraban demasiado rígidos y burocráticos. Como primer paso, redactaron el Manifiesto Ágil, un documento que resume la filosofía "agile". Si trabajas en el ámbito del desarrollo de software, conocerás este manifiesto y su importancia capital para el sector.

El Manifiesto prioriza a los individuos e interacciones, el software funcional, la colaboración con el cliente y la respuesta al cambio sobre la documentación y los procesos rígidos. Transformó la industria al reemplazar (en muchos equipos) el modelo clásico "en cascada" (waterfall) —rígido y secuencial— por un enfoque basado en la iteración y la flexibilidad. Su impacto se refleja en una mayor eficiencia, calidad del producto y satisfacción del cliente.

Su influencia y efectos han repercutido no solo en el sector tecnológico, sino también en la gestión de equipos y la gestión empresarial en general.

2026: retiro sobre el futuro del desarrollo de software

25 años después del Manifiesto Ágil, en febrero de 2026, y de manera simbólica en las mismas montañas de Utah, Martin Fowler y la empresa Thoughtworks organizaron un retiro de varias jornadas con cerca de 40 líderes técnicos, investigadores y profesionales de la ingeniería de software de todo el mundo.

El formato elegido para el debate fue de tipo "unconference" o espacio abierto (Open Space): un tipo de encuentro sin agenda ni presentaciones predefinidas, donde los propios participantes proponen los temas de las sesiones y eligen libremente a cuáles asistir.

Los organizadores del evento y algunas de las personas participantes han publicado artículos sobre los temas tratados en el retiro. Al final del post enlazo con las fuentes.

Los participantes analizaron cómo la inteligencia artificial está transformando radicalmente el desarrollo de software. A continuación, profundizo en los temas que más interesantes me han resultado.

Consecuencias negativas y riesgos de la adopción de la IA

Los participantes en el retiro identificaron diversas consecuencias negativas y riesgos asociados a la adopción de la IA en el desarrollo de software. A continuación, recojo las que me han parecido más relevantes.

El surgimiento de la "deuda cognitiva"

La deuda cognitiva es el vacío de comprensión que surge cuando la IA genera código de forma tan masiva que los humanos perdemos la capacidad de comprender en profundidad cómo funciona el sistema y por qué se construyó de esa manera. Se produce cuando el volumen de código generado por la IA es tal que obliga a los ingenieros a revisarlo de manera superficial.

El concepto tiene similitudes con el clásico de deuda técnica. Que se define como el coste futuro de retrabajo (los "intereses" de la deuda) derivado de elegir soluciones rápidas o atajos en el desarrollo actual en lugar de enfoques más eficientes y sólidos.

Los equipos pueden acumular deuda cognitiva más rápido que deuda técnica, hasta alcanzar un punto en el que no pueden realizar cambios sencillos sin romper algo inesperado, porque nadie comprende la teoría subyacente al sistema ni las decisiones de diseño originales.

Al igual que los intereses en la deuda financiera, la deuda cognitiva encarece progresivamente la incorporación de nuevas funcionalidades y exige una inversión explícita de tiempo y recursos para recuperar el conocimiento perdido.

El desapego del autor

Es un concepto estrechamente relacionado con el de deuda cognitiva. Mientras que la deuda cognitiva es causada por la velocidad y el volumen —la IA permite generar código tan rápido que sobrepasa la capacidad de procesamiento humana—, el desapego del autor surge de la delegación y la falta de autoría. Al dejar que agentes realicen el trabajo, el ingeniero se convierte en un supervisor que se distancia del "hacer", perdiendo la conexión profunda con el producto final. Se trata de una pérdida de conexión emocional con el sistema construido y una pérdida de responsabilidad sobre lo desarrollado.

Pérdida de habilidades

El uso intensivo de agentes de IA puede provocar que las habilidades de los ingenieros se atrofien al dejar de realizar el trabajo de forma manual.

Agotamiento y fatiga mental

La presión de revisar miles de líneas de código generado por múltiples agentes de forma simultánea genera una carga cognitiva inmensa, que está llevando a los ingenieros más experimentados al agotamiento.

Crisis de identidad

Como veremos más adelante, los roles de los ingenieros están evolucionando hacia la supervisión, lo que puede desencadenar una crisis de identidad en aquellos desarrolladores que aman el acto de programar y que disfrutan con la escritura artesanal de código (software craftsmanship).

Medidas para contrarrestar las consecuencias negativas y los riesgos

En el retiro se debatió sobre muchas medidas estratégicas centradas en recuperar el control humano y el rigor técnico. Destaco las que me han parecido más relevantes.

El surgimiento de la ingeniería de supervisión

El desarrollo de software se ha descrito durante mucho tiempo mediante dos bucles. El bucle interno es el ciclo personal del desarrollador: escribir, probar y depurar. El bucle externo es el ciclo de entrega más amplio de CI/CD, despliegue y operaciones. El retiro identificó un tercero: un bucle intermedio de ingeniería de supervisión situado entre ambos. En esta nueva etapa, la labor del ingeniero no consiste en la ejecución manual de la sintaxis, sino en:

Orquestar y delegar: descomponer problemas complejos en paquetes de trabajo que los agentes de IA puedan procesar.
Evaluar la veracidad: valorar con rapidez la calidad de la salida de los agentes y reconocer cuándo producen resultados plausibles pero incorrectos.
Mantener la coherencia: asegurar que la integridad arquitectónica del sistema se mantenga a pesar de los múltiples flujos de trabajo paralelos generados por la IA.

Vinculado a la supervisión, se habló de que las organizaciones están adoptando una clasificación por niveles de riesgo, donde la intensidad de la revisión humana es proporcional al impacto de un posible error. Así, los sistemas críticos requieren de una revisión humana profunda y rigurosa.

Modelo de gestión de riesgos y supervisión estratégica

Ante la capacidad de la IA para generar código de forma masiva, la ingeniería no desaparece, sino que se transforma. Algunas de las tareas a realizar por parte de los ingenieros serán:

Escritura precisa de especificaciones. Dado que la IA genera código a partir de instrucciones, la precisión de estas resulta crítica. Se está trabajando en diseñar métodos estructurados de redacción de especificaciones para evitar que la IA cometa errores de base.
Restricciones y tipado fuerte. En lugar de corregir errores a posteriori, se definen restricciones arquitectónicas que limitan lo que la IA puede o no modificar. Además, se propone utilizar lenguajes con sistemas de tipado fuerte para que el código incorrecto resulte "irrepresentable".
Revisión humana por niveles de riesgo. No todo el código requiere la misma supervisión.
TDD (Test-Driven Development). En un entorno donde la generación de código es no determinista (la IA puede dar respuestas distintas cada vez), las pruebas se convierten en la única fuente de verdad. Escribir las pruebas antes que el código evita que los agentes "engañen" al sistema creando pruebas que validen comportamientos erróneos.
Ingeniería de supervisión. Surge una nueva categoría de trabajo de supervisión situada entre la escritura de código (bucle interno) y la entrega (bucle externo). Este rol requiere habilidades de orquestación, delegación y una visión arquitectónica profunda para mantener la coherencia del sistema.

Las estructuras actuales, diseñadas solo para humanos, se están resquebrajando bajo el peso del trabajo asistido por IA, lo que exige una transición desde un modelo de artesanía hacia uno de gestión de riesgos y supervisión estratégica.

El resurgir del TDD (Test-Driven Development)

El TDD es un viejo conocido del desarrollo de software, defendido infinidad de veces como la técnica de desarrollo más eficiente y sostenible a largo plazo. Los participantes en el retiro sostienen que el TDD debe ser una responsabilidad humana fundamental para actuar como contrapeso determinista frente a la IA.

Los motivos principales que esgrimen son:

Evitar que la IA "haga trampas". Si se permite que los agentes escriban las pruebas al mismo tiempo o después del código, estos suelen crear pruebas que simplemente confirman su propia implementación, incluso si esta es incorrecta. Al escribir el humano las pruebas (o definirlas rigurosamente) antes de que la IA genere el código, se evita este fallo y se obliga al agente a ajustarse a un criterio externo y objetivo.
Las pruebas son la mejor técnica de ingeniería de prompts. Las pruebas escritas por el desarrollador sirven como las instrucciones deterministas que validan la generación no determinista de la IA.
Reducir la deuda cognitiva. El ciclo de TDD permite a los desarrolladores humanos consolidar su comprensión del sistema y plasmarla en la base de código, sobre todo si los humanos llevan a cabo también el paso de refactorización del ciclo. Delegar este proceso por completo a la IA contribuiría a la acumulación de deuda cognitiva, ya que el humano dejaría de razonar sobre la "teoría del sistema".
Facilita la labor del ingeniero de supervisión. En el nuevo rol de ingeniería de supervisión, el humano utiliza las pruebas para evaluar la calidad de lo producido por los agentes de forma rápida y segura, sin necesidad de leer cada línea de código generado.

Evolución del rol de desarrollador y del product manager

En el debate se estableció un paralelismo interesante con la historia de las imágenes generadas por ordenador. En 1992 los ingenieros codificaban a mano el renderizado de polígonos. Más tarde, ese trabajo lo hacía el hardware, y la tarea de los ingenieros paso a ser la de animación e iluminación. Cada nueva capa de abstracción en la generación de imágenes por ordenador provocaba que los trabajadores que no se adaptaban quedaran rezagados.

Los desarrolladores deberán evolucionar hacia supervisión, la arquitectura y el diseño de sistemas de alto nivel. Este movimiento puede conducir a la convergencia entre los roles de los product managers (PM) y de los desarrolladores. Algunos desarrolladores se desplazarán hacia decidir qué construir y por qué, un territorio que tradicionalmente pertenecía a la gestión de producto. Por otro lado, ya hay organizaciones que impulsan a los PM hacia las herramientas técnicas.

La convergencia es tan palpable que algunas grandes empresas tecnológicas están investigando si el rol de PM necesita una nueva denominación.

Un futuro incierto por construir entre todos

Annie Vella, una de las ingenieras participantes en el evento, aporta unas interesantes reflexiones que quiero incorporar a modo de conclusiones.

Hay más incertidumbre que certeza: sobre cómo usar bien la IA, qué impacto real tiene en la productividad, cómo están cambiando los roles y hacia dónde evolucionará todo. Nadie tiene respuestas definitivas. Todos están aprendiendo sobre la marcha.
Debemos ayudar a las generaciones actuales y futuras de ingenieros no con promesas vacías, sino definiendo con claridad los nuevos problemas que deben resolver. Se les contrató para escribir código; ahora se les pide delegarlo. Merecen que definamos qué viene después.