Cómo trabajar con proyectos legacy con IA sin romper lo que ya funciona

Cuando hablamos de inteligencia artificial aplicada al desarrollo de software, es fácil imaginar el escenario ideal, conectamos un agente al repositorio, le pedimos que entienda el sistema y empezamos a refactorizar, actualizar dependencias o reemplazar componentes antiguos. En proyectos nuevos esto puede funcionar razonablemente bien porque muchas de las decisiones todavía son visibles y el contexto suele estar fresco. En un sistema legacy, en cambio, la situación es bastante distinta.

El código puede mostrarnos qué hace el sistema, pero no necesariamente por qué lo hace. Una condición que parece innecesaria puede estar protegiendo una regla de negocio que nadie documentó, una duplicación puede existir por diferencias entre clientes o países, y una dependencia aparentemente obsoleta puede sostener un proceso crítico que sigue funcionando todos los días. El problema no está solo en la antigüedad del stack, sino en todo el conocimiento que se fue perdiendo, fragmentando o quedando en la memoria de unas pocas personas, por eso, cuando la IA entra en un proyecto legacy, su primera responsabilidad no debería ser cambiar código. Debería ayudarnos a reducir incertidumbre.

Ese es el principio que guía actualmente el tratamiento de proyectos legacy dentro de Kaddo, entender antes de cambiar y mantener ese entendimiento durante todo el ciclo de la modificación.

Un sistema no se vuelve legacy por utilizar una versión antigua de Java, .NET, PHP o cualquier otra tecnología. Incluso un proyecto relativamente reciente puede convertirse en legacy si nadie entiende bien sus dependencias, si las decisiones importantes no quedaron registradas o si modificar una parte del sistema genera miedo porque no sabemos qué puede romperse.

En ese contexto, el riesgo no está únicamente en lo que conocemos del código, sino también en aquello que todavía no conocemos. Podemos saber que un módulo es crítico y tener identificado un riesgo concreto, pero también podemos encontrarnos con preguntas que nadie sabe responder: quién consume realmente una tabla, qué proceso externo depende de cierto endpoint o por qué una validación aparentemente extraña fue agregada hace años.

Aquí aparece una diferencia importante. Un riesgo y una incógnita no deberían tratarse de la misma forma. Si sabemos que el módulo de facturación comparte transacciones con conciliación, tenemos un riesgo que debe mitigarse. Si no sabemos si existe otro proceso consumiendo directamente esas tablas, tenemos una incógnita que debemos investigar.

Reconocer esa diferencia es mucho más seguro que permitir que un agente complete el vacío con una suposición.

El enfoque legacy de Kaddo parte precisamente de hacer visibles esas zonas grises. En lugar de comenzar proponiendo cambios, el flujo inicial busca construir una imagen más clara del sistema mediante señales técnicas, contexto existente y análisis asistido por agentes.

De ese proceso surgen tres tipos de conocimiento especialmente útiles, los riesgos conocidos, las incógnitas y los candidatos de modernización. Los riesgos permiten identificar áreas donde un cambio podría tener consecuencias importantes; las incógnitas hacen explícito lo que todavía no entendemos; y los candidatos de modernización reúnen oportunidades que podrían tener sentido más adelante, sin convertirlas todavía en compromisos de implementación.

La diferencia parece pequeña, pero cambia bastante la forma de trabajar. En vez de decir “este módulo debería reemplazarse”, podemos decir “este módulo parece un candidato de modernización porque concentra varias dependencias y presenta estos riesgos”. La segunda formulación conserva incertidumbre, deja espacio para validar y evita que una observación preliminar termine convertida demasiado pronto en una decisión arquitectónica.

Eso es especialmente importante cuando usamos IA, porque los modelos son muy buenos produciendo explicaciones plausibles. En legacy necesitamos que también sea visible cuándo esas explicaciones todavía son hipótesis.

Cuando una organización decide modernizar, la conversación suele saltar rápidamente hacia la arquitectura objetivo. Queremos migrar a servicios, pasar a contenedores, reemplazar procesos batch por eventos, adoptar serverless o mover componentes hacia tecnologías más recientes.

El problema es que una arquitectura objetivo tiene poco valor si todavía no entendemos suficientemente la arquitectura que existe hoy, por eso, después del análisis inicial de riesgos e incógnitas, Kaddo busca reconstruir el estado actual del sistema y relacionarlo con las capacidades del producto. La intención no es producir diagramas por producirlos, sino entender qué partes del software soportan determinadas capacidades, qué dependencias existen entre ellas y dónde están las zonas que merecen mayor cuidado.

Antes de decidir cómo modernizar, deberíamos poder responder preguntas como qué capacidades soporta cada módulo, quién depende de él, qué integraciones son críticas, qué áreas tienen mayor riesgo y qué todavía no conocemos lo suficiente para tocar.

Ese orden importa. En un proyecto legacy, el current state no es una formalidad antes del target state; es la base que permite decidir si la arquitectura futura tiene sentido.

La llegada de agentes capaces de generar grandes cantidades de código puede hacer que una reescritura completa parezca más atractiva de lo que era hace algunos años. Si podemos producir código mucho más rápido, la tentación natural es pensar que quizá lo más sencillo sea empezar de nuevo.

Sin embargo, escribir código no suele ser la parte más difícil de reemplazar un sistema legacy. El reto está en reproducir correctamente todo el comportamiento acumulado que el sistema ha aprendido a lo largo del tiempo.

Un producto con diez o quince años en producción probablemente contiene reglas de negocio que nunca llegaron a un documento formal. Algunas viven en validaciones, otras en consultas, otras en integraciones y otras en comportamientos que los usuarios simplemente esperan que sigan funcionando.

La IA puede acelerar una reescritura, pero no puede recuperar automáticamente ese conocimiento perdido, por esa razón, los candidatos de modernización en Kaddo son precisamente eso, candidatos. Pueden señalar que convendría encapsular una dependencia, extraer un módulo, reemplazar una tecnología o eliminar una pieza obsoleta, pero antes de convertir cualquiera de esas ideas en trabajo real necesitamos entender su impacto, sus dependencias y el valor que aporta.

La IA puede ayudar a descubrir oportunidades, la decisión de ejecutarlas sigue necesitando contexto y criterio.

Una vez construido el conocimiento inicial, tampoco tiene demasiado sentido intentar una transformación enorme. En sistemas legacy suele ser más útil comenzar con cambios pequeños que, además de aportar valor, permitan aprender más sobre el sistema.

Esto cambia la lógica de la modernización. En vez de intentar comprender todo antes de tocar cualquier cosa (algo que puede convertirse en un proyecto interminable ), podemos reducir la incertidumbre progresivamente. Un Work Item pequeño permite validar una hipótesis, confirmar una dependencia, comprobar una integración y descubrir comportamiento que antes no estaba documentado.

El roadmap puede organizar esos pasos de manera que los primeros cambios tengan un riesgo controlado y, al mismo tiempo, produzcan conocimiento útil para los siguientes.

La meta no debería ser “conocer completamente el legacy antes de empezar”, porque probablemente eso nunca suceda. Lo que sí podemos hacer es aumentar nuestra confianza de forma incremental.

Identificar riesgos al comienzo sirve de poco si esa información desaparece cuando el agente empieza a modificar código. Uno de los cambios importantes en la evolución reciente de Kaddo es precisamente conectar el conocimiento del proyecto con la implementación mediante el Implementation Handoff.

Cuando un Work Item está listo, el handoff puede incorporar los riesgos, incógnitas y candidatos de modernización que realmente afectan las áreas que se van a modificar. El agente no necesita recibir toda la historia del sistema ni todos los documentos existentes; necesita el contexto relevante para la decisión que está tomando.

Este enfoque también evita otro problema frecuente, llenar la ventana de contexto con tanta información que lo importante termina enterrado entre detalles irrelevantes.

En legacy, esto resulta especialmente valioso. Si un Work Item modifica una zona asociada a un riesgo conocido, ese riesgo debería acompañar el trabajo. Si existe una incógnita que podría afectar la implementación, debería estar visible antes de que el agente tome una decisión difícil de revertir.

Kaddo también incorpora una evaluación específica de riesgo legacy para contrastar cambios planeados con lo que ya sabemos del sistema. La intención no es detener automáticamente el trabajo, sino hacer evidente cuándo un cambio necesita una consideración adicional.

Una vez que el conocimiento está relacionado con áreas concretas del repositorio, podemos detectar cuándo un cambio entra en una zona delicada, ahí aparece el papel de guard.

En un proyecto legacy, guard puede identificar que los archivos modificados intersectan con áreas relacionadas con riesgos conocidos y presentar ese conocimiento como contexto adicional. Esto no significa convertir cada modificación en una aprobación burocrática ni impedir que el equipo avance.

La idea es mucho más simple, si vamos a tocar una parte frágil del sistema, deberíamos saber qué conocemos sobre ella antes de continuar.

Ese principio aplica tanto para personas como para agentes. Un desarrollador puede olvidar un riesgo documentado meses atrás, y un agente puede no haber recibido ese contexto durante una sesión. Relacionar conocimiento con ownership y código ayuda a que esa memoria vuelva a aparecer justo cuando se necesita.

En proyectos legacy, esa capacidad puede ser más valiosa que tener otro documento perfectamente escrito que nadie consulta.

Esta diferencia es importante en cualquier proyecto, pero se vuelve crítica cuando trabajamos con sistemas que conocemos parcialmente.

Un agente puede modificar el código, ejecutar algunas pruebas y afirmar que la tarea se completó correctamente. Sin embargo, esa afirmación no debería ser suficiente para considerar terminado el trabajo.

La implementación describe lo que ocurrió; la verificación intenta demostrar que lo ocurrido corresponde con lo que realmente se necesitaba, por eso el lifecycle actual de Kaddo incorpora evidencia de implementación. Esa evidencia puede incluir qué archivos cambiaron, qué validaciones se ejecutaron, qué decisiones surgieron durante el trabajo, qué se desvió del plan inicial y qué nuevos gaps aparecieron.

Después, verify puede contrastar esa evidencia con los criterios de aceptación y con la intención original del Work Item.

En un legacy, esta separación es especialmente sana porque disminuye la dependencia de la confianza ciega en el agente. No se trata de preguntar “¿terminaste?”, sino de revisar “¿qué cambió y qué evidencia tenemos de que cumple lo esperado?”.

Una de las partes más interesantes del ciclo ocurre después de verificar la implementación. Supongamos que durante un cambio descubrimos que una tabla aparentemente interna también es utilizada por un proceso nocturno que nadie tenía identificado. Si ese descubrimiento queda solamente en la conversación con el agente, la próxima persona que llegue a esa parte del sistema tendrá que aprenderlo otra vez. Ese tipo de conocimiento debería regresar al proyecto.

Por eso Kaddo incorpora learn como parte del lifecycle. Los aprendizajes obtenidos durante un Work Item pueden actualizar riesgos, resolver incógnitas, reclasificar hallazgos o agregar nuevas restricciones al conocimiento existente, con esto, el proceso deja de ser únicamente una secuencia de tareas y empieza a comportarse como un ciclo de aprendizaje:

Ese patrón tiene mucho sentido en legacy porque permite que el conocimiento crezca al mismo ritmo que la modernización. No necesitamos detener el proyecto durante meses para producir una documentación perfecta antes de comenzar, podemos aprender mientras evolucionamos el sistema.

Muchos sistemas legacy tampoco viven dentro de un único repositorio. Con el tiempo suelen aparecer servicios adicionales, aplicaciones web independientes, procesos batch, integraciones externas y componentes administrados por otros equipos, eso significa que entender un repositorio no necesariamente significa entender el sistema.

El alcance actual de Kaddo contempla escenarios multirepo, donde un proyecto puede mantener una visión global mientras cada módulo conserva su contexto específico. Esto permite que un Work Item se refine desde una perspectiva más amplia y que después se determine qué repositorios están realmente involucrados.

También existen casos donde ni siquiera tenemos acceso al código. Puede tratarse de un sistema de un proveedor, un componente administrado por otro equipo o un servicio restringido por razones organizacionales. Para esos escenarios, el intercambio de contexto no necesita significar acceso completo al repositorio; puede trabajar con una descripción mínima de capacidades, contratos, riesgos y dependencias.

En legacy esto es especialmente importante porque algunas de las dependencias más peligrosas son precisamente aquellas que viven fuera de la base de código que estamos intentando modificar.

Vale la pena dejar clara esta frontera; Kaddo no toma un monolito y lo convierte automáticamente en microservicios, ni pretende reconstruir por sí solo todo el conocimiento del negocio leyendo código. Tampoco busca reemplazar las decisiones del equipo.

Su papel es diferente, el CLI realiza tareas determinísticas como escanear, organizar artefactos, gestionar el lifecycle, detectar relaciones y recopilar evidencia. Los agentes ayudan a interpretar señales, formular hipótesis, identificar riesgos y proponer alternativas. El humano conserva el control de las decisiones que tienen impacto real sobre el sistema.

Lo que Kaddo intenta ofrecer alrededor de ese proceso es continuidad, que el conocimiento descubierto durante el análisis no se pierda en la implementación, que las decisiones tomadas durante el cambio puedan verificarse y que los aprendizajes regresen nuevamente al conocimiento del proyecto.

Esa continuidad es especialmente importante en sistemas legacy, donde buena parte del problema nació precisamente porque durante años el conocimiento se fue perdiendo entre cambios, personas y herramientas.

La inteligencia artificial nos permite producir software mucho más rápido, pero la velocidad para escribir código no resuelve automáticamente el principal problema de un sistema legacy.

El verdadero cuello de botella suele ser la confianza para modificarlo; no sabemos exactamente qué podemos romper, qué comportamiento debemos conservar, qué integraciones siguen activas o qué decisiones históricas continúan siendo importantes. Por eso, antes de preguntar cómo modernizar un sistema, conviene hacer una pregunta más útil ¿qué necesitamos entender para poder cambiarlo con confianza?

Ahí es donde veo el valor de aplicar Knowledge Driven Development a proyectos legacy. No se trata de utilizar IA para reemplazar rápidamente lo antiguo, sino de combinar conocimiento, agentes, evidencia y aprendizaje para reducir progresivamente la incertidumbre que hace difícil evolucionar estos sistemas.

Un legacy no deja de ser legacy porque reemplacemos su tecnología, empieza a dejar de serlo cuando recuperamos la capacidad de entenderlo, cambiarlo y aprender de él sin depender del miedo a romper lo que ya funciona.