Durante mucho tiempo, tocar un sistema heredado fue sinónimo de contener la respiración. Cualquier cambio en código legado, sobre todo si nadie en el equipo recuerda bien cómo fue escrito, podía significar romper algo que llevaba años funcionando sin sobresaltos. Ese miedo, más cultural que técnico, terminó frenando proyectos de modernización durante años.
Lo que está cambiando hoy no es solo la tecnología disponible, sino la forma en que un developer se relaciona con ese riesgo. Herramientas como IBM Bob no prometen automatizar la modernización sin supervisión: la propuesta pasa por acompañar al desarrollador en cada paso, sin sacarlo de la ecuación.
Human-in-the-loop: la IA no reemplaza el criterio del developer
La filosofía detrás de Bob se apoya en un concepto conocido como human-in-the-loop: la herramienta no busca eliminar al humano del proceso, sino compartir su razonamiento con el desarrollador para que este valide cada paso antes de avanzar. En la práctica, esto significa que ninguna modificación se aplica a ciegas: el equipo puede seguir el criterio detrás de cada sugerencia y decidir si avanzar o no.
Ese esquema viene acompañado de mecanismos de seguridad pensados para dar tranquilidad frente a un sistema crítico. Bob permite cancelar una tarea en curso o hacer un rollback —volver a la versión anterior— si algo no sale como se esperaba, y puede generar pruebas unitarias automáticas para validar que el código sigue funcionando como debería. Ninguno de estos mecanismos elimina el riesgo por completo, pero sí cambia la naturaleza del problema: en vez de actuar a ciegas sobre un sistema heredado, el equipo cuenta con una red de contención antes de comprometerse con un cambio.
De COBOL a Java: modernizar sin perder de vista la deuda técnica
El alcance de este tipo de herramientas no se limita a escribir código nuevo. Uno de los usos que más interés genera entre developers es la modernización de aplicaciones existentes, incluyendo proyectos en Java y en lenguajes propietarios como COBOL y RPG, todavía muy presentes en sistemas core de bancos, aseguradoras y organismos públicos.
A esto se suma un uso menos visible pero igual de relevante: la documentación de proyectos. Un sistema legado mal documentado —o directamente sin documentar— es, en sí mismo, una fuente de deuda técnica: cada nuevo desarrollador que se suma al equipo pierde tiempo tratando de entender decisiones que nadie registró. Usar una IA para generar esa documentación de forma sistemática reduce ese costo oculto y facilita el mantenimiento a futuro.
Otro punto que suele pasar desapercibido es que esta clase de agentes no está pensada para intervenir solo en una etapa puntual del desarrollo. Pueden participar en cualquier momento del ciclo de vida del software (SDLC): desde la planificación inicial, pasando por las pruebas, hasta el mantenimiento de largo plazo. Esa presencia continua es, quizás, lo que más cambia la relación del developer con el código legado: deja de ser un territorio aislado que se toca solo en emergencias.
Lo que cambia puertas adentro: velocidad y foco en lo que importa
Más allá del argumento técnico, hay un impacto cultural que empieza a notarse dentro de los equipos. IBM cita un caso de uso interno —ya hecho público— en el que la propia compañía logró acelerar el desarrollo de aplicaciones entre un 60% y un 80%. Independientemente del número puntual, lo interesante es qué tipo de trabajo dejó de hacer un developer para lograr esa aceleración.
Buena parte de ese impacto cultural tiene que ver con delegar tareas que, para muchos desarrolladores, dejaron de tener sentido hace rato: correr scripts repetitivos, por ejemplo, una tarea que solía recaer de forma bastante estricta tanto en perfiles junior como senior, casi sin distinción de seniority. Al delegar esa supervisión en un agente de IA, el equipo puede redirigir su atención hacia tareas de mayor impacto: arquitectura, decisiones de diseño, problemas de negocio.
Dicho esto, sería exagerado hablar de un proceso ya resuelto. Aunque los ciclos de desarrollo se acortaron, la adopción diaria de este tipo de herramientas todavía está en construcción. Tanto IBM como las comunidades de desarrolladores siguen trabajando en cómo integrar plenamente estos agentes al flujo de trabajo real, más allá de la demo o la prueba piloto. Ese proceso de maduración, más que la tecnología en sí, es probablemente el capítulo que todavía queda por escribirse.
Compartir nota:
