Cómo auditar código legacy sin que la IA invente

Auditar código legacy con IA se vuelve confiable cuando inviertes el orden del proceso: primero pides un tour técnico y solo después pides los hallazgos. Este enfoque es clave para equipos de desarrollo que trabajan con módulos antiguos que nadie quiere tocar y que están llenos de problemas escondidos.

El escenario es familiar para cualquiera que haya heredado un repositorio grande. En payments.svc existe un módulo llamado Settlements, la liquidación de pagos, que nadie ha modificado en años. Funciona, pero está lleno de vacíos que solo conoce quien lo escribió. Y aquí viene lo interesante: la IA no conoce esa historia, y cuando no sabe algo, no se queda callada, rellena los huecos con invenciones muy plausibles.

Por qué la IA inventa contexto en código que no conoce

El riesgo central al pedirle a una IA que audite código desconocido es la alucinación. Si le preguntas directamente "¿qué hace este archivo?", te devuelve un resumen que en principio se ve bien, pero no tienes forma de saber si realmente entendió el contexto.

En el ejemplo de Settlements, quien conoce la API y la leyó puede detectar de inmediato vacíos, confusiones y comentarios sobre cosas que tal vez ni siquiera son un problema real. Ahora multiplica eso por una API mucho más grande y un módulo más complejo, y el margen de error se dispara [00:38].

¿Qué es una alucinación de IA en revisión de código? Es cuando la IA rellena información que no tiene con suposiciones plausibles pero falsas. En código legacy ocurre porque no conoce la historia ni las decisiones detrás del módulo.

En qué consiste el patrón tour antes de auditar

El patrón tour invierte el orden habitual. Antes de pedir una sola crítica, le pides a la IA que construya un mapa del módulo anclado en el código real [00:59].

Este tour técnico cumple dos funciones simultáneas:

• Fuerza a la IA a construir el contexto que le faltaba, pero anclándose en el código real y no en invenciones.
• Te da un punto de control: si el resumen está mal, lo detectas de inmediato y no confías en las críticas posteriores.

El prompt del tour pide explícitamente que la IA devuelva la responsabilidad principal del módulo, las entradas que recibe y de dónde vienen, las salidas que produce y quién las consume, las dependencias internas o externas, el flujo principal paso a paso y los supuestos que está infiriendo [02:00].

Qué reglas hacen que el tour sea confiable

Las reglas del prompt son lo que impide que la IA se salga del código. Estas son las restricciones que marcan la diferencia:

• No inventar contexto fuera del archivo.
• No reportar bugs todavía en esta fase.
• Decir explícitamente cuando algo no puede saberse solo por el código.
• Citar funciones o líneas cuando el código las haga visibles.

Al final se agrega una sección llamada punto de control con una lista corta de cosas que tú debes confirmar antes de pedir hallazgos [02:31]. Ese tour no es un adorno, es la barrera que evita confiar en una crítica construida sobre contexto inventado.

Cómo pedir hallazgos anclados a líneas reales

Una vez verificado el tour, recién ahí pides la auditoría. El segundo prompt le indica buscar bugs, riesgos de rendimiento y problemas de seguridad, siempre sobre la base ya construida [03:26].

Las reglas obligatorias de esta fase son igual de estrictas:

• Cada hallazgo debe citar una línea o un rango de líneas reales del archivo.
• Si no puede citar la línea, no incluye el hallazgo.
• No repetir problemas generales de arquitectura que no sean accionables en este archivo.
• Priorizar hallazgos que puedan demostrarse con una prueba o una medición.

El formato de salida exige categoría, severidad, líneas, la evidencia visible en el código, el riesgo y el siguiente paso. El resultado es un reporte enumerado, citado por línea, breve y replicable [03:56].

¿Cómo evito que la IA reporte bugs falsos? Exige que cada hallazgo cite una línea real del archivo. Si no puede citar la línea, no incluye el hallazgo. Sin evidencia, no hay reporte.

Recuerda que la misión aquí no es corregir los hallazgos en este momento. Es asegurar que estén bien especificados para que el equipo los arregle correctamente después.

Por qué conviene acotar la ventana de contexto

Pedirle a la IA que busque bugs en 3.000 líneas casi siempre devuelve problemas de arquitectura viejos que no hay tiempo de arreglar hoy. La solución es la revisión diferencial [04:30].

En lugar de auditar el archivo completo, acotas su ventana de contexto y le entregas solo el diff. Puedes preguntarle, por ejemplo, cuál es el cambio de mayor riesgo en los últimos 30 días de commits.

Esto logra tres cosas:

• La IA prioriza por riesgo reciente, que es donde suelen estar los bugs frescos.
• Reduce drásticamente las alucinaciones causadas por exceso de información.
• Enfoca el esfuerzo del equipo en lo accionable hoy.

¿Qué es una revisión diferencial con IA? Es auditar solo los cambios recientes de código, como el diff de los últimos 30 días, en vez del archivo completo. Prioriza bugs frescos y baja el ruido.

El principio se resume así: inicias con un tour, generas evidencias citadas siempre y haces una revisión diferencial para priorizar por riesgos recientes. Con eso auditas código desconocido sin alimentar la alucinación.

Encontrar un bug una vez no basta, porque sin memoria automatizada ese error puede volver a colarse con otro nombre. ¿Cómo convertirías cada hallazgo puntual en una barrera permanente? Cuéntame en los comentarios cómo auditas tú tus módulos legacy.