Saltar al contenido principal
Lo más importante que debes recordar al darle instrucciones a Devin es ser lo más específico posible. Del mismo modo que proporcionarías una especificación detallada al pedirle a un compañero de trabajo que programe algo, deberías hacer lo mismo con Devin. Esta guía te ayudará a estructurar tus instrucciones/prompts para usar Devin de forma eficaz. Para conocer estrategias más generales sobre cómo trabajar de forma eficaz con agentes de código, consulta también nuestra guía Coding Agents 101.

​
Cómo redactar prompts eficaces

A continuación se muestra un ejemplo de prompt que demuestra una instrucción eficaz:
En el repositorio de Devin, quiero que desarrolles una herramienta que supervise el uso de RAM y CPU de las máquinas remotas en las que se ejecuta Devin. Para ello, realiza las siguientes tareas:
  • Crea una tarea en segundo plano que se inicie automáticamente cuando se inicie devin.rs.
  • La tarea debe abrir una conexión a todas las máquinas remotas generadas mediante fork que se usen en esta sesión de Devin y supervisar su uso de RAM y CPU.
  • Si el uso supera el 80% de los recursos disponibles, emite un nuevo tipo de evento de Devin para indicarlo (revisa cómo usamos Kafka).
  • Diseña esto de forma inteligente, de modo que no bloquee otras operaciones. Debes entender cómo interactúan entre sí todos los contenedores de los subagentes de Devin.

​
Por qué esto funciona bien

Proporciona contexto útil

  • Detalle: Especifica el repositorio de Devin y el propósito más amplio (monitorear el uso de recursos).
  • Beneficio: Devin conoce claramente el alcance y el dominio.

Da instrucciones paso a paso

  • Detalle: Tareas como “crear una tarea en segundo plano” y “emitir un evento al 80 % de uso”.
  • Beneficio: Divide el trabajo en partes lógicas.

Define criterios de éxito claros

  • Detalle: Define el “éxito” como emitir un evento específico cuando se alcance el 80 % de uso.
  • Beneficio: Devin sabe exactamente qué debe lograr.

Hace referencia a patrones y código existentes

  • Detalle: Menciona Kafka e interacciones con contenedores.
  • Beneficio: Fomenta la reutilización de código o enfoques de diseño ya establecidos.

​
Buenas prácticas: lo que se debe y lo que no se debe hacer

Haz esto: proporciona instrucciones claras
  • Por qué: Devin puede atascarse sin un camino claro o cuando se enfrenta a demasiadas posibles interpretaciones.
  • Cómo:
    • Toma tú las decisiones importantes y los juicios de valor por Devin.
    • Ofrece opciones de diseño concretas y estrategias de implementación específicas.
    • Define con claridad el alcance, los límites y los criterios de éxito.
  • Ejemplo: “Optimize the getOrderDetails query in orderService.js by adding a composite index on the order_id and product_id columns in the order_items table. Refactor the query to replace the existing correlated subquery with a JOIN to the products table for fetching product details.”
No hagas esto: dejar decisiones abiertas
  • Por qué: Las instrucciones vagas pueden llevar a que Devin implemente soluciones que no se alineen con tus necesidades reales.
  • Cómo:
    • Evita enunciados que requieran que Devin tome decisiones de diseño o implementación significativas sin orientación. Esto puede generar resultados inesperados.
  • Ejemplo: No hagas esto: “Improve our database’s performance.”
Haz: Elige tareas en las que Devin es bueno
  • Por qué:
    • Maximiza los resultados: Al asignar tareas que se alinean con las capacidades de Devin, puedes obtener los mejores resultados con el menor esfuerzo y la menor cantidad de ACUs posible.
  • Cómo:
    • Lee esta guía: Cuándo usar Devin
    • Proporciona ejemplos, módulos, recursos y plantillas que Devin pueda seguir.
      • Comparte enlaces directos a sitios de documentación para que Devin pueda leer detalles como los cuerpos de las solicitudes de API y funcionalidades que podría no conocer.
      • Comparte nombres de archivos específicos que quieras que Devin revise y de los que aprenda.
    • Conecta las integraciones MCP para darle a Devin acceso a diseños de Figma, bases de datos, herramientas de monitoreo y más.
    • Ejemplo: Haz: “Refactoriza la gestión de estado en el componente Header para usar el hook useReducer de React y lograr mejor escalabilidad y mantenibilidad. Asegúrate de que se preserve toda la funcionalidad existente y agrega pruebas unitarias para cubrir la nueva lógica de estado.”
    • Ejemplo: Haz: “Usa authTemplate.rs como referencia para mantener la coherencia en el manejo de errores.”
    • Ejemplo: Haz: “Revisa la documentación oficial de Sequelize en https://sequelize.org/docs/v6/getting-started/ para los pasos de migración.”
No hagas: Omitir el contexto para tareas complejas
  • Por qué: Aunque Devin puede encargarse de trabajo complejo, rinde mejor cuando le proporcionas contexto y una dirección clara.
  • Cómo:
    • Para tareas que requieren conocimiento del dominio, proporciona documentación, ejemplos o referencias relevantes.
    • Para tareas visuales, proporciona archivos de Figma a través del Figma MCP, diseños de referencia o especificaciones detalladas: Devin puede construir a partir de esto, pero no va a inventar la estética por sí solo.
    • Para aplicaciones móviles, ten en cuenta que Devin no tiene acceso a un emulador de teléfono, así que proporciona criterios de prueba claros.
  • Ejemplo: No hagas: “Make the app look better” — en su lugar, proporciona especificaciones de diseño concretas o un archivo de Figma.
  • Ejemplo: No hagas: “Improve our database’s performance.” — en su lugar, especifica qué consultas optimizar y qué métricas quieres mejorar.
Haz esto: establece comprobaciones claras y frecuentes
  • Por qué: Los comentarios frecuentes (tanto tuyos como de pruebas/verificaciones/linters) garantizan que Devin corrija los errores de forma eficaz.
  • Cómo:
    • Usa pruebas (unitarias/de integración) para confirmar la corrección.
    • Mantén validaciones de compilación, comprobaciones de lint y análisis estático para asegurar la calidad del código.
    • Activa Devin Review con Auto-Fix para que Devin responda automáticamente a los comentarios de revisión de código y a los fallos de CI, creando un ciclo cerrado en el que los PR iteran hasta alcanzar una calidad lista para hacer merge sin que tengas que intervenir.
  • Ejemplo: Haz esto: “Run npm test after each iteration.”
  • Ejemplo: Haz esto: “Ensure the pipeline on CircleCI doesn’t fail.”
  • Ejemplo: Haz esto: “Pass ESLint/Prettier checks before pushing any commits.”
No hagas esto: descuidar la retroalimentación
  • Por qué: Sin comentarios, Devin no sabrá si sus soluciones cumplen con tus estándares.
  • Cómo:
    • Evita asignar tareas sin definir cómo las evaluarás.
Haz esto: define puntos de control y subtareas claras
  • Por qué: Dividir tareas complejas en subtareas y puntos de control más pequeños ayuda a que Devin se mantenga concentrado y reduce los errores.
  • Cómo:
    • Divide las tareas en subtareas verificables e inicia una sesión de Devin para cada subtarea.
    • Define qué se considera éxito para cada subtarea y, opcionalmente, establece puntos de control dentro de cada una.
    • Pídele a Devin que te informe al completar cada punto de control o subtarea.
Ejemplos:
  • Ejemplo: Haz esto: “Al trabajar con el conjunto de datos, verifica que tenga al menos 500 filas y contenga las columnas X, Y, Z.”
  • Ejemplo: Haz esto: “Al modificar la API, confirma que el endpoint devuelva el código de estado 200 e incluya todos los campos requeridos.”
  • Ejemplo: Haz esto: “Al actualizar la UI, comprueba que el componente se renderice sin errores en la consola y que coincida con la especificación de diseño.”
No hagas esto: no te saltes requisitos de validación específicos
  • Por qué: Sin pasos de validación definidos, Devin no puede dar por completadas las tareas con seguridad.
  • Cómo:
    • Evita criterios de éxito vagos.
    • No dejes los pasos de verificación implícitos o sin definir.
  • Ejemplo: No hagas esto: “Asegúrate de que funcione.”
Devin tiene un entorno de escritorio completo — shell, IDE y navegador. Indícale a Devin que pruebe su propio trabajo antes de abrir un PR:
  • Inicia la aplicación: “Run npm run dev and verify the new page renders at /settings.”
  • Pruebas en el navegador: “Open the browser, navigate to the login page, and confirm the OAuth flow completes successfully.”
  • Verificación visual: “Take screenshots at desktop (1440px) and mobile (375px) widths and confirm the layout matches the design.”
  • Grabación de pantalla: “Record yourself testing the checkout flow end-to-end.”
Esto permite que Devin realice el control de calidad (QA) de sus cambios de la misma forma que tú lo harías, antes de que tengas que revisar el PR.
Para tareas repetitivas o complejas, recomendamos usar e iterar con los Playbooks. Obtén más información sobre cómo usar playbooks de forma eficaz. Los playbooks son prompts reutilizables y compartibles que optimizan la delegación de tareas. Por ejemplo, si quieres que Devin se encargue de fallos recurrentes en los builds de CI, crea un playbook que incluya los pasos generales que Devin debe seguir cada vez.Para contexto persistente que Devin deba recordar en todas las sesiones —como estándares de codificación, errores comunes y sus soluciones, flujos de despliegue o cómo usar herramientas internas— usa Knowledge. Los elementos de Knowledge se recuperan automáticamente cuando son relevantes, así que no necesitas repetir las mismas instrucciones en cada prompt. Puedes fijar Knowledge a repos específicos o aplicarlo de forma global.
Playbooks vs. Knowledge: Usa Playbooks para procedimientos paso a paso vinculados a tareas específicas. Usa Knowledge para consejos generales, convenciones y contexto que se apliquen de forma general entre sesiones.