Skip to main content
1

Define el problema y los criterios de éxito

Tu API de checkout (POST /api/checkout) tiene una latencia p99 de 1,8 segundos: los usuarios están abandonando sus carritos de compra y tu objetivo de SLA es de 400 ms. Hay varias formas válidas de abordar esto: caché, optimización de consultas, procesamiento asíncrono, pool de conexiones. No sabes cuál funcionará mejor hasta que las pruebes, y probarlas de forma secuencial significa días de espera.En vez de eso, pídele a Devin que lance 3 sesiones en paralelo, cada una explorando una estrategia diferente. Cuando las 3 hayan terminado, Devin compara los resultados y publica la solución ganadora, o combina las mejores partes de cada una en un único PR.Para comenzar, abre una nueva sesión de Devin desde la página de inicio de Devin y describe la tarea por lotes.
2

Redacta un prompt que oriente cada sesión hacia una corrección diferente

El valor de ejecutar 3 sesiones depende de que cada una explore un enfoque realmente diferente. Escribe tu prompt para fomentar la divergencia: sugiere estrategias específicas y define qué significa “mejor” para que los resultados sean directamente comparables.Consejos para un buen prompt de múltiples estrategias:
  • Define “mejor” con criterios ordenados. Enumerar dimensiones de comparación — latencia, tasa de errores, complejidad, consistencia — evita que Devin se limite por defecto únicamente a la velocidad bruta.
  • Sugiere estrategias específicas. Opciones como “caching, query rewriting, async processing” orientan cada sesión hacia un camino diferente.
  • Incluye un comando de benchmark. Cada sesión necesita una forma reproducible de medir su propio resultado — npm run bench, k6 run load-test.js o un simple bucle con curl.
  • Señala el código. Una ruta de archivo como src/routes/checkout.ts garantiza que las 3 sesiones comiencen desde el mismo lugar.
3

Compara los resultados y selecciona al ganador

Una vez que se completen las 3 sesiones, Devin revisa su trabajo comparándolo lado a lado según tus criterios — estrategias utilizadas, métricas de referencia, trade-offs — y o bien elige la mejor opción o sintetiza una solución combinada en un PR final.Así es como se ve esa comparación para el problema de latencia en el checkout:
Sesión 1 — Caché de respuestas con Redis
  Estrategia: Caché de carrito serializado + consultas de inventario en Redis con
              TTL de 30s, omitir DB en solicitudes repetidas
  p99:        1.8s -> 320ms  (APROBADO — reducción del 82%)
  Errores:    Sin cambios
  Complejidad: +1 dependencia (ioredis), 2 archivos nuevos
  Compromiso: Datos de inventario desactualizados hasta 30s; 40MB de memoria Redis

Sesión 2 — Optimización de consultas + pool de conexiones
  Estrategia: Se reemplazaron las consultas N+1 con un único JOIN, se añadió
              PgBouncer como pool de conexiones (25 conexiones)
  p99:        1.8s -> 580ms  (FALLIDO — aún por encima de 400ms)
  Errores:    Sin cambios
  Complejidad: 0 dependencias nuevas, consultas más limpias
  Compromiso: Ninguno significativo — menor carga en la DB en general

Sesión 3 — Procesamiento asíncrono de pedidos
  Estrategia: Se trasladó el procesamiento de pagos y el correo a una cola en segundo plano
              (BullMQ), devuelve 202 inmediatamente tras la verificación de inventario
  p99:        1.8s -> 190ms  (APROBADO — reducción del 89%)
  Errores:    Sin cambios
  Complejidad: +1 dependencia (bullmq), 3 archivos nuevos, manejador de webhook
  Compromiso: El checkout pasa a ser eventualmente consistente; requiere webhook
              para confirmación de pago

Veredicto: Las sesiones 1 y 3 cumplen el objetivo de 400ms. Las correcciones
de consultas de la sesión 2 son valiosas pero insuficientes por sí solas.

PR final: Se combinó la optimización de consultas de la sesión 2 (sin coste, estrictamente
mejor) con el procesamiento asíncrono de la sesión 3. Pagos + correo trasladados a
la cola, consultas N+1 corregidas. p99 final: 150ms. PR #412 abierto.
Puedes revisar los PR individuales de cada sesión antes de que Devin cree el PR combinado. Si ya prefieres un enfoque en particular, solo dile a Devin: “quédate con el enfoque de la Sesión 3, omite la combinación.”
4

Cuándo hacer competir 3 estrategias en un mismo problema

Buen encaje — existen múltiples enfoques válidos:
  • Cuellos de botella de rendimiento donde podrían funcionar tanto el uso de caché como la optimización de consultas o cambios de arquitectura
  • Decisiones de arquitectura con compromisos reales (extracción de un monolito, rediseño de la gestión de estado)
  • Selección de algoritmos para un problema intensivo en datos (diferentes enfoques de indexación, ranking o ML)
Mal encaje — la solución es obvia:
  • Correcciones de errores con una causa raíz clara
  • Agregar un endpoint CRUD estándar
  • Actualizar dependencias o archivos de configuración
Este patrón utiliza 3 veces los ACUs de una sola sesión. Resérvalo para problemas en los que, de otro modo, pasarías días probando enfoques de forma secuencial. Para tareas sencillas, una sola sesión de Devin es más rápida y económica.También puedes lanzar sesiones en paralelo a través de la API configurando advanced_mode como batch, lo cual es útil para integrarlas en pipelines de CI que prueban automáticamente múltiples correcciones frente a una regresión de rendimiento. Si quieres que Devin se ejecute de forma completamente autónoma sin esperar tu aprobación sobre las propuestas, habilita la opción bypass permissions para que las sesiones se aprueben automáticamente y sigan avanzando.