Cambiar una firma de función y actualizar sus 40 llamadas manualmente es el tipo de trabajo que Composer elimina de tu día. Así se usa bien.
El chat de Cursor responde preguntas y sugiere cambios que aplicas archivo por archivo. Composer (accesible con Cmd/Ctrl + I) opera en modo agente: recibe un objetivo, decide qué archivos necesita leer y modificar, genera un plan de cambios across todo el repositorio, y presenta un diff consolidado antes de aplicar nada. La diferencia clave es que Composer puede crear archivos nuevos, borrar código en múltiples ubicaciones y ejecutar comandos de terminal (si le das permiso) como parte del mismo flujo.
Un caso real: renombrar un campo user_id a account_id en toda la base de código porque el modelo de datos cambió de "usuarios" a "cuentas" multi-usuario.
Composer identifica los archivos relevantes usando el índice del repo, muestra qué va a tocar antes de escribir, y respeta exclusiones explícitas como la de la tabla de auditoría. Esa exclusión explícita es importante: sin ella, es común que el modelo generalice de más y toque algo que no debía.
Composer muestra una lista de archivos que va a modificar antes de tocar nada, con un resumen de la intención por archivo. Nunca aceptes el plan completo a ciegas en un refactor grande; revisa por lo menos:
- Si toca archivos de configuración o .env que no deberían cambiar. - Si el conteo de archivos afectados coincide con lo que esperabas (si esperabas 6 y toca 20, algo generalizó de más). - Si incluye archivos de migración con nombres duplicados o timestamps conflictivos, un problema común en Laravel/Rails cuando dos desarrolladores generan migraciones el mismo día.
Cada aplicación de Composer queda como un punto que puedes revertir independientemente del historial de git, útil cuando el refactor sale mal a medio camino. Aun así, la práctica recomendada es trabajar sobre una rama limpia y hacer commit antes de invocar Composer en cambios grandes — así tienes reversión de git como respaldo real, no solo el historial interno de Cursor.
Para refactors que cruzan capas (backend y frontend a la vez), sé explícito sobre qué archivos incluir en el contexto usando @ para referenciar archivos o carpetas puntuales, en vez de confiar en que la indexación automática encuentre todo. Esto es especialmente importante en monorepos con múltiples paquetes, donde el índice puede priorizar el paquete equivocado.
Composer brilla en refactors mecánicos y coordinados, pero no es la herramienta correcta para decisiones de diseño ambiguas ("¿deberíamos usar Redis o Postgres para esta cola?"). Ahí conviene usar el chat normal para discutir opciones primero, y reservar Composer para la ejecución una vez que la decisión está tomada. Mezclar exploración de diseño con ejecución en el mismo prompt produce planes inconsistentes porque el modelo intenta decidir y ejecutar al mismo tiempo.
Trata la salida de Composer como el primer borrador de un pull request, no como el resultado final. Ejecuta linters, tests y git diff completos antes de hacer push. En equipos con CI, es buena práctica requerir que cualquier PR con cambios generados mayormente por Composer incluya en la descripción qué prompt se usó, para que el revisor entienda la intención original del cambio y pueda evaluar si el resultado se ajusta a ella.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel