Skip to main content

Corrija a latência do checkout com três estratégias concorrentes

Execute 3 sessões paralelas do Devin em uma corrida contra uma API de checkout lenta — cada uma tenta uma otimização diferente e, em seguida, a melhor abordagem é enviada para produção.
AuthorCognition
CategoryOtimização com Devin
FeaturesAvançado
1

Defina o problema e os critérios de sucesso

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, use o Advanced Devin para iniciar 3 sessões em paralelo, cada uma explorando uma estratégia diferente. Depois que as 3 terminarem, o Advanced 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, selecione Advanced no seletor de agentes na página inicial do Devin e clique na aba Start Batch Sessions.
2

Escreva um prompt que oriente cada sessão para uma correção diferente

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.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.
3

Compare os resultados e escolha o vencedor

Assim que as três sessões forem concluídas, o Advanced 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 Advanced Devin crie o PR combinado. Se preferir uma abordagem específica, basta dizer ao Devin — “use a abordagem da Sessão 3 e ignore a combinação.”
4

Quando executar 3 estratégias concorrentes para resolver um único problema

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 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 em lote via a API 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.