How to Refactoriza tu base de código with Eigent

How it works

1. Pídele a Eigent que mapee el área antes de editar — módulos ruidosos, lógica duplicada, código no utilizado y patrones obsoletos.
2. Elige una sola temática de limpieza a la vez — elimina código no utilizado, simplifica el flujo de control, moderniza un patrón obsoleto o divide un archivo grande.
3. Antes de que Eigent aplique parches a los archivos, haz que indique el comportamiento actual, la mejora estructural y la verificación mínima que demuestre que el comportamiento se mantuvo estable.
4. Revisa y ejecuta la verificación más pequeña útil después de cada pasada en lugar de agrupar toda la limpieza en un solo diff.
5. Mantén los cambios de stack, las migraciones de dependencias y los movimientos de arquitectura como tareas separadas, salvo que sean necesarios para completar la limpieza.

More prompts to try

• ¿Qué archivos en esta área tienen más código muerto o exports no utilizados?
• Identifica todos los lugares donde se duplica la misma lógica y propone un único punto de consolidación.
• ¿Qué patrones heredados en este módulo entran en conflicto con las convenciones actuales del repositorio?
• Divide este archivo demasiado grande en piezas más pequeñas y claramente asignadas sin cambiar su API pública.

How to use

Comienza pidiéndole a Eigent que mapee el área desordenada — identificará las oportunidades de limpieza de mayor valor antes de tocar cualquier código. Trabaja una temática a la vez y revisa cada diff antes de seguir. Usa tu suite de pruebas o CI como verificación después de cada pasada. Si Eigent propone una migración de stack o un cambio de dependencia, márcalo como una tarea separada y mantén el refactor actual enfocado solo en la estructura.

Expected output

Un plan de limpieza priorizado, una serie de pequeños diffs focalizados (uno por pasada) y un resumen de validación para cada pasada que muestre qué se cambió y qué verificación confirma que el comportamiento es estable.

Limitations

• Funciona mejor cuando el área tiene una suite de pruebas existente o contratos de comportamiento claros contra los que validar.
• Los monorrepos grandes se benefician de delimitar el alcance a un servicio o módulo a la vez.
• Los cambios de arquitectura, las actualizaciones de runtime y las migraciones de framework deben ser tareas separadas — mezclarlos con la refactorización hace que los diffs no sean revisables.