Solo se puede probar en producción
Prioridad: un entorno de pruebas réplica de producción.
Automatización: ninguna. La IA asiste.
Perspectivas · Modernización
Modernizar con IA: automatiza solo lo que puedas comprobar
La IA ya escribe código más rápido que cualquier equipo. Pero en una modernización la pregunta no es quién escribe el código, sino cómo sabes que tu sistema sigue haciendo lo mismo. De esa respuesta depende cuánto puedes delegar en la IA y cuánto debe seguir en manos de tu equipo.
Bruno Anglés · Tecnología, Arquitectura e Innovación · · 8 min de lecturaEl cuello de botella ya no es escribir código
Modernizar un sistema que sostiene el negocio tiene una regla: después de cada cambio, el sistema debe hacer exactamente lo mismo que antes. Los mismos cálculos, las mismas validaciones, los mismos documentos. Incluso los errores conocidos, que se corrigen después y por separado.
La IA puede proponer cientos de cambios al día. Si cada uno tiene que revisarlo una persona leyendo código, la velocidad de la IA no sirve de nada: el cuello de botella pasa a ser la revisión. Y leer código, por sí solo, no detecta un cambio sutil en el cálculo de una prima o en el redondeo de un recibo.
Lo que permite delegar en la IA es una red de comprobaciones automáticas: pruebas que verifican, en cada paso, que el comportamiento antes y después es el mismo. Los equipos técnicos lo llaman harness, el arnés que sujeta a la IA y le dice en segundos si su último cambio ha roto algo.
La conclusión es sencilla: cuánto puedes automatizar depende de cuánto puedes comprobar. No de lo buena que sea la IA.
Lo que la IA aporta desde el primer día
Hay un papel de la IA que sirve en cualquier situación, incluso cuando el sistema todavía no se puede probar con garantías: no exige tocarlo, solo leerlo.
- Explicar el código. Qué hace cada módulo, qué reglas de negocio contiene, de dónde sale cada dato.
- Documentar lo que nadie documentó. Dependencias, integraciones, procesos nocturnos y el conocimiento que solo tienen unas pocas personas.
- Proponer qué probar. A partir del código, qué escenarios deberían comprobarse antes de cambiar nada.
- Resolver dudas. Un asistente para el equipo que hace el trabajo, disponible a cualquier hora.
Este papel reduce la dependencia de personas clave y acelera todo lo demás. Y puede hacerse dentro de tu infraestructura, sin que tu código salga de casa.
Cuatro niveles de madurez
El punto de partida no lo elige la IA: lo marca tu sistema, según lo fácil que sea probarlo. En cada nivel, la prioridad es subir al siguiente. Y el papel de la IA crece a medida que crece la capacidad de comprobar.
Las pruebas dependen de otros sistemas
Prioridad: simuladores, datos estables y pruebas de los procesos críticos.
Automatización: parcial y supervisada.Se prueba el sistema entero, no sus piezas
Prioridad: separar las piezas para poder probarlas de forma aislada.
Automatización: alta, con fuerte supervisión.Red de pruebas en tres niveles
Prioridad: modernizar por etapas, con garantías.
Automatización: amplia. Las personas deciden y aprueban.Solo se puede probar en producción
No hay un entorno donde probar sin afectar al negocio: cada cambio se valida en vivo, con clientes reales. A menudo, además, la instalación es manual y depende de quien la ha hecho siempre.
Automatizar cambios aquí es una imprudencia. Un error de la IA llegaría directamente a tus clientes.
PrioridadCrear un entorno de preproducción que replique producción y una instalación repetible: que cualquier versión pueda desplegarse en ese entorno siempre de la misma forma, sin pasos manuales ni conocimiento que solo tenga una persona. Y todo el código, bajo control de versiones.
Papel de la IAAsistente del equipo que monta el entorno. Ayuda a inventariar configuraciones, servidores y dependencias, a escribir los procedimientos de instalación y a documentarlos. No toca el código de la aplicación.
Hay entorno de pruebas, pero depende de otros sistemas
Existe preproducción, pero la aplicación necesita conectarse a sistemas reales para funcionar: el ERP, el gestor documental, la pasarela de pago, servicios de terceros. Eso plantea dos problemas:
- Muchos de esos sistemas no tienen entorno de pruebas, así que no puedes probar nada que modifique datos.
- Las pruebas no se pueden repetir: los datos cambian continuamente y la misma prueba da resultados distintos cada día.
Aislar la aplicación con simuladores de esos sistemas, que ante el mismo escenario responden siempre igual, y con un juego de datos de prueba estable. En sectores regulados, esos datos deben estar anonimizados: los datos reales de tus clientes no deberían salir de producción.
Con la aplicación aislada, ya se pueden automatizar pruebas de extremo a extremo de los procesos críticos: dar de alta una póliza, emitir un recibo, cerrar un expediente. Pruebas que fotografían lo que el sistema hace hoy, se considere correcto o no.
Papel de la IAGenera los simuladores y los primeros borradores de las pruebas. Pero conectar los simuladores suele exigir pequeñas intervenciones quirúrgicas en el código, para que la aplicación hable con el simulador en lugar de con el sistema real. Esas intervenciones las hacen personas que conocen el código, apoyadas por la IA.
Las pruebas que escribe la IA necesitan además la validación de alguien que conozca el negocio. Una prueba que comprueba lo que no importa da una falsa sensación de seguridad.
Este nivel todavía no basta para modernizar: las pruebas de extremo a extremo dicen que algo se ha roto, pero no dónde, y tardan demasiado para la cantidad de intentos que hace la IA.
Se prueba el sistema entero, pero no sus piezas
Hay pruebas de extremo a extremo y de integración estables contra preproducción. Pero el código está tan acoplado (la lógica de negocio mezclada con la base de datos, las pantallas o las llamadas a otros sistemas) que no se puede probar una pieza por separado.
Para sustituir un módulo necesitas comprobarlo en su frontera: qué recibe y qué devuelve. Y necesitas la respuesta en segundos, no en horas.
PrioridadCrear esas fronteras. Separar la lógica de negocio de lo que la rodea, con patrones de diseño conocidos como la inyección de dependencias, para poder probar cada componente aislado. Cada uno de estos cambios está protegido por las pruebas del nivel anterior: si algo se rompe, se detecta.
No hace falta hacerlo en todo el sistema a la vez. Basta con empezar por los módulos que vas a modernizar primero y escribir pruebas de integración y unitarias en sus límites.
Papel de la IALa IA ya puede ejecutar buena parte de estas refactorizaciones, que suelen ser mecánicas y repetitivas. Pero con una supervisión fuerte de personas que conozcan el código y la arquitectura de software: dónde poner las fronteras es una decisión de diseño que condiciona toda la modernización.
Red de pruebas en tres niveles
Hay pruebas de extremo a extremo, de integración y unitarias, al menos en la parte del sistema que se va a modernizar. Son fiables, rápidas y se ejecutan automáticamente con cada cambio.
Es en este nivel donde la modernización con IA se puede abordar con garantías.
Cómo es una modernización con IA con garantías
El principio es el de siempre: por etapas, sin saltos al vacío. Lo que cambia es quién hace el trabajo pesado.
Elegir la pieza
Las personas deciden qué módulo modernizar primero, por valor de negocio y por riesgo. La IA ayuda a analizar sus dependencias.
Fijar el contrato
Las pruebas de la frontera del módulo definen qué debe hacer. Se revisan, se completan y se congelan: la IA no puede modificarlas. Si pudiera, podría «arreglar» una prueba en lugar del código.
Probar las pruebas
Se introducen fallos a propósito en el código y se comprueba que alguna prueba los detecta. Una prueba que nunca falla no protege nada.
Construir en pasos pequeños
La IA escribe la nueva versión detrás de la misma frontera, cambio a cambio. Cada cambio debe pasar todas las pruebas antes del siguiente; si falla, se descarta. Cada cambio aceptado queda registrado y lo revisa una persona.
Comparar en paralelo
La versión antigua y la nueva reciben las mismas peticiones y se comparan sus respuestas. Cada diferencia se analiza: muchas revelan reglas de negocio que nadie había documentado.
Cambiar de forma gradual
La nueva versión entra poco a poco, con la posibilidad de volver atrás en minutos. Cuando está estable, se retira la antigua y se pasa a la siguiente pieza.
Qué queda en manos de las personas: decidir qué se moderniza y en qué orden, validar las reglas de negocio, revisar y aprobar cada cambio, y decidir cuándo una pieza nueva entra en producción. La IA hace el trabajo pesado. Las personas mantienen el control.
Para equipos técnicosPatrón strangler fig, pruebas de caracterización y de contrato, pruebas de mutación, ejecución en sombra con tráfico duplicado y despliegue canario con interruptores de funcionalidad (feature flags).
Cinco reglas que valen en cualquier nivel
- Primero, el mismo comportamiento. Modernizar y corregir errores son tareas distintas. Si las mezclas, no sabrás si una diferencia es un error nuevo o una corrección.
- Quien cambia el código no toca las pruebas. Ni las personas ni la IA.
- Pasos pequeños y reversibles. Cada cambio debe poder deshacerse sin dejar nada a medias.
- Las personas aprueban. La IA propone; ningún cambio llega a producción sin revisión humana.
- Tu código, en casa. El código de tus sistemas también es un activo sensible. El análisis y la generación con IA pueden hacerse dentro de tu infraestructura.
¿En qué nivel estás? Tres preguntas
- ¿Puedes probar un cambio sin que lo note ningún cliente? Si la respuesta es no, estás en el nivel 0.
- ¿Puedes repetir mañana la misma prueba y obtener el mismo resultado, sin depender de otros sistemas? Si no, estás en el nivel 1.
- ¿Puedes probar un módulo de forma aislada y saber en segundos si lo has roto? Si no, estás en el nivel 2.
Si has respondido que sí a las tres, estás en el nivel 3. Es normal que distintas partes de un mismo sistema estén en niveles distintos: la hoja de ruta puede empezar a modernizar una parte mientras prepara otra.
En resumen
La IA no cambia lo que hace bien una modernización: entender antes de tocar, avanzar por etapas y comprobar cada paso. Cambia la velocidad a la que puedes avanzar cuando esas comprobaciones existen.
Si tu sistema aún no está preparado, la mejor inversión no es la IA más potente, sino la red que te permitirá usarla con seguridad.
¿En qué nivel está tu sistema?
Cuéntanos tu situación. Te ayudamos a identificar el punto de partida y el primer paso, antes de proponerte nada.