Documentar un sistema antiguo del que no hay código fuente

A quién le sirve. Empresas que dependen de un programa antiguo del que nadie conserva el código ni la documentación y quieren entender qué hace antes de sustituirlo.

Qué hicieron

Consultores de Thoughtworks usaron Gemini 2.5 Pro para hacer ingeniería inversa (deducir cómo funciona un programa sin tener su código) de sistemas antiguos de los que no había código fuente. La IA ayudó a sacar qué hacen esos sistemas, y el resultado fueron «planos» validados de su funcionamiento. Fue un piloto de dos semanas. La fuente es un resumen muy corto, así que no detalla qué material se usó ni qué pasos siguió la gente.

Cómo salió

El piloto produjo planos validados del funcionamiento en dos semanas. Según la fuente, mostró que la IA puede reducir el tiempo y el riesgo de modernizar sistemas opacos, siempre que la velocidad se equilibre con la validación.

Conviene saber

Lo delicado es validar: hay que comprobar lo que dice la IA y no fiarse solo de la rapidez. Los detalles están en el artículo completo de InfoQ, no en el listado donde aparece.

Qué necesitas

• Gemini 2.5 Pro u otro asistente de IA que admita muchos archivos a la vez
• Todo lo que tengas del sistema: configuraciones, esquemas de bases de datos, capturas de pantalla, manuales, informes y ejemplos de datos
• Personas que usen el sistema a diario y puedan confirmar lo que hace
• Si solo tienes el programa compilado, un especialista que pueda analizarlo
• Una carpeta de trabajo con copias, nunca los originales

Cómo hacerlo tú, paso a paso

1. Reúne todo lo que tengas del sistema y guárdalo en una carpeta de trabajo, en copias.
2. Quita datos de clientes y claves antes de dárselo a la IA.
3. Pega el prompt de la ficha con la carpeta. Pide que lo que no tenga claro lo marque como «sin verificar».
4. Pide el plano en un archivo markdown: qué hace el sistema, sus flujos de trabajo, el recorrido de los datos y las reglas de negocio.
5. Enséñaselo a las personas que usan el sistema y pregúntales si lo que describe es lo que ocurre de verdad.
6. Comprueba con casos reales si el plano predice lo que el sistema hace.
7. Usa el plano para decidir qué reglas de negocio conservar, qué se puede tirar y cómo planificar la sustitución.

Tengo un sistema antiguo y no hay documentación. Esto es lo que tengo de él: [carpeta con el código, las configuraciones, los esquemas de las bases de datos, capturas o manuales]. Léelo todo y escribe un plano en un archivo markdown con lo que hace el sistema, sus flujos de trabajo principales, el recorrido de los datos y las reglas de negocio. Marca como «sin verificar» todo lo que no tengas claro. No modifiques ningún archivo que no sea el plano. Habrás terminado cuando todos los módulos importantes estén descritos.

Consejos

• La velocidad no vale sin validación. Cada afirmación del plano debe comprobarla alguien que conozca el sistema.
• Haz que marque «sin verificar» lo que no tenga claro. Así sabes dónde mirar primero.
• Trabaja con copias y pide que no modifique nada salvo el plano.

Preguntas frecuentes

Fuentes

• infoq.com ↗

En el directorio desde el 3 de octubre de 2026.