IA como arqueólogo de código legado: extrayendo reglas de negocio de VBA

Cuando la lógica de negocio vive en macros VBA dispersas

El problema del tesoro oculto

Considere una aplicación de planificación de personal construida en VB6, utilizada por varios cientos de clientes en Alemania. En su núcleo: 28.000 líneas de código VBA implementando la lógica para planificación de turnos, seguimiento de tiempo y — crucialmente — cumplimiento con los Tarifverträge alemanes.

Los Tarifverträge son convenios colectivos que gobiernan las condiciones laborales en las industrias alemanas. Especifican todo, desde duraciones máximas de turno hasta períodos de descanso obligatorios, desde cálculos de horas extra hasta derechos de vacaciones. Pero aquí está la complejidad: estas reglas difieren por industria, por región, a veces por empresa individual. Un hospital en Baviera opera bajo reglas diferentes que una planta manufacturera en Renania del Norte-Westfalia. El centro de distribución de una cadena minorista tiene requisitos diferentes que sus tiendas.

Durante dos décadas, cada instalación de cliente evolucionó para implementar sus requisitos específicos de Tarifvertrag. Primas de turno nocturno calculadas de una manera aquí, de otra manera allá. Reglas de tiempo de descanso que dependen de la duración del turno, pero con diferentes umbrales por cliente. Horas extra que se acumulan diferentemente según tipo de contrato, estado de empleo y qué convenio colectivo aplica.

Las reglas de negocio no están en un documento de requisitos. Están dispersas a través de miles de líneas de VBA, escritas por desarrolladores que entendían tanto el código como la ley laboral — algunos se han ido, pero muchos permanecen disponibles como expertos de dominio que pueden validar lo que la IA extrae.

Cuando estos sistemas necesitan modernización, las organizaciones enfrentan un problema fundamental: incluso cuando los desarrolladores originales permanecen disponibles, no pueden dedicar meses a explicar cada módulo. La documentación, si alguna vez existió, describe intención en lugar de implementación. Los usuarios saben lo que el sistema hace por ellos, pero no cómo — y ciertamente no cómo interactúan todas las piezas.

Por qué los enfoques tradicionales fallan

La brecha de documentación

La mayoría de las personalizaciones VBA nunca fueron documentadas formalmente. Un desarrollador escribió código para resolver un problema inmediato, funcionó, y todos siguieron adelante. Incluso cuando existe documentación, típicamente describe lo que alguien intentaba construir, no lo que realmente se construyó — y ciertamente no las modificaciones sutiles hechas durante años de mantenimiento.

La limitación de las entrevistas

Los usuarios de negocio pueden describir lo que hacen con el sistema. Conocen sus flujos de trabajo, sus casos límite, sus soluciones alternativas. Pero describen comportamiento, no lógica. Cuando dicen “el sistema calcula nuestra comisión”, no pueden decirte las siete condiciones anidadas que determinan qué tasa de comisión aplica, o el manejo especial para productos descontinuados, o el ajuste trimestral que entra en vigor para cuentas de alto volumen.

El problema de la revisión manual de código

Los desarrolladores experimentados pueden leer código VBA. Pero leer miles de líneas a través de docenas de instalaciones personalizadas, identificar qué patrones representan reglas de negocio versus implementación técnica, y sintetizarlo todo en entendimiento coherente — esto toma meses. Incluso entonces, la revisión está coloreada por lo que el revisor espera encontrar. Los patrones inesperados se pasan por alto.

Entra la arqueología de código asistida por IA

Cuando empecé a trabajar con este cliente como Developer Advocate, el desafío era claro: extraer suficiente entendimiento de las reglas de negocio existentes para reconstruir el sistema como una Progressive Web App moderna — desplegable tanto en las instalaciones del cliente para quienes lo requieren como una oferta SaaS para aquellos listos para la nube.

El análisis tradicional tomaría un año o más. Los expertos de dominio conocen el negocio, pero no leen VBA. Las personas que escribieron el código todavía están, pero han asumido otras responsabilidades — soporte al cliente, consultoría de implementación, capacitación — y no pueden dedicar meses a guiar a los desarrolladores a través de cada módulo. Y con varios cientos de variantes de clientes, revisar manualmente cada instalación era impracticable.

Los grandes modelos de lenguaje entrenados en código traen algo nuevo a este análisis. A diferencia de intentos anteriores de simplificar el desarrollo de software, la IA no promete eliminar la necesidad de experiencia — la amplifica. Estos modelos han visto millones de patrones de código a través de lenguajes. Pueden reconocer lo que el código intenta lograr incluso cuando la implementación es enrevesada. No se cansan después de leer la centésima subrutina. Y pueden ser dirigidos a buscar tipos específicos de lógica de negocio.

Lo que la IA hace bien

Reconocimiento de patrones a escala: Los modelos de IA pueden procesar grandes cantidades de código e identificar patrones recurrentes. Pueden detectar dónde aparece lógica de negocio similar en diferentes instalaciones de clientes, incluso cuando está implementada diferentemente.

Traducción a lenguaje natural: Dado código VBA, una IA puede generar descripciones en lenguaje simple de lo que hace el código. No descripciones perfectas — la IA puede malinterpretar el contexto — pero puntos de partida que los humanos pueden verificar y refinar.

Comparación y contraste: Al analizar múltiples instalaciones, la IA puede resaltar dónde difieren. “La instalación A calcula impuestos de esta manera, pero la instalación B tiene esta condición adicional.” Estas diferencias a menudo representan reglas de negocio críticas específicas para cada cliente.

Respuesta a preguntas: En lugar de solo resumir código, la IA puede responder preguntas específicas. “¿Cómo maneja este sistema las devoluciones?” “¿Qué dispara la advertencia de límite de crédito?” “¿Dónde ocurre el cálculo del descuento?”

Lo que la IA no puede hacer

Entender el contexto de negocio: La IA no sabe por qué existe una regla, solo lo que hace. Un humano debe determinar si un cálculo peculiar refleja requisitos de negocio genuinos o una solución temporal olvidada hace tiempo.

Garantizar completitud: La IA puede pasar por alto interacciones sutiles entre módulos de código. Puede pasar por alto lógica condicional que raramente se ejecuta. Proporciona asistencia, no certeza.

Reemplazar experiencia de dominio: La IA puede identificar que existe un cálculo y describir su mecánica. Solo alguien que entiende el negocio puede juzgar si el cálculo es correcto, necesario u obsoleto.

Un enfoque práctico

El enfoque que hemos desarrollado trata a la IA como un puente entre el código y la experiencia de dominio. La IA lee el VBA. Los expertos de dominio validan las reglas de negocio. El resultado no es solo entendimiento — son especificaciones ejecutables que impulsarán la nueva implementación.

El desafío de las cuentas

Una gran porción del código VBA trata con cuentas — los bloques de construcción para calcular pagos de empleados. Hay cientos de diferentes tipos de cuentas: cuentas de salario base, cuentas de horas extra, cuentas de prima de turno nocturno, cuentas de vacaciones, cuentas de licencia por enfermedad, cada una con sus propias reglas de cálculo que varían según Tarifvertrag y configuración del cliente.

Entender cómo funciona cada tipo de cuenta — cuándo se acumula, cómo calcula, qué dispara ajustes — es esencial para que el nuevo sistema produzca nóminas correctas.

Fase 1: Extracción impulsada por IA a Issues de GitHub

Dirigimos a la IA a analizar áreas funcionales específicas del código VBA. “Examina este módulo e identifica todos los tipos de cuenta. Para cada cuenta, describe cuándo se acumula, cómo se calculan los montos y qué condiciones afectan el cálculo.”

La IA no solo produce un informe — crea un Issue de GitHub para cada regla de negocio o tipo de cuenta descubierto. El issue contiene el análisis de la IA: lo que el código parece hacer, las condiciones que aplican, cualquier variación que notó, y preguntas donde la lógica no estaba clara.

Fase 2: Revisión humana y planificación

Los expertos en la materia que revisan cada issue son las mismas personas que escribieron el código VBA original. Desde entonces se han movido a roles orientados al cliente — implementación, soporte, capacitación — pero recuerdan la lógica. No necesitan releer su propio VBA; leen la descripción en lenguaje de negocio de la IA y juzgan si coincide con lo que construyeron hace años.

A veces la IA acertó exactamente. A veces pasó por alto un matiz que el autor original detecta inmediatamente. A veces la IA reveló comportamiento que incluso el autor había olvidado — manejo de casos límite que agregaron para un cliente específico hace una década.

Los issues validados se programan para implementación. Los issues poco claros se marcan para investigación más profunda, a menudo involucrando una conversación rápida para refrescar memorias sobre los requisitos de ese cliente particular.

Fase 3: Implementación asistida por IA

La implementación sigue un patrón similar. Dado un issue validado que describe una regla de negocio, le pedimos a la IA que escriba el código C# y las pruebas asociadas para la nueva PWA.

La IA produce tanto la implementación como los casos de prueba. Las pruebas codifican las reglas de negocio en forma ejecutable: “Dado un empleado con tipo de contrato X trabajando patrón de turno Y, cuando se calcula la cuenta de prima nocturna, entonces el monto debería ser Z.”

Fase 4: Validación humana dirigida

Los expertos revisan las pruebas generadas — pero no línea por línea. Saben qué cuentas son sencillas y cuáles ocultan complejidad. Saben qué reglas de Tarifvertrag tienen casos límite sutiles y cuáles son cálculos simples.

Enfocan su atención en las partes críticas y difíciles. Cuando ven una prueba para primas de turno nocturno, verifican si maneja correctamente el límite de medianoche. Cuando ven pruebas de acumulación de vacaciones, verifican la lógica para empleados de año parcial. Su experiencia guía dónde mirar, no si mirar todo.

Esta revisión dirigida es mucho más eficiente que la verificación exhaustiva. Los expertos aplican juicio sobre dónde es probable que se oculten errores, en lugar de tratar todo el código como igualmente riesgoso.

La mentalidad de aumento

Los expertos de dominio en esta empresa escribieron el código VBA original. Conocen la ley laboral alemana íntimamente, y conocen el código porque lo construyeron. Pero su tiempo es escaso — están ocupados con implementaciones de clientes, llamadas de soporte y capacitación. Hacer que relean miles de líneas de su propio código para explicárselo a nuevos desarrolladores no es un buen uso de su experiencia.

La IA crea una capa de traducción. Lee el código y produce descripciones en lenguaje de negocio. Los autores originales validan esas descripciones — rápidamente, porque reconocen explicaciones correctas de su propio trabajo. Juntos, revelan entendimiento en horas que de otra manera tomaría semanas de conversaciones interrumpidas.

Este modelo colaborativo define el enfoque de Developer Advocate: trabajo técnico práctico que amplifica la experiencia existente en lugar de reemplazarla. La IA es una herramienta. Los expertos de dominio proporcionan el juicio. El Developer Advocate orquesta el proceso y asegura que el conocimiento extraído se convierta en especificaciones ejecutables — no solo documentación que se desincronizará.

Esto importa especialmente para

proyectos de modernización de legado donde entender el sistema existente es

trabajo artesanal — investigación, hipótesis, verificación. La IA acelera las fases de investigación y verificación mientras mantiene a los humanos firmemente en control de las decisiones de juicio.

Consideraciones prácticas

Selección de modelo

Diferentes modelos de IA tienen diferentes fortalezas. Para análisis de código, los modelos con fuertes capacidades de codificación y grandes ventanas de contexto funcionan mejor. Claude Sonnet 4.5 y modelos similares pueden manejar archivos de código sustanciales y mantener coherencia a través de largas sesiones de análisis.

Gestión de contexto

Los módulos VBA pueden ser grandes. Proporcionar suficiente contexto para que la IA entienda lo que está mirando — sin abrumarla con código irrelevante — requiere juicio. A veces necesitas alimentar módulos relacionados juntos; a veces necesitas enfocarte en funciones específicas.

Ingeniería de prompts

Cómo preguntas importa enormemente. “¿Qué hace este código?” produce respuestas genéricas. “Este código VBA parece calcular descuentos de precio. Identifica todas las condiciones que afectan qué tasa de descuento se aplica, y explica cada condición en términos de negocio” produce análisis útil.

Control de versiones

Cuando estás analizando código de múltiples instalaciones de clientes, hacer seguimiento de qué código vino de dónde es esencial. A la IA no le importa, pero a los humanos interpretando su salida definitivamente sí.

Más allá de la extracción: Construyendo para el futuro

Entender las reglas de negocio legadas es solo el primer paso. El objetivo más grande es típicamente reconstruir esta lógica en un sistema moderno — documentado, probado, mantenible.

Los patrones que extraes del VBA legado pueden convertirse en la base para:

• Especificaciones ejecutables que documentan exactamente lo que el sistema debe hacer
• Suites de pruebas que verifican que la nueva implementación coincide con el comportamiento anterior
• Modelos de dominio que hacen las reglas de negocio explícitas en lugar de enterradas en código

La asistencia de IA no termina en la extracción. Los mismos modelos pueden ayudar a traducir reglas de negocio identificadas a código moderno, generar casos de prueba y documentar el comportamiento previsto. Todo el arco desde entender hasta reconstruir se vuelve más rápido.

El valor real

El sistema de planificación de personal representa décadas de conocimiento acumulado sobre la ley laboral alemana — no teoría legal abstracta, sino implementación práctica de cómo cientos de organizaciones realmente aplican estas reglas. Ese conocimiento tiene enorme valor, pero estaba encerrado en código VBA que solo un puñado de personas podía leer.

Ahora ese conocimiento se está volviendo explícito. Las pruebas que estamos creando no solo validan la nueva implementación PWA — documentan exactamente cómo funciona cada regla de Tarifvertrag en la práctica. Cuando un cliente pregunta “¿cómo manejan los períodos de descanso para empleados de tiempo parcial en retail?”, la respuesta existe en forma legible y ejecutable.

Esto cambia la economía de modernización fundamentalmente. Un año de análisis manual se comprime en semanas. Los expertos de dominio — que habrían pasado ese año respondiendo preguntas de desarrolladores tratando de entender el código — en cambio validan reglas extraídas a nivel de negocio. Su experiencia es apalancada, no consumida.

Para organizaciones enfrentando sistemas legados con personalización extensiva, esto representa una nueva capacidad. Trabajo que anteriormente requería meses de tiempo de especialista costoso ahora sucede en semanas. Análisis que era demasiado costoso de justificar se vuelve asequible. Conocimiento de negocio que estaba encerrado en código de décadas se vuelve accesible para personas que realmente pueden usarlo.

El código no va a ningún lado. Pero ahora tenemos mejores herramientas para entender lo que sabe.