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.

​
Ruim

Revisão de código genérica

“Identifique problemas na nossa base de código e corrija-os”
Por que é ruim? A solicitação é vaga demais e pede que o Devin conclua tarefas demais em uma única sessão. O Devin pode se confundir em sessões longas.

Tarefas de design visual

“Reproduza exatamente o que está neste mock do Figma”
Por que é ruim? Essa é uma solicitação visual subjetiva. O Devin não consegue “ver” como os humanos veem e não vai acertar todos os detalhes perfeitamente. Ele não é otimizado para esse tipo de caso de uso.

Projetos muito complexos e vagos

“Crie uma nova arquitetura de microsserviços para o nosso app.”
Por que é ruim? Essa é uma tarefa muito grande e pouco estruturada. Exige decisões de arquitetura e trade-offs.Em vez disso, divida projetos complexos em fases:
  1. Peça que o Devin analise sua base de código
  2. Peça que o Devin proponha arquiteturas específicas
  3. Crie sessões separadas para implementar cada parte