Não quer configurar isso manualmente? Cole um link para esta página em uma sessão do Devin e peça para ele configurar tudo para você. Sua API de checkout (`POST /api/checkout`) tem uma latência p99 de 1,8 segundos — os usuários estão abandonando os carrinhos e sua meta de SLA é 400 ms. Há várias maneiras válidas de resolver isso: cache, otimização de consultas, processamento assíncrono, connection pooling. Você não sabe qual vai funcionar melhor até experimentar, e testar cada opção em sequência significa esperar dias. Em vez disso, peça ao Devin para iniciar 3 sessões em paralelo, cada uma explorando uma estratégia diferente. Depois que as 3 terminarem, o Devin compara os resultados e faz o deploy da vencedora — ou combina as melhores partes de cada uma em um único PR. Para começar, abra uma nova sessão do Devin na [página inicial do Devin](https://app.devin.ai/?utm_source=docs\&utm_medium=use-case-gallery) e descreva a tarefa em lote. O benefício de rodar 3 sessões depende de cada uma explorar uma abordagem genuinamente diferente. Escreva seu prompt para incentivar a divergência — sugira estratégias específicas e defina o que "melhor" significa para que os resultados sejam diretamente comparáveis. ```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. ``` **Dicas para um bom prompt com múltiplas estratégias:** * **Defina "melhor" com critérios ordenados.** Listar dimensões de comparação — latência, taxa de erro, complexidade, consistência — impede Devin de dar preferência apenas à velocidade bruta. * **Sugira estratégias específicas.** Opções como "caching, query rewriting, async processing" orientam cada sessão para um caminho diferente. * **Inclua um comando de benchmark.** Cada sessão precisa de uma forma reprodutível de medir seu próprio resultado — `npm run bench`, `k6 run load-test.js` ou um simples loop com curl. * **Aponte para o código.** Um caminho de arquivo como `src/routes/checkout.ts` garante que todas as 3 sessões comecem do mesmo lugar. Assim que as três sessões forem concluídas, o Devin revisa o trabalho de cada uma lado a lado com base nos seus critérios — estratégias usadas, métricas de benchmark, trade-offs — e então escolhe a melhor ou sintetiza uma solução combinada em uma PR (pull request) final. Veja como fica essa comparação para o problema de latência no checkout: ``` Sessão 1 — Cache de resposta com Redis Estratégia: Armazenar em cache o carrinho serializado + consultas de estoque no Redis com TTL de 30s, ignorar o BD em requisições repetidas p99: 1,8s -> 320ms (APROVADO — redução de 82%) Erros: Sem alteração Complexidade: +1 dependência (ioredis), 2 novos arquivos Tradeoff: Dados de estoque desatualizados por até 30s; 40MB de memória Redis Sessão 2 — Otimização de consultas + pool de conexões Estratégia: Substituídas consultas N+1 por um único JOIN, adicionado pool de conexões PgBouncer (25 conexões) p99: 1,8s -> 580ms (REPROVADO — ainda acima de 400ms) Erros: Sem alteração Complexidade: 0 novas dependências, consultas mais limpas Tradeoff: Nenhum significativo — menor carga no BD no geral Sessão 3 — Processamento assíncrono de pedidos Estratégia: Processamento de pagamento e e-mail movidos para uma fila em segundo plano (BullMQ), retorna 202 imediatamente após verificação de estoque p99: 1,8s -> 190ms (APROVADO — redução de 89%) Erros: Sem alteração Complexidade: +1 dependência (bullmq), 3 novos arquivos, handler de webhook Tradeoff: O checkout passa a ser eventualmente consistente; requer webhook para confirmação de pagamento Veredicto: As sessões 1 e 3 atingem a meta de 400ms. As correções de consulta da sessão 2 são valiosas, mas insuficientes por si só. PR Final: Combinada a otimização de consultas da sessão 2 (sem custo, estritamente melhor) com o processamento assíncrono da sessão 3. Pagamento + e-mail movidos para fila, consultas N+1 corrigidas. p99 final: 150ms. PR #412 aberto. ``` Você pode revisar os PRs de cada sessão antes que o Devin crie o PR combinado. Se preferir uma abordagem logo de cara, basta dizer ao Devin — "use a abordagem da Sessão 3 e ignore a combinação." **Bom uso — existem várias abordagens válidas:** * Gargalos de desempenho em que cache, ajuste de consultas e mudanças de arquitetura poderiam funcionar * Decisões de arquitetura com trade‑offs reais (extração de monólito, redesenho do gerenciamento de estado) * Escolha de algoritmo para um problema intensivo em dados (diferentes abordagens de indexação, ranqueamento ou ML) **Mau uso — a solução é óbvia:** * Correções de bugs com causa raiz clara * Adicionar um endpoint CRUD padrão * Atualizar dependências ou arquivos de configuração Esse padrão usa 3x os [ACUs](/pt-BR/admin/billing/usage) de uma única sessão. Reserve-o para problemas em que você passaria dias testando abordagens de forma sequencial. Para tarefas simples, uma única sessão do Devin é mais rápida e barata. Você também pode acionar sessões paralelas [via a API](/pt-BR/api-reference/v3/sessions/post-organizations-sessions) definindo `advanced_mode` como `batch` — útil para integrar em pipelines de CI que automaticamente testam várias correções em paralelo diante de uma regressão de desempenho. Se quiser que o Devin seja executado de forma totalmente autônoma, sem esperar sua aprovação sobre propostas, habilite a opção **bypass permissions** para que as sessões aprovem automaticamente e continuem avançando.

{title}