Ejemplo: refactorizar un módulo grande · Agentes de IA para programar

Los prompts de ejemplo son ilustrativos; los comandos están verificados contra la documentación oficial.

Escenario: billing_service.py ha crecido hasta unas 1.500 líneas y hay que partirlo. Los refactors grandes fracasan cuando el agente se pone a editar de inmediato. El patrón: planificar primero, cambiar de forma incremental y ejecutar los tests entre pasos.

El flujo

Mapear las responsabilidades del módulo y quién depende de él.
Entrar en modo plan o de solo lectura y acordar una estrategia de partición antes de tocar nada.
Extraer una responsabilidad cada vez.
Ejecutar la suite de tests entre cada paso; parar en rojo.
Revisar el diff completo al final.

Claude Code

Arranca en modo plan para que la exploración se quede en solo lectura:

claude --permission-mode plan

Analiza billing_service.py y quién depende de él. Propón una partición en
módulos enfocados (facturación, pagos, reembolsos). La API pública no puede
cambiar. Itera el plan conmigo antes de tocar ningún archivo.

Aprueba el plan para salir del modo plan y luego impón el ciclo incremental por prompt:

Ejecuta el plan paso a paso. Después de cada extracción ejecuta
`pytest tests/billing/` — si algo falla, para y repórtalo en vez de seguir.

El modo de permisos acceptEdits (Shift+Tab rota los modos) acepta solo las ediciones de archivos pero sigue preguntando por el resto de herramientas — muy útil en un refactor mecánico largo. /rewind devuelve el código y la conversación a un checkpoint si un paso sale mal.

Termina con /diff y /code-review:

/code-review medium

Codex

Explora primero con un sandbox de solo lectura (el preset Read Only):

codex --sandbox read-only --ask-for-approval on-request

Mapea billing_service.py: sus responsabilidades, sus funciones públicas y
todos los archivos que lo importan.

Y luego pásate al modo plan:

/plan Diseña una partición de billing_service.py en módulos de facturación,
pagos y reembolsos. Conserva la API pública. Ordena los pasos para que la
suite de tests siga en verde después de cada uno.

Implementa bajo workspace-write, un paso verificado cada vez:

codex --sandbox workspace-write --ask-for-approval on-request

Ejecuta el plan de forma incremental: una extracción por paso, ejecuta
`pytest tests/billing/` después de cada una y para ante cualquier fallo.

Revisa el diff acumulado con /diff y luego pasa /review sobre el árbol de trabajo (o codex review --uncommitted desde el shell).

Kimi Code

Arranca en modo plan — Write/Edit quedan limitados al archivo del plan hasta que lo apruebes:

kimi --plan

Analiza billing_service.py y todo lo que lo importa. Escribe un plan para
partirlo en módulos de facturación, pagos y reembolsos sin cambiar la API
pública. Los pasos tienen que poder testearse por separado.

Aprobar el plan (ExitPlanMode siempre pide confirmación) desbloquea las ediciones. Después trabaja de forma incremental — el modo Ask When Needed evita que las ediciones rutinarias y las tandas de tests pregunten:

/yolo

Ejecuta el plan extracción a extracción. Ejecuta `pytest tests/billing/`
después de cada paso; si falla, para y enséñame la salida.

Ve comprobando el diff sobre la marcha con el modo shell:

!git diff --stat

Ojo: el /undo de Kimi Code revierte prompts y estado del plan, no los cambios de código — para deshacer ediciones, tira de git (por ejemplo !git checkout -- <archivo>).

Relacionado

Flujos de Claude Code: Claude Code — Flujos de trabajo
Flujos de Codex: Codex CLI — Flujos de trabajo
Flujos de Kimi Code: Kimi Code — Flujos de trabajo
Tablas de referencia rápida: Cheatsheet de las tres herramientas

Última verificación: 2026-09-07

Las herramientas de IA para programar evolucionan rápido. Si encuentras información desactualizada, abre un issue o un pull request.