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.

Implementar una funcionalidad a partir de un diseño

“Implementa la página de precios a partir de este archivo de Figma: https://figma.com/file/abc123/Pricing-Page. Concéntrate en el frame ‘Pricing Section’. Usa nuestra configuración de Tailwind en tailwind.config.ts para colores y espaciado. Reutiliza los componentes Card y Button existentes de src/components/ui/. Después de implementar, inicia el servidor de desarrollo y toma capturas de pantalla en anchos de escritorio (1440px) y móvil (375px). No abras un PR hasta que coincida con el diseño.”
¿Por qué es bueno? Vincula el archivo específico de Figma, nombra el frame exacto, hace referencia al sistema de diseño del proyecto y a los componentes existentes, y le indica a Devin que verifique visualmente su trabajo antes de abrir un PR. Con el Figma MCP conectado, Devin puede leer los design tokens directamente del archivo.

Investigar un error en producción

“Los usuarios están reportando errores 500 en la página de checkout. Usa el Sentry MCP para obtener los últimos stack traces del proyecto payments-api. Revisa la base de datos para detectar posibles problemas de datos relacionados. Encuentra la causa raíz, corrígelo y agrega una prueba de regresión. Incluye el enlace al issue de Sentry en la descripción del PR.”
¿Por qué es bueno? Dirige a Devin a las herramientas correctas (integraciones MCP), proporciona un camino claro de investigación y define el entregable esperado (corrección + prueba de regresión + PR).

​
Malo

Revisión de código abierta e indefinida

“Encuentra problemas en nuestra base de código y arréglalos”
¿Por qué es malo? La solicitud es demasiado vaga y abierta. No hay criterios de éxito ni forma de que Devin sepa cuándo ha terminado.En su lugar: Usa Devin Review para revisión de código automatizada en PRs específicos, o dale a Devin una tarea concreta como “Encuentra y corrige todos los usos de la API obsoleta oldLogger en src/services/.”

Solicitudes visuales puramente subjetivas

“Haz que la landing page se vea mejor”
¿Por qué es malo? “Mejor” es subjetivo y Devin no tiene criterios con los que guiarse. Devin puede construir interfaces funcionales e implementar diseños a partir de especificaciones, pero no puede hacer juicios estéticos por sí solo.En su lugar: Proporciona un diseño de Figma, un sitio de referencia o cambios específicos: “Aumenta el tamaño de fuente de la sección hero a 48px, añade 32px de padding y usa el color indigo-500 de nuestra configuración de Tailwind.”

Proyectos muy complejos y vagos

“Crea una nueva arquitectura de microservicios para nuestra app.”
¿Por qué es malo? Esta es una tarea muy grande y poco estructurada. Requiere muchas decisiones de arquitectura, compromisos y contexto que no está en el prompt.En su lugar, divídelo:
  1. Usa Ask Devin para investigar tu base de código y mapear dependencias
  2. Pídele a Devin que proponga arquitecturas específicas con sus compromisos
  3. Crea sesiones separadas para implementar cada servicio y ejecútalas en paralelo con batch sessions