Pular para o conteúdo principal
A coisa mais importante a ter em mente ao instruir o Devin é ser o mais específico possível. Assim como você forneceria uma especificação detalhada ao pedir a um colega para programar algo, você deve fazer o mesmo com o Devin. Este guia ajudará você a estruturar suas instruções/prompts para usar o Devin de forma eficaz. Para estratégias mais amplas sobre como trabalhar com agentes de código de forma eficaz, confira também nosso guia Coding Agents 101.

​
Como escrever prompts eficazes

Aqui está um exemplo de prompt que demonstra como dar instruções eficazes:
No repositório do Devin, quero que você crie uma ferramenta que monitore o uso de RAM e CPU das máquinas remotas nas quais o Devin é executado. Para fazer isso, execute as seguintes tarefas:
  • Crie uma tarefa em segundo plano que seja iniciada automaticamente quando o devin.rs for iniciado.
  • A tarefa deve abrir uma conexão com todas as máquinas remotas criadas por fork usadas nesta sessão do Devin e monitorar o uso de RAM e CPU delas.
  • Se o uso exceder 80% do recurso disponível correspondente, emita um novo tipo de evento do Devin para sinalizar isso (verifique como usamos o Kafka).
  • Projete isso de forma inteligente, de modo que não bloqueie outras operações. Você deve entender como todos os contêineres dos subagentes do Devin interagem entre si.

​
Por que Isso Funciona Bem

Fornece Contexto Útil

  • Detalhe: Especifica o repositório do Devin e o propósito mais amplo (monitorar o uso de recursos).
  • Benefício: Devin entende claramente o escopo e o domínio.

Fornece Instruções Passo a Passo

  • Detalhe: Tarefas como “create a background task” e “emit an event at 80% usage”.
  • Benefício: Divide o trabalho em partes lógicas.

Define Critérios Claros de Sucesso

  • Detalhe: Define “success” como emitir um evento específico ao atingir 80% de uso.
  • Benefício: Devin sabe exatamente o que precisa alcançar.

Faz Referência a Padrões e Código Existentes

  • Detalhe: Menciona Kafka e interações com contêineres.
  • Benefício: Incentiva a reutilização de código ou abordagens de design já estabelecidas.

​
Boas práticas: o que fazer e o que evitar

Faça: Forneça orientações claras
  • Por quê: Devin pode ficar travado sem um caminho claro ou quando se depara com muitas interpretações possíveis.
  • Como:
    • Tome decisões importantes e faça julgamentos em nome do Devin.
    • Ofereça escolhas de design específicas e estratégias de implementação.
    • Defina claramente o escopo, os limites e os critérios de sucesso.
  • Exemplo: “Otimize a consulta getOrderDetails em orderService.js adicionando um índice composto nas colunas order_id e product_id na tabela order_items. Refatore a consulta para substituir a subconsulta correlacionada existente por um JOIN com a tabela products para buscar os detalhes dos produtos.”
Não faça: Deixar decisões em aberto
  • Por quê: Instruções vagas podem levar o Devin a implementar soluções que não atendem às suas necessidades reais.
  • Como:
    • Evite instruções que exijam que o Devin tome decisões significativas de design ou implementação sem orientação. Isso pode levar a resultados inesperados.
  • Exemplo: Não faça: “Melhore a performance do nosso banco de dados.”
Faça: Escolha tarefas em que o Devin é bom
  • Por que:
    • Maximize os resultados: Ao atribuir tarefas que se alinham às capacidades do Devin, você obtém os melhores resultados com o mínimo esforço e ACUs gastos.
  • Como:
    • Leia este guia: Quando usar o Devin
    • Forneça exemplos, módulos, recursos e templates que o Devin possa seguir.
      • Compartilhe links diretos para sites de documentação para que o Devin possa ler detalhes como corpos de requisição de API e funcionalidades que ele talvez não conheça.
      • Compartilhe nomes de arquivos específicos que você quer que o Devin analise e aprenda com eles.
    • Conecte integrações MCP para dar ao Devin acesso a designs do Figma, bancos de dados, ferramentas de monitoramento e mais.
    • Exemplo: Faça: “Refatore o gerenciamento de estado no componente Header para usar o hook useReducer do React para melhor escalabilidade e manutenibilidade. Garanta que toda a funcionalidade existente seja preservada e adicione testes unitários para cobrir a nova lógica de estado.”
    • Exemplo: Faça: “Use authTemplate.rs como referência para manter a consistência no tratamento de erros.”
    • Exemplo: Faça: “Confira a documentação oficial do Sequelize em https://sequelize.org/docs/v6/getting-started/ para as etapas de migração.”
Não faça: Deixar de fornecer contexto para tarefas complexas
  • Por que: Embora o Devin consiga lidar com trabalhos complexos, ele tem o melhor desempenho quando você fornece contexto e orientação clara.
  • Como:
    • Para tarefas que exigem conhecimento de domínio, forneça documentação, exemplos ou referências relevantes.
    • Para tarefas visuais, forneça arquivos do Figma via Figma MCP, designs de referência ou especificações detalhadas — o Devin pode construir a partir disso, mas não vai inventar a estética por conta própria.
    • Para aplicativos móveis, lembre-se de que o Devin não tem acesso a um emulador de celular, então forneça critérios claros de teste.
  • Exemplo: Não faça: “Deixe o app com uma aparência melhor” — em vez disso, forneça especificações de design específicas ou um arquivo do Figma.
  • Exemplo: Não faça: “Melhore a performance do nosso banco de dados” — em vez disso, especifique quais queries otimizar e quais métricas devem ser atingidas.
Faça: estabeleça verificações claras e frequentes
  • Por que: feedback frequente (tanto seu quanto de testes/checks/linters) garante que o Devin corrija erros de forma eficaz.
  • Como:
    • Use testes (unitários/de integração) para confirmar se estão corretos.
    • Mantenha validações de build, verificações de lint e análise estática para garantir a qualidade do código.
    • Ative o Devin Review com Auto-Fix para que o Devin responda automaticamente a comentários de revisão e a falhas de CI — criando um ciclo fechado em que os PRs evoluem até atingirem qualidade pronta para merge, sem que você precise intervir.
  • Exemplo: Faça: “Execute npm test após cada iteração.”
  • Exemplo: Faça: “Garanta que o pipeline no CircleCI não falhe.”
  • Exemplo: Faça: “Passe nas verificações do ESLint/Prettier antes de fazer qualquer commit.”
Não faça: deixar de fornecer feedback
  • Por que: sem feedback, o Devin não saberá se as soluções dele atendem aos seus padrões.
  • Como:
    • Evite atribuir tarefas sem definir como você vai avaliá-las.
Faça: Defina checkpoints e subtarefas claros
  • Por que: Dividir tarefas complexas em checkpoints menores ajuda o Devin a manter o foco e reduz erros.
  • Como:
    • Divida as tarefas em subtarefas verificáveis e inicie uma sessão do Devin para cada subtarefa.
    • Defina o que caracteriza sucesso para cada subtarefa e, opcionalmente, estabeleça checkpoints dentro de cada subtarefa.
    • Peça que o Devin retorne após concluir cada checkpoint ou subtarefa.
Exemplos:
  • Exemplo: Faça: “Ao trabalhar com o conjunto de dados, verifique que ele tenha pelo menos 500 linhas e contenha as colunas X, Y, Z.”
  • Exemplo: Faça: “Ao modificar a API, confirme que o endpoint retorna status 200 e inclui todos os campos obrigatórios.”
  • Exemplo: Faça: “Ao atualizar a UI, verifique que o componente renderiza sem erros no console e corresponda à especificação de design.”
Não faça: Deixar de definir requisitos específicos de validação
  • Por que: Sem etapas de validação definidas, o Devin não consegue concluir tarefas com segurança.
  • Como:
    • Evite critérios de sucesso vagos.
    • Não deixe etapas de verificação implícitas ou indefinidas.
  • Exemplo: Não faça: “Garanta que está funcionando.”
O Devin possui um ambiente de desktop completo — shell, IDE e navegador. Peça que o Devin teste o próprio trabalho antes de abrir um PR:
  • Suba o app: “Execute npm run dev e verifique se a nova página é renderizada em /settings.”
  • Teste no navegador: “Abra o navegador, navegue até a página de login e confirme que o fluxo de OAuth é concluído com sucesso.”
  • Verificação visual: “Tire screenshots em larguras de desktop (1440px) e mobile (375px) e confirme que o layout corresponde ao design.”
  • Gravação de tela: “Grave a tela enquanto você testa o fluxo de checkout de ponta a ponta.”
Isso permite que o Devin faça QA das alterações da mesma forma que você faria — antes mesmo de você precisar analisar o PR.
For tarefas repetitivas ou complexas, recomendamos usar e iterar sobre Playbooks. Saiba mais sobre como usar playbooks de forma eficaz. Playbooks são prompts reutilizáveis e compartilháveis que simplificam a delegação de tarefas. Por exemplo, se você quiser que o Devin lide com falhas recorrentes em builds de CI, crie um playbook que inclua as etapas gerais que o Devin deve seguir sempre.Para contexto persistente que o Devin deve manter em todas as sessões — como padrões de código, bugs comuns e suas correções, fluxos de implantação ou como usar ferramentas internas — use Knowledge. Itens de Knowledge são recuperados automaticamente quando relevantes, então você não precisa repetir as mesmas instruções em cada prompt. Você pode fixar Knowledge a repositórios específicos ou aplicá-lo globalmente.
Playbooks vs. Knowledge: Use Playbooks para procedimentos passo a passo vinculados a tarefas específicas. Use Knowledge para dicas gerais, convenções e contexto que se aplicam amplamente ao longo das sessões.