> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Buenas vs. Malas Instrucciones

> Qué funciona y qué no

<Note>Asegúrate de leer [Cuándo usar Devin](/es/essential-guidelines/when-to-use-devin) e [Instrucciones efectivas para Devin](/es/essential-guidelines/instructing-devin-effectively) para más consejos esenciales.</Note>

<CardGroup cols={1}>
  <Card title="Agregar un nuevo endpoint de API" icon="server">
    **Enfoque correcto**

    <Check>
      "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`."
    </Check>

    **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

    <br />

    ***

    <br />

    **Enfoque incorrecto**

    <Warning>
      "Agrega un endpoint de estadísticas de usuarios."
    </Warning>

    **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
  </Card>

  <Card title="Funcionalidad de frontend para mostrar datos" icon="window">
    **Enfoque correcto**

    <Check>
      "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."
    </Check>

    **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

    <br />

    ***

    <br />

    **Enfoque incorrecto**

    <Warning>
      "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."
    </Warning>

    **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
  </Card>
</CardGroup>

<div id="more-examples">
  ## Más ejemplos
</div>

<div id="good">
  ### Bueno
</div>

<CardGroup cols={1}>
  <Card title="Escribir pruebas unitarias" icon="vial">
    <Check>
      "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."
    </Check>

    **¿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.
  </Card>

  <Card title="Migrar o refactorizar código existente" icon="code-branch">
    <Check>
      "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."
    </Check>

    **¿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.
  </Card>

  <Card title="Actualizar APIs o consultas de base de datos" icon="database">
    <Check>
      "Estamos pasando de pg a sequelize (consulta [https://sequelize.org/api/v6/identifiers](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`."
    </Check>

    **¿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.
  </Card>

  <Card title="Implementar una funcionalidad a partir de un diseño" icon="paintbrush">
    <Check>
      "Implementa la página de precios a partir de este archivo de Figma: [https://figma.com/file/abc123/Pricing-Page](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."
    </Check>

    **¿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](/es/work-with-devin/mcp) conectado, Devin puede leer los design tokens directamente del archivo.
  </Card>

  <Card title="Investigar un error en producción" icon="bug">
    <Check>
      "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."
    </Check>

    **¿Por qué es bueno?** Dirige a Devin a las herramientas correctas ([integraciones MCP](/es/work-with-devin/mcp)), proporciona un camino claro de investigación y define el entregable esperado (corrección + prueba de regresión + PR).
  </Card>
</CardGroup>

<div id="bad">
  ### Malo
</div>

<CardGroup cols={1}>
  <Card title="Revisión de código abierta e indefinida" icon="magnifying-glass">
    <Warning>
      "Encuentra problemas en nuestra base de código y arréglalos"
    </Warning>

    **¿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](/es/work-with-devin/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/`."
  </Card>

  <Card title="Solicitudes visuales puramente subjetivas" icon="palette">
    <Warning>
      "Haz que la landing page se vea mejor"
    </Warning>

    **¿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."
  </Card>

  <Card title="Proyectos muy complejos y vagos" icon="sitemap">
    <Warning>
      "Crea una nueva arquitectura de microservicios para nuestra app."
    </Warning>

    **¿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](/es/work-with-devin/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 [Devins gestionados](/es/work-with-devin/advanced-capabilities#managed-devins)
  </Card>
</CardGroup>