Disclaimer: Esto no es un post enteramente escrito por mi. Es un texto condensado a partir de las respuestas que me dio Cursor AI mientras conversabamos.

Intro

Hola. Hace unos días decidí experimentar trabajando con Cursor AI y dejando que hiciera la mayor cantidad del trabajo posible sin que yo interviniera más que para dar instrucciones. Muy pronto descubrí 4 cosas:

  1. El reto de pensar los pasos y soluciones no te lo ahorras, más bien ese se vuelve tu principal responsabilidad.
  2. La IA hace muy bien el trabajo duro de escritura de código, y es capaz de tomar decisiones bien enfocadas y delimitadas.
  3. No solo se trata de dar instrucciones, también hay que escuchar
  4. Nos volvemos un equipo de 2, así que el eje principal es la comunicación. Entre mejor comunicación y claridad tengamos el uno con el otro, ambos somos más conscientes de lo que está pasando.

🤔 ¿Hay a estas alturas una metodología o técnica que nos permita trabajar lo mejor posible con nuestro aliado virtual? La verda, lo desconozco. No he leído artículos "serios" pero sí que he recibido consejos de colegas que ya han estado trabajando de esta manera desde hace algún tiempo. Además, le he pedido al mismo Cursor AI que me diera recomendaciones para hacerme entender mejor. Esto es lo que me ha dicho:

🤖 Cursor AI: Para ayudarme a entender mejor tus requerimientos
y ser más efectivo, te sugiero seguir estas pautas:

Estructura recomendada para las Instrucciones: 

Objetivo: [Descripción clara del objetivo]
Contexto: [Información relevante del sistema/componente]
Requisitos: [Lista de requisitos específicos]
Restricciones: [Limitaciones o consideraciones especiales]

Como yo le solicito las cosas al empezar a trabajar en la feature: 

Hola. Vamos a crear un endpoint nuevo en el proyecto. 

El objetivo es implementar un nuevo endpoint que cubra el caso de uso de actualización parcial del usuario.

Antes de empezar, analiza el módul "auth" en el que implementé la creación de usuarios. Pon atención al estilo y patrón: 

el controlador de express está en infrastructure/routes. Este se encarga preparar los colaboradores para pasarlos al servicio de aplicación. En application se realiza la de verificación de existencia del usuario, verificación del payload, persistencia de datos a través del userRepository, respuesta del resultado y gestión de errores

Los requisitos son:
- Crear endpoint patch /users/:id
- Actualización parcial del usuario y su perfil
- Mantener los datos existentes no incluidos en el payload
- Validar datos


Restricciones:
- Realizar los nuevos cambios en el módulo de users
- Gestionar errores usando custom exceptions. Agregar nuevas si es necesario o reutilizar las existentes si es apropiado
- No intentes corregir errores de eslint
- Usa el mismo estilo que se ha usado para el signup y signin

Orden de los cambios:
Primero realiza los cambios nucleares en el repository y finalmente la ruta de express

A partir de ahí voy haciendo las correcciones, ajustes y siguientes pasos con instrucciones más pequeñas.

Ejemplo de una Solicitud Bien Estructurada según Cursor AI (un poco excesivo para mi gusto, pero funciona): 

Objetivo: Implementar endpoint PATCH para actualización parcial de usuarios

Contexto:
- Módulo de users
- Seguir patrones existentes del módulo de auth
- Implementar actualización parcial (PATCH)
- Mantener consistencia con la arquitectura actual

Requisitos:
1. Endpoint PATCH /users/:id
2. Actualización parcial de datos del usuario y su perfil
3. Solo el ID es requerido en el payload
4. Mantener datos existentes no incluidos en el payload
5. Implementar validación de datos
6. Seguir el patrón de manejo de errores existente

Estructura de Datos:
Payload esperado (todos los campos son opcionales excepto id):
{
  "id": string,
  "fullName": string,
  "email": string,
  "phone": string,
  "status": "active" | "inactive" | "banned",
  "onlineStatus": "online" | "offline" | "away"
}

Componentes a Modificar/Crear:
1. Interface UserRepository:
   - Añadir método update(user: User): Promise

2. PrismaUserRepository:
   - Implementar método update
   - Manejar actualización parcial de datos
   - Mantener datos existentes

3. Routes:
   - Crear endpoint PATCH
   - Implementar validación de datos
   - Manejar errores

4. Validators:
   - Crear schema de validación para actualización parcial

Restricciones:
- Mantener la estructura de dominios actual
- Seguir el patrón de manejo de errores existente
- Validar datos según reglas de negocio
- Mantener la consistencia de datos

Consideraciones Técnicas:
- Usar el mismo patrón de manejo de errores que auth
- Mantener la separación de responsabilidades
- Seguir el patrón de validación existente
- Implementar logs para debugging

¿Podrías proceder con la implementación siguiendo este orden:
1. Interface y Repository
2. Validator
3. Route
4. Tests

Esta estructura me ayuda a:

  • Entender claramente el alcance del cambio
  • Identificar los componentes que necesito modificar
  • Mantener la consistencia con el código existente
  • Seguir el patrón de arquitectura actual
  • Implementar la funcionalidad de manera incremental

Para Describir Cambios o Nuevas Funcionalidades:

  • Antes: "Quiero que hagas X"
  • Mejor: "Necesito implementar X porque [razón] y debe cumplir con [requisitos específicos]"

Para Reportar Problemas:

  • Antes: "No funciona el endpoint"
  • Mejor: "El endpoint /api/auth/signin devuelve error 500 cuando [condición específica]"

Para Solicitar Mejoras:

  • Antes: "Hazlo más rápido"
  • Mejor: "Necesito optimizar el rendimiento del endpoint X para manejar Y peticiones por segundo"

Para Manejar Complejidad:

  • Dividir las tareas grandes en subtareas
  • Especificar el orden de prioridad
  • Indicar dependencias entre componentes

Para Validar Cambios:

  • Proporcionar ejemplos de casos de uso
  • Especificar el comportamiento esperado
  • Indicar cómo probar los cambios

Para Contexto Técnico:

  • Mencionar versiones de dependencias relevantes
  • Indicar restricciones de infraestructura
  • Especificar patrones de diseño a seguir

Para Decisiones de Arquitectura:

  • Proporcionar contexto del sistema actual
  • Mencionar consideraciones de escalabilidad
  • Indicar restricciones de rendimiento

Para Manejo de Errores:

  • Describir el comportamiento actual
  • Especificar el comportamiento deseado
  • Proporcionar logs o ejemplos de error

Para Testing:

  • Especificar casos de prueba
  • Indicar cobertura esperada
  • Mencionar tipos de pruebas necesarias

Ideas finales

Iré actualizando esto según entienda mejor cómo trabajar de esta manera. Son nuevos tiempos. Una nueva manera de hacer las cosas, y deberíamos usar esto a nuestro favor antes de que alguien lo vuelva hacia nuestra contra.

Si tienes consejos, correcciones y observaciones, por favor compartelas :)