Teoría de la evolución del software en la era de la IA

En muchas empresas actuales, la mayor parte de la toma de decisiones, la ejecución, la verificación y la mejora tiene lugar en sistemas de software. Los puntos de contacto con los clientes, los cambios de precios y contratos, los ajustes de suministro e inventario, la recopilación y el análisis de registros y los flujos de trabajo operativos internos dependen profundamente del software. Ya no estamos en una fase en la que simplemente se ha introducido la TI: la propia operación del negocio está ligada al estado de su software, y la capacidad de actualizarlo equivale a la capacidad de actualizar el negocio.

La situación no se limita a sectores concretos. Con independencia del sector o el tamaño, las empresas que operan con cierto nivel de velocidad y complejidad ya no pueden funcionar sin el software en su núcleo. A medida que las condiciones externas cambian más deprisa y aumenta la frecuencia de los ciclos de decisión y ejecución, la propia capacidad de cambiar se convierte en un factor competitivo. Cuando coinciden cambios en el valor para el cliente, las condiciones del servicio, las restricciones operativas, los requisitos normativos y las estructuras de costes, una empresa que no puede actualizar su software tampoco puede convertir las decisiones en acciones, corregir el rumbo y, finalmente, acaba deteniéndose.

En este contexto abundan los casos en los que las actualizaciones de software se convierten en un cuello de botella para las decisiones empresariales y los cambios de política. Puede haberse tomado la decisión, pero los cambios estructurales necesarios para ejecutarla no se completan a tiempo, lo que reduce el abanico de iniciativas que pueden probarse de manera realista.

Cuanto más tardan las actualizaciones de software, mayor es la distancia entre la decisión y su ejecución. Durante ese intervalo, las condiciones del entorno siguen cambiando. Como resultado, más decisiones quedan sin ejecutar y el margen operativo de la empresa se contrae gradualmente.

Al observar software utilizado durante mucho tiempo, rara vez encontramos sistemas que conserven su estado original. Se añaden funciones, cambian las configuraciones, se ajusta la operación y el software acaba adoptando una forma muy distinta de la prevista al principio. Es poco frecuente que las primeras especificaciones o documentos de diseño coincidan por completo con la implementación y la realidad operativa años después. Esto no significa que el diseño original careciera de sentido, sino que las condiciones asumidas al inicio son difíciles de mantener durante periodos prolongados de operación.

A medida que el software sigue en uso, tareas y decisiones que no se habían previsto pasan a formar parte de la operación cotidiana. Cambia el comportamiento de los usuarios, evolucionan el volumen y el significado de los datos, y se modifican las relaciones con los sistemas del entorno. Se acumulan procesos adicionales, reorganizaciones, sustituciones y soluciones provisionales. Lo que al principio parece una pequeña excepción acaba convirtiéndose en norma, y esas normas presionan la estructura interna. Con el tiempo, un diseño antes sencillo se vuelve más complejo al absorber las exigencias del mundo real.

También es raro que las mismas personas sigan siendo responsables durante toda la vida del sistema. Cambian desarrolladores y operadores, evolucionan las estructuras organizativas y se reasignan funciones. Aunque se conserve la documentación, los supuestos contextuales de las decisiones anteriores no se comparten por completo. Lo que se pierde no es volumen de información, sino el conjunto de condiciones que daba sentido a aquellas decisiones. Cuando esos supuestos se desvanecen, el mismo texto deja de llevar a las mismas conclusiones. Los cambios se vuelven más cautelosos, proliferan las soluciones provisionales locales y la coherencia general se deteriora gradualmente.

Estos cambios no nacen de fallos concretos ni de circunstancias excepcionales. Se observan patrones similares una y otra vez en distintas organizaciones, sectores y ámbitos técnicos. Todos comparten que el software se utiliza durante largos periodos mientras las condiciones del entorno siguen cambiando. La naturaleza de esos cambios varía según el contexto, pero su persistencia es común.

Las pequeñas diferencias entre supuestos se acumulan con el tiempo. Los ajustes que antes podían absorberse mediante la operación rutinaria acaban exigiendo una reconsideración estructural. En ese momento aumentan el peso y el alcance del cambio. A medida que crece su radio de impacto, suben los costes de verificación, resulta más difícil volver atrás y se ralentiza la toma de decisiones. Cuando las decisiones se demoran, las empresas ya no pueden probar aquello que desean ensayar. No es un estado de baja calidad, sino de aprendizaje inhibido; cuanto más rápido cambia el entorno, más perjudicial se vuelve.

Muchos proyectos de desarrollo han seguido tradicionalmente un modelo que intenta cerrar el diseño todo lo posible antes de iniciar la implementación. Este enfoque ha sido eficaz para generar consenso, dividir el trabajo y gestionar proyectos a escala. En entornos con altos costes de implementación y experimentación, consolidar pronto el diseño era una decisión práctica y servía para reducir la complejidad por adelantado.

Sin embargo, este enfoque arrastra limitaciones temporales inherentes. Desde que se cierra un diseño, las condiciones que presupone empiezan a cambiar. Cuanto más tiempo transcurre entre el cierre del diseño y la implementación, mayor es la distancia entre los supuestos y la realidad. Si las condiciones cambian deprisa, esa distancia puede ser considerable cuando el sistema queda terminado. A menudo no cambia un detalle menor de las especificaciones, sino las prioridades fundamentales, las restricciones operativas o el significado de los datos.

Esto no implica que el diseño fuera incorrecto. En muchos casos fue la mejor decisión posible en aquel momento. El problema surge cuando no se contempla que los supuestos cambiarán con el tiempo. Si no se integra la posibilidad de ajustar el sistema tras completarlo, este se vuelve difícil de actualizar en cuanto se da por terminado. Cuando la finalización se trata como punto de llegada, los cambios posteriores se gestionan como excepciones y se acumulan como añadidos tardíos. Con el tiempo, las actualizaciones se amontonan como correcciones locales, la estructura se endurece y disminuye la velocidad de aprendizaje del negocio.

Este enfoque de desarrollo surgió por razones claras. Los altos costes de implementación y la pesada carga de experimentar hicieron esencial la planificación temprana. La capacidad de evaluar condiciones, ordenar dependencias y definir de antemano un sistema completo desempeñó un papel decisivo en esos entornos. Generar consenso, anticipar los riesgos y dividir el trabajo de forma estructurada eran necesidades prácticas.

A medida que cambian las condiciones, también cambia dónde reside el valor. Los juicios, fallos y ajustes del pasado no pierden validez, sino que se consultan y aplican de otra manera. La experiencia de las revisiones de diseño ya no sirve para predecir perfectamente el futuro, sino para reconocer dónde es probable que los sistemas fallen ante el cambio. Las lecciones operativas indican qué fundamentos deben permanecer fijos y qué áreas deben conservar su flexibilidad. La experiencia pasada no se descarta: se reutiliza.

Cuando esta reutilización se vuelve posible, el valor de la experiencia suele aumentar en vez de disminuir. En entornos que cambian deprisa, los juicios equivocados se amplifican con rapidez. Un menor coste de experimentación permite más intentos, incluidos los erróneos. Por ello, la calidad de la priorización y del criterio para marcar la dirección influye aún más en los resultados.

En los últimos años se han producido cambios claros en las condiciones de desarrollo. Ha disminuido el coste de implementar y experimentar, y se ha acortado el tiempo necesario para convertir una hipótesis en algo verificable. Este cambio se debe en parte a la adopción generalizada de software basado en IA que facilita directamente la generación y modificación de código. Estas herramientas reducen el coste inicial de validar implementaciones y hacen viable probar, descartar y reestructurar diseños.

Lo que importa aquí no es si se adopta la IA, sino que las condiciones han cambiado. Cuando las condiciones cambian, las estructuras que funcionan eficazmente en ellas también cambian.

Es importante señalar que no se trata de enfrentar el desarrollo impulsado por IA con el desarrollo humano. Lo que ocurre es la convergencia del criterio humano —la priorización, las decisiones estructurales y la comprensión del contexto— con la generación y modificación de código asistidas por IA. Las personas deciden qué probar y dónde cambiar; la IA reduce el coste de llevar esas decisiones a la práctica. Esta cooperación hace viables la experimentación y el aprendizaje a velocidades antes impracticables.

Como resultado, el desarrollo que actualiza continuamente el software en sintonía con los cambios de negocio se ha convertido en una opción realista por primera vez.

En estas condiciones, resultan más manejables las estructuras que permiten ajustes posteriores que aquellas que intentan fijarlo todo de antemano. A medida que aumenta la escala y evolucionan los requisitos, revisar y modificar la estructura se convierte en un requisito previo. Esto no significa abandonar el diseño, sino reducir el núcleo fijo, definir con claridad qué debe seguir siendo flexible y conservar la capacidad de reorganizar la estructura gradualmente con prioridades claras. El diseño de los fundamentos cobra más importancia, no menos.

A medida que los sistemas escalan, la infraestructura se sustituye inevitablemente. Configuraciones antes suficientes pasan a necesitar redundancia, particionado, distribución, observabilidad y mecanismos de recuperación. La operación continuada exige reorganizaciones y ampliaciones funcionales. En entornos reales, las actualizaciones, los retrocesos de versión, las reversiones, las migraciones por fases, la operación en paralelo y las sustituciones parciales son actividades habituales, no incidentes excepcionales. Las estructuras que no permiten avanzar y retroceder aumentan el riesgo y el coste con cada cambio, hasta detener por completo las actualizaciones.

Por ello, las estructuras de software deben admitir la reversibilidad y la sustitución. Cuando los límites no están claros y los sistemas crecen en una sola dirección, los cambios se propagan ampliamente, la validación pierde precisión y resulta difícil revertir. Unos límites bien definidos y unidades modulares sustituibles permiten seguir aprendiendo a través del cambio.

Estas decisiones no pueden dejarse únicamente al ingenio individual. Determinar qué permanece fijo, qué se mantiene flexible y qué cambios son aceptables debe tratarse como un conjunto de supuestos compartidos. Esto exige algo más que elegir herramientas o normas de programación: requiere una comprensión táctica común. Sin ese criterio compartido, las actualizaciones pasan a depender de cada persona, la velocidad disminuye y el aprendizaje se detiene.

Cada vez que cambian las condiciones, se añaden nuevas restricciones tanto al software como al negocio. Aunque los diseños y las implementaciones anteriores ya no sean directamente aplicables, eso no invalida la experiencia que contienen.

Los criterios formados a través de cambios anteriores —comprender dónde fallan los sistemas, dónde aparecen cuellos de botella y hasta dónde se propagan los cambios— siguen utilizándose cuando las condiciones vuelven a cambiar. Aunque cambie la forma, esos criterios reaparecen al decidir qué probar y dónde intervenir.

En los entornos de desarrollo modernos, combinar el criterio humano sobre la situación con una implementación asistida por IA permite aplicar esa experiencia en intervalos mucho más breves. El conocimiento acumulado se plasma en la calidad de ese criterio y se transfiere directamente a las implementaciones y validaciones posteriores.

Como resultado, los sistemas no se reconstruyen de cero a cada cambio, ni las formas pasadas se conservan rígidamente. En su lugar, la experiencia se reutiliza a medida que cambian las condiciones, y el software evoluciona en consecuencia.

El cambio continuará. Surgirán nuevas tecnologías y restricciones. Pero la experiencia acumulada no se perderá. A medida que aumenta la velocidad y frecuencia con que puede reutilizarse la experiencia, su valor se refleja más directamente y de manera consistente en los resultados.