Utilidades IACómo entender código heredado con ayuda de la IA
| Para quién | Para quien se incorpora a un proyecto existente, recupera una aplicación antigua o debe modificar un programa escrito por otra persona sin apenas documentación. |
|---|---|
| Tiempo estimado | Entre 1 y 3 horas para entender un módulo mediano, repartidas en varias sesiones. |
| Categoría | Programación y datos |
Paso a paso
- Obtén primero una visión de conjunto
Antes de leer funciones sueltas, reúne lo que haya: estructura de carpetas, archivos de configuración, dependencias, scripts de arranque y cualquier nota. Pide al asistente que, a partir de esa lista de archivos y no del contenido completo, proponga un mapa probable: qué hace cada carpeta, dónde parece estar el punto de entrada y qué piezas son externas. Trata ese mapa como una hipótesis que irás confirmando. Sin una idea del conjunto, es fácil perderse en detalles que luego resultan irrelevantes. - Protege secretos y datos antes de compartir código
Revisa el código buscando contraseñas, claves, direcciones internas, datos de clientes y comentarios con información sensible, y sustitúyelos por marcadores. Comprueba también que tienes permiso para compartir ese código con un servicio externo, ya que puede pertenecer a un cliente o a tu empleador. Si la política no lo permite, utiliza una herramienta autorizada o describe la estructura con tus palabras. Es mucho más fácil evitar la filtración al principio que intentar remediarla después de haber pegado el código. - Pide explicaciones por fragmentos pequeños
Pega una función o una clase cada vez, con el contexto mínimo necesario, e indica el lenguaje y la versión. Pide una explicación en tres niveles: qué hace en una frase, cómo lo hace paso a paso y qué entradas y salidas tiene. Solicita que marque expresamente lo que no pueda saber sin ver otras partes. Los fragmentos largos favorecen resúmenes vagos o inventados. Anota las explicaciones en tus propios términos: si no puedes reformularlas, todavía no las has comprendido. - Contrasta cada explicación ejecutando el código
Una explicación convincente puede ser falsa. Comprueba cada afirmación importante con una prueba: ejecuta la función con entradas conocidas, añade trazas temporales, usa un depurador o escribe un test que fije el comportamiento actual. Presta atención a los efectos secundarios, como escrituras en archivos, llamadas a servicios o cambios en variables compartidas. Hazlo en un entorno de pruebas con datos ficticios y copias, nunca sobre producción. Lo que verificas en ejecución es lo único que puedes dar por cierto. - Detecta riesgos y deuda técnica
Pide al asistente una lista de posibles problemas del fragmento: dependencias obsoletas, falta de gestión de errores, entradas sin validar, código duplicado o acoplamientos fuertes. Después, valida cada punto por tu cuenta, porque puede señalar falsos problemas o pasar por alto otros reales. Para cuestiones de seguridad, no te conformes con su revisión: usa herramientas de análisis y, si el software maneja datos sensibles, consulta a alguien con experiencia. Prioriza lo que afecta a la estabilidad antes que lo meramente estético. - Documenta lo aprendido y protégelo con pruebas
Convierte lo comprobado en documentación útil: un esquema del flujo principal, un glosario de nombres confusos y una lista de peculiaridades conocidas. Añade pruebas que fijen el comportamiento actual antes de modificar nada, para detectar roturas al refactorizar. Pide al asistente que redacte comentarios o un borrador de documentación, y revisa que cada frase refleje lo que el código hace de verdad. Esa documentación será el mayor beneficio duradero de todo el esfuerzo y evitará repetirlo en el futuro.
Prompt de ejemplo
Completa los corchetes con datos de tu caso, nunca con información confidencial:
Actúa como ingeniero sénior que me ayuda a entender código que no escribí. Lenguaje y versión: [LENGUAJE Y VERSIÓN]. Contexto del proyecto: [DESCRIPCIÓN BREVE]. Te pego la función [NOMBRE] (sin claves ni datos reales): [CÓDIGO]. Explícamelo en tres niveles: una frase de resumen, los pasos que sigue, y sus entradas, salidas y efectos secundarios. Después enumera posibles riesgos o comportamientos sorprendentes. Distingue claramente lo que se deduce del código pegado de lo que solo supones sin ver otras partes. No inventes el contenido de funciones que no te he mostrado y avísame de cualquier duda.
Qué esperar
Recibirás explicaciones claras y ordenadas, útiles para orientarte. También es probable que incluyan suposiciones presentadas con seguridad, nombres de funciones externas interpretados por su apariencia y algún riesgo inexistente. Cuanto menos contexto aportes, más rellenará el asistente con conjeturas.
Cómo verificar el resultado
- Ejecuta el fragmento con entradas conocidas en un entorno de pruebas y compara el resultado con la explicación.
- Busca en el código real todas las llamadas a las funciones que el asistente da por sabidas.
- Escribe un test que fije el comportamiento actual antes de modificar nada.
- Contrasta los riesgos señalados con herramientas de análisis o con un compañero con experiencia.
Errores comunes
- Pegar archivos enteros con claves, datos de clientes o código que no tienes permiso para compartir.
- Aceptar la explicación sin ejecutar el código para comprobarla.
- Modificar el código sin haber fijado antes su comportamiento actual con pruebas.
- Probar cambios directamente sobre producción o con datos reales.
Riesgos y límites
El asistente solo ve lo que pegas y puede inventar el contenido de lo que no ve, interpretar mal nombres engañosos o describir con seguridad un comportamiento que el código no tiene. Las explicaciones pueden estar desfasadas respecto a la versión real del lenguaje o de las bibliotecas. Compartir código ajeno puede vulnerar acuerdos de confidencialidad o licencias. En software que afecte a la seguridad de personas, a dinero o a datos sensibles, toda modificación debe revisarla un profesional cualificado y probarse a fondo antes de usarse.
Preguntas frecuentes
¿Puedo confiar en que la explicación sea correcta?
Úsala como hipótesis. El asistente puede equivocarse, sobre todo con código ambiguo o con dependencias que no ve. Compruébala ejecutando el código con entradas conocidas y contrastando los resultados antes de basar ningún cambio en ella.
¿Qué hago si el código es demasiado grande?
Divídelo por módulos y avanza de lo general a lo concreto: estructura, punto de entrada, flujo principal y después funciones concretas. Pegar demasiado a la vez produce resúmenes vagos y aumenta el riesgo de exponer información sensible.
¿Es legal compartir código de mi trabajo con un asistente?
Depende de tu contrato, de la licencia del código y de la política de tu empresa. Si no estás seguro, consúltalo con tu responsable o con asesoría jurídica antes de pegarlo, o utiliza únicamente las herramientas que tu organización haya autorizado.