Pular para o conteúdo principal
Certifique-se de ler Quando Usar o Devin e Como Instruir o Devin com Eficiência para mais dicas essenciais.

Adicionando um Novo Endpoint de API

Boa abordagem
“Create a new endpoint /users/stats that returns a JSON object with user count and average signup age. Use our existing users table in PostgreSQL. You can reference the /orders/stats endpoint in statsController.js for how we structure responses. Ensure the new endpoint is covered by the StatsController.test.js suite.”
Por que isso funciona:
  • Especifica claramente a rota e o formato de resposta esperado
  • Faz referência a código existente como modelo
  • Define a fonte de dados (tabela de usuários)
  • Inclui requisitos de cobertura de testes


Abordagem ruim
“Add a user stats endpoint.”
Por que isso falha:
  • Não é específico sobre quais estatísticas incluir
  • Não menciona fontes de dados
  • Não faz referência a padrões existentes
  • Não define requisitos de testes

Funcionalidade de Frontend para Exibir Dados

Boa abordagem
“In UserProfileComponent, add a dropdown that shows a list of user roles (admin, editor, viewer). Use the styling from DropdownBase. When a role is selected, call the existing API to set the user role. Validate by checking that the selection updates the user role in the DB. Refer to your Knowledge for how to test properly.”
Por que isso funciona:
  • Nomeia componentes específicos
  • Lista exatamente quais papéis de usuário incluir
  • Faz referência ao componente de estilização existente
  • Define o fluxo de interação do usuário
  • Inclui etapas de validação


Abordagem ruim
“Make the user profile page more user-friendly. Add some way for them to change roles and confirm it’s working.”
Por que isso falha:
  • “Amigável ao usuário” é subjetivo
  • Não menciona componentes de UI específicos
  • O fluxo de interação do usuário não está claro
  • Critérios de validação vagos

​
Mais exemplos

​
Bom

Escrevendo testes unitários

“Adicione testes Jest para os métodos do AuthService: login e logout. Garanta que a cobertura de testes para essas duas funções seja de pelo menos 80%. Use UserService.test.js como exemplo. Após a implementação, execute npm test -- --coverage e verifique se o relatório de cobertura mostra >80% para ambas as funções. Também confirme que os testes passem com credenciais válidas e inválidas e que o logout limpe corretamente os dados de sessão.”
Por que é bom? Métrica de sucesso clara (80% de cobertura), referências para orientar o Devin (UserService.test.js) e um escopo bem definido com etapas específicas de verificação.

Migrando ou refatorando código existente

“Migre logger.js de JavaScript para TypeScript. Já temos um tsconfig.json e uma suíte de testes LoggerTest.test.js para validação. Certifique-se de que o código compile sem erros e não altere a configuração existente! Após a migração, verifique: 1) executando tsc para confirmar que não há erros de tipo, 2) executando a suíte de testes com npm test LoggerTest.test.js para garantir que todos os testes passem e 3) conferindo se todas as chamadas existentes para métodos do logger em toda a base de código ainda funcionam sem erros de tipo.”
Por que é bom? Há um template claro (tsconfig.json) e uma suíte de testes para feedback imediato, além de etapas específicas de compilação e validação.

Atualizando APIs ou consultas de banco de dados

“Estamos migrando de pg para sequelize (leia https://sequelize.org/api/v6/identifiers). Atualize as consultas de UserModel para usar métodos do Sequelize. Consulte OrderModel para ver como fazemos isso nesta base de código. Após a implementação, verifique: 1) executando npm run test:integration UserModel.test.js para checar se todos os testes de integração passem, 2) confirmando que o desempenho das consultas não foi prejudicado, verificando o tempo de execução em um conjunto de dados de teste com 1000 usuários, e 3) validando que todas as operações de CRUD ainda mantêm a integridade dos dados ao executar npm run test:e2e user-flows.test.js.”
Por que é bom? O Devin pode imitar um padrão conhecido e há referências explícitas (OrderModel.js). Fornece um link para a documentação para que o Devin saiba consultá-la e inclui etapas específicas de verificação de desempenho e funcionalidade com comandos de teste exatos.

Implementando uma funcionalidade a partir de um design

“Implemente a página de preços com base neste arquivo do Figma: https://figma.com/file/abc123/Pricing-Page. Concentre-se no frame ‘Pricing Section’. Use nossa configuração do Tailwind em tailwind.config.ts para cores e espaçamentos. Reutilize os componentes Card e Button existentes em src/components/ui/. Após a implementação, inicie o servidor de desenvolvimento e faça capturas de tela nas larguras desktop (1440px) e mobile (375px). Não abra uma PR até que a implementação corresponda ao design.”
Por que é bom? Vincula o arquivo específico do Figma, nomeia o frame exato, faz referência ao design system do projeto e a componentes existentes, e orienta o Devin a verificar visualmente o trabalho antes de abrir uma PR. Com o Figma MCP conectado, o Devin pode ler os design tokens diretamente do arquivo.

Investigando um bug em produção

“Usuários estão relatando erros 500 na página de checkout. Use o Sentry MCP para obter as stack traces mais recentes do projeto payments-api. Verifique o banco de dados em busca de quaisquer problemas de dados relacionados. Encontre a causa raiz, corrija e adicione um teste de regressão. Inclua o link da issue do Sentry na descrição da PR.”
Por que é bom? Aponta o Devin para as ferramentas corretas (integrações MCP), fornece um caminho claro de investigação e define o entregável esperado (correção + teste de regressão + PR).

​
Ruim

Revisão de código sem escopo definido

“Encontre problemas na nossa codebase e corrija-os”
Por que é ruim? A solicitação é vaga demais e sem foco. Não há critérios de sucesso nem uma forma de o Devin saber quando terminou.Em vez disso: Use o Devin Review para revisão de código automatizada em PRs específicas ou dê ao Devin uma tarefa direcionada, como: “Encontre e corrija todos os usos da API oldLogger descontinuada em src/services/.”

Solicitações visuais puramente subjetivas

“Deixe a landing page com uma aparência melhor”
Por que é ruim? “Melhor” é subjetivo e o Devin não tem critérios para orientar o trabalho. O Devin pode construir interfaces funcionais e implementar designs a partir de especificações, mas não pode fazer julgamentos estéticos sozinho.Em vez disso: Forneça um design no Figma, um site de referência ou mudanças específicas: “Aumente o tamanho da fonte da seção hero para 48px, adicione padding de 32px e use a cor indigo-500 da nossa configuração do Tailwind.”

Projetos muito complexos e vagamente definidos

“Crie uma nova arquitetura de microsserviços para nosso aplicativo.”
Por que é ruim? Esta é uma tarefa muito grande e não estruturada. Ela exige muitas decisões de arquitetura, trade-offs e contexto que não estão no prompt.Em vez disso, divida em etapas:
  1. Use o Ask Devin para investigar sua codebase e mapear dependências
  2. Peça ao Devin para propor arquiteturas específicas com seus respectivos trade-offs
  3. Crie sessões separadas para implementar cada serviço — execute-as em paralelo com batch sessions