Darle libertad total a Cursor para generar una feature completa en Android es un experimento revelador: con un solo prompt bien acotado y archivos de contexto, el agente puede crear folders, packages, vistas, repositorios y hasta tests. Esta guía muestra cómo estructurar ese prompt, qué revisar después y dónde aparecen los errores típicos cuando delegas la generación de código a una IA.

Cómo armar un prompt efectivo para que Cursor genere una feature

El primer paso es preparar el contexto. En lugar de ir paso a paso como en iteraciones anteriores, aquí la idea es entregar reglas claras y dejar que el agente razone.

Dentro de Cursor, con el chat abierto y el agente habilitado usando Claude 4 Sonnet, el prompt base fue: Genera la feature de listar cursos para mi app con sus respectivos files, folders y packages. A partir de ahí se suman las reglas de contexto.

• Arquitectura definida en el archivo de Clean Architecture.
• Entidades y requests HTTP tomadas del archivo de contratos.
• Generación de UI, composables y pantallas guiada por un prompt específico de diseño.
• Diseños de referencia: course list view para la pantalla y course card view para cada ítem de la lista.

¿Qué archivos de contexto necesita Cursor para generar una feature completa? Tres como mínimo: el de arquitectura (Clean Architecture), el de contratos con entidades y requests HTTP, y un prompt de UI con imágenes de referencia para las vistas.

Qué genera Cursor cuando le das libertad total

Tras enviar el prompt y pedirle continuar al alcanzar el límite del agente, el resumen final mostró bastante más de lo solicitado. Algunos extras fueron bienvenidos, otros conviene controlarlos.

• Tests unitarios sin haberlos pedido, lo cual es útil pero recomendable diferir hasta probar el flujo principal.
• README con documentación de la feature.
• Gradle modificado con las dependencias necesarias, incluyendo retrofit.
• Manifest actualizado con los permisos requeridos.
• MainActivity ajustada con su preview y la vista principal de la app.

También creó un repositorio con Mock Data y un módulo que, en desarrollo, apuntaba a esos datos mock. Para validar el servicio real conviene cambiarlo de inmediato y usar el Remote Course Repository con el API service generado.

Cómo quedó organizada la arquitectura generada

La estructura respeta las capas de Clean Architecture y se reparte así:

• Capa de UI: composables para loading, mensajes de error y cards, además de ajustes al sistema de diseño con los colores definidos en el prompt.
• ViewModels: manejan el estado de la UI con flows y scopes, y disparan el load en el init (un punto a optimizar para evitar recargas innecesarias en recomposiciones).
• Capa de data: repositorio remoto, API service con retrofit haciendo GET, módulo de network con la base URL, mappers y data classes con sus @SerializedName correctamente anotados.
• Capa de dominio: interfaces del repositorio y data classes propias del dominio.

Por qué fallan algunas piezas y cómo se detectan

Después de aceptar los cambios hay que cerrar Cursor y abrir Android Studio para ejecutar Sync Now y que Gradle baje las dependencias nuevas. Recién entonces aparecen los errores reales.

En esta corrida saltaron dos problemas concretos en la vista de lista de cursos:

• La variable isRefreshing no estaba declarada, aunque el composable la usaba.
• Algunos nested scrolls referenciados no estaban definidos.

¿Por qué Cursor genera código con errores aunque el resumen diga que todo está listo? Porque el agente compone piezas a partir del contexto pero no compila el proyecto. Errores de variables no declaradas o imports faltantes solo aparecen al sincronizar Gradle y correr el build en Android Studio.

¿Conviene aceptar todos los cambios que propone Cursor de una vez? No siempre. Acepta los archivos de configuración y estructura, pero revisa tests y datos mock antes de fijarlos, porque suelen necesitar ajustes manuales o un nuevo prompt.

Qué revisar antes de confiar en el código generado

Delegar la generación completa funciona, pero exige una revisión activa. Estos son los puntos críticos donde detenerse:

• Cambiar el repositorio por defecto de Mock Data al Remote Course Repository si vas a probar el servicio real.
• Validar que los tests unitarios cubran lo que realmente quieres testear, no lo que la IA decidió cubrir.
• Revisar la lógica del init en los ViewModels para evitar recargas innecesarias en cada recomposición.
• Verificar que los mappers y @SerializedName coincidan con los contratos reales.
• Confirmar que el sistema de diseño y los colores aplicados respeten el prompt de UI.

Cuando aparezcan errores como los de isRefreshing o los nested scrolls, tienes dos caminos: arreglarlos tú mismo o pedirle a Cursor que los resuelva, ya con el código entendido. ¿Tú qué harías primero, leer todo el código generado o lanzarlo al build y dejar que el compilador te guíe?