Saltar al contenido principal
Asegúrate de leer Cuándo usar Devin e Instrucciones efectivas para Devin para más consejos esenciales.

Agregar un nuevo endpoint de API

Enfoque correcto
“Crea un nuevo endpoint /users/stats que devuelva un objeto JSON con el número de usuarios y la edad promedio al registrarse. Usa nuestra tabla existente users en PostgreSQL. Puedes usar el endpoint /orders/stats en statsController.js como referencia para la estructura de las respuestas. Asegúrate de que el nuevo endpoint esté cubierto por la suite StatsController.test.js.”
Por qué funciona:
  • Especifica claramente la ruta y el formato de respuesta esperado
  • Hace referencia a código existente como plantilla
  • Define la fuente de datos (tabla de usuarios)
  • Incluye requisitos de cobertura de pruebas


Enfoque incorrecto
“Agrega un endpoint de estadísticas de usuarios.”
Por qué falla:
  • No especifica qué estadísticas incluir
  • No menciona las fuentes de datos
  • No hace referencia a patrones existentes
  • No indica requisitos de pruebas

Funcionalidad de frontend para mostrar datos

Enfoque correcto
“En UserProfileComponent, agrega un menú desplegable que muestre una lista de roles de usuario (admin, editor, viewer). Usa los estilos de DropdownBase. Cuando se seleccione un rol, llama a la API existente para establecer el rol del usuario. Valida comprobando que la selección actualice el rol del usuario en la base de datos. Consulta tu Knowledge para saber cómo probarlo correctamente.”
Por qué funciona:
  • Nombra componentes específicos
  • Enumera exactamente los roles que se deben incluir
  • Hace referencia a un componente de estilos existente
  • Define el flujo de interacción del usuario
  • Incluye pasos de validación


Enfoque incorrecto
“Haz que la página de perfil de usuario sea más fácil de usar. Agrega alguna forma de que puedan cambiar de rol y confirma que funciona.”
Por qué falla:
  • “Fácil de usar” es subjetivo
  • No se mencionan componentes específicos de UI
  • El flujo de interacción del usuario no está claro
  • Los criterios de validación son vagos

​
Más ejemplos

​
Bueno

Escribir pruebas unitarias

“Agrega pruebas de Jest para los métodos de AuthService: login y logout. Asegúrate de que la cobertura de pruebas para estas dos funciones sea de al menos el 80 %. Usa UserService.test.js como ejemplo. Después de la implementación, ejecuta npm test -- --coverage y verifica que el informe de cobertura muestre >80 % para ambas funciones. Confirma también que las pruebas pasen tanto con credenciales válidas como inválidas, y que logout borre correctamente los datos de sesión.”
¿Por qué es bueno? Métrica de éxito clara (80 % de cobertura), referencias para guiar a Devin (UserService.test.js) y un alcance bien definido con pasos específicos de verificación.

Migrar o refactorizar código existente

“Migra logger.js de JavaScript a TypeScript. Ya tenemos un tsconfig.json y una suite de pruebas LoggerTest.test.js para validación. Asegúrate de que compile sin errores y no cambies la configuración existente. Después de la migración, verifica: 1) ejecutando tsc para confirmar que no hay errores de tipo, 2) ejecutando la suite de pruebas con npm test LoggerTest.test.js para asegurar que todas las pruebas pasen, y 3) comprobando que todas las llamadas existentes a los métodos del logger en todo el código base sigan funcionando sin errores de tipo.”
¿Por qué es bueno? Hay una plantilla clara (tsconfig.json) y una suite de pruebas para feedback inmediato, además de pasos específicos de compilación y validación.

Actualizar APIs o consultas de base de datos

“Estamos pasando de pg a sequelize (consulta https://sequelize.org/api/v6/identifiers). Actualiza las consultas de UserModel para usar métodos de Sequelize. Consulta OrderModel para ver cómo lo hacemos en este código base. Después de la implementación, verifica: 1) ejecutando npm run test:integration UserModel.test.js para comprobar que todas las pruebas de integración pasen, 2) confirmando que el rendimiento de las consultas no se haya degradado revisando el tiempo de ejecución en un conjunto de datos de prueba de 1000 usuarios, y 3) validando que todas las operaciones CRUD sigan manteniendo la integridad de los datos ejecutando npm run test:e2e user-flows.test.js.”
¿Por qué es bueno? Devin puede imitar un patrón conocido y hay referencias explícitas (OrderModel.js). Se proporciona un enlace a la documentación para que Devin sepa que debe consultarla, e incluye pasos específicos de verificación de rendimiento y funcionalidad con comandos de prueba exactos.

​
Malos ejemplos

Revisión de código abierta

“Encuentra problemas en nuestra base de código y arréglalos”
¿Por qué es malo? La solicitud es demasiado vaga y le pide a Devin que complete demasiadas tareas en una sola sesión. Devin puede confundirse en sesiones largas.

Tareas de diseño visual

“Crea exactamente lo que se muestra en este diseño de Figma”
¿Por qué es malo? Este es un encargo visual subjetivo. Devin no puede “ver” como lo hacen los humanos y no captará los detalles a la perfección. No está optimizado para estos casos de uso.

Proyectos muy complejos y vagos

“Crea una nueva arquitectura de microservicios para nuestra aplicación.”
¿Por qué es malo? Esta es una tarea muy grande y no estructurada. Requiere decisiones de arquitectura y compromisos.En su lugar, divide los proyectos complejos en fases:
  1. Haz que Devin analice tu base de código
  2. Pídele a Devin que proponga arquitecturas específicas
  3. Crea sesiones separadas para implementar cada parte