¿No quieres configurarlo manualmente? Pega un enlace a esta página en una sesión de Devin y pídele que lo configure todo por ti. 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](https://app.devin.ai/?utm_source=docs\&utm_medium=use-case-gallery) y describe la tarea por lotes. 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. ```txt Fix checkout latency — 3 competing strategies theme={null} Our checkout API (POST /api/checkout in src/routes/checkout.ts) has a p99 latency of 1.8s. We need it under 400ms. Start 3 parallel sessions. Each should: 1. Profile the endpoint to find bottlenecks (run `npm run bench:checkout`) 2. Pick a DIFFERENT optimization strategy — e.g., caching, query optimization, async processing, connection pooling, or denormalization 3. Implement the optimization 4. Re-run the benchmark and report the new p99 Comparison criteria — rank each result by: - p99 latency (must be under 400ms to pass) - Error rate (must not increase) - Code complexity added (fewer new dependencies = better) - Data consistency tradeoffs (document any eventual-consistency risks) Once all 3 finish, compare the results using the criteria above and create a final PR that uses the best approach — or combines ideas from multiple sessions if that gets us lower latency. ``` **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. 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." **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](/es/admin/billing/usage) 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](/es/api-reference/v3/sessions/post-organizations-sessions) 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.

{title}