Si quieres acelerar tu desarrollo front-end sin perder horas en configuración, el agente de Cursor te permite delegar tareas como crear types, consumir endpoints y generar estilos a partir de un repositorio base en Next.js 15. Aquí verás cómo aprovecharlo paso a paso, con errores reales incluidos, para que tu primera landing conectada a una API funcione tal como la imaginas.
¿Qué estructura inicial necesitas para empezar con Cursor?
El punto de partida es un lienzo en blanco montado sobre Next.js 15 con App Router. Sobre esa base se instala la librería de Sass para hacer el build de los estilos y se prepara una carpeta Styles con dos archivos clave [0:31].
- Un archivo reset que normaliza los estilos entre navegadores para que tu diseño se vea igual en todos lados.
- Un archivo
Vars vacío, listo para variables que usarás más adelante.
- Una carpeta
Source donde vivirá toda la lógica del proyecto.
Esta limpieza inicial importa porque el agente trabaja mejor cuando tu repositorio tiene convenciones claras. Si tu estructura está ordenada, sus propuestas también lo estarán.
¿Cómo delegar la creación de types al agente de Cursor?
La primera tarea inteligente es generar los types de TypeScript desde el acuerdo con el backend. Esto te da seguridad de avanzar sin romper el contrato de datos [1:05].
El flujo es directo: creas una carpeta Types dentro de Source, abres el chat en modo agente y le indicas que extraiga los types desde un documento que arrastras al chat. También arrastras la carpeta destino para que el agente sepa exactamente dónde guardarlos [1:30].
¿Qué es el modo agente en Cursor? Es un modo del chat que ejecuta tareas sobre tu código, crea archivos y propone cambios que tú apruebas o rechazas antes de aplicarlos.
En el ejemplo, el agente genera un archivo index con interfaces para course, class, course details, progress, quiz y favorite. Los cambios aparecen resaltados en verde para distinguir el código nuevo del existente, y tú decides si aceptas o rechazas [2:00].
¿Cómo conectar un endpoint y mostrar datos en la página?
La segunda tarea consiste en consumir un endpoint local y renderizar una lista de cursos como tarjetas. Antes de escribir el prompt, conviene cerrar archivos abiertos para que no contaminen el contexto del nuevo chat [2:38].
El prompt debe incluir varios elementos para que el agente acierte:
- La URL del endpoint, en este caso
localhost:8000/courses.
- El archivo
page arrastrado al chat para indicar dónde escribir el código.
- El diseño esperado, por ejemplo un título principal
Platzi Fix y tarjetas para cada curso.
- El stack: Next.js 15, App Router, CSS Modules y validación con TypeScript.
¿Cómo le doy contexto preciso a un agente de Cursor? Arrastra y suelta archivos o carpetas dentro del chat. El agente los toma como referencia obligatoria y reduce errores de ubicación o de tipado.
¿Qué errores comete el agente y cómo corregirlos?
Aquí viene lo interesante. En la primera ejecución, el agente crea una nueva interfaz course.ts por fuera de Source, ignorando los types que ya existían. Esto ensucia la estructura del proyecto [3:45].
La solución tiene dos caminos. Puedes rechazar los cambios, mover manualmente la carpeta al lugar correcto y pedirle al agente que borre la duplicada. O puedes iterar el prompt indicándole explícitamente dónde viven tus types antes de empezar [4:30].
Al repetir el ejercicio con el contexto corregido, el agente ya no duplica interfaces y entrega la página y los estilos. Pero aparece un segundo error al abrir localhost:3000: el mensaje dice que los cursos no se pueden mapear porque no son una función [5:50].
Revisando el código, el agente hace el fetch y la conversión a JSON correctamente, pero intenta iterar directamente sobre la respuesta. El problema es que la API devuelve un objeto con una propiedad data que contiene el array real. La corrección manual es mínima [6:20]:
- Guardar la respuesta en una variable
data.
- Iterar sobre
data.data en lugar de la respuesta cruda.
¿Debo corregir manualmente o pedirle al agente que arregle el error? Si el error es evidente y rápido, corrígelo tú. Si requiere reescribir lógica, itera el prompt explicando qué falló y qué esperabas.
¿Por qué la previsualización de cambios cambia tu flujo de trabajo?
La función de aceptar o rechazar cambios convierte al agente en un colaborador, no en un piloto automático. Cada propuesta queda visible en verde y tú validas si encaja con tu visión del proyecto [2:15].
Esto significa que aprender a leer el código generado es tan importante como escribir buenos prompts. Cuando el agente se equivoca, tu capacidad de detectar la falla determina si avanzas en minutos o pierdes horas debugueando.
El resultado final muestra una landing con título Platzi Fix, tarjetas estilizadas y los tres cursos que retorna la API. Todo construido con prompts iterativos, contexto arrastrado al chat y dos correcciones puntuales [7:30].
¿Te animas a crear tu propia landing de cursos siguiendo este flujo? Cuéntanos en los comentarios si tu agente acertó a la primera o también te tocó corregir como en este caso.