Melhores práticas

Como estruturar o trabalho com o Devin para maximizar a eficiência e o ROI

Identificar o caso de uso ideal para o Devin é fundamental para maximizar a eficiência e o retorno sobre o investimento (ROI). A seguir estão as melhores práticas para selecionar um caso de uso que aproveite os pontos fortes do Devin.

​

Melhores casos de uso para Enterprise

Critérios ideais de casos de uso
Projetos grandes, de alto valor para o negócio, que podem ser divididos em subtarefas isoladas e repetitivas.
Tarefas que exigem menos de 90 minutos de trabalho de engenharia manual.
Tarefas compatíveis com versões anteriores que podem ser validadas e mescladas de forma independente.

​

Requisitos ideais para o Devin

Requisito
Alto volume de subtarefas repetitivas (slices)
Tarefas com complexidade de engenheiro júnior
Tarefas isoladas e incrementais
Subtarefas objetivas e verificáveis
(Recomendado) Mínimas dependências de projeto

Se sua tarefa atende à maioria ou a todos esses requisitos, ela é uma candidata ideal para o Devin.

​

Definindo o trabalho do Devin

Selecionar o tipo de tarefa certo é crucial para maximizar a confiabilidade do Devin.

Cenário	Questão de confiabilidade	Tipo de tarefa
Pedir ao Devin para construir funcionalidades novas e complexas (mesmo que repetitivas)	Menor confiabilidade em larga escala	Tall & Deep
Atribuir ao Devin tarefas simples e bem definidas	Altamente confiável e eficaz	Wide & Shallow

​

Vertical e profundo vs. horizontal e raso

Um grande backlog de tarefas simples, escaláveis horizontalmente (por exemplo, resolver issues do SonarQube) pode gerar um ROI significativo quando replicado ao longo de milhares de iterações.

Quanto mais simples for a fatia, mais confiável será o projeto como um todo.

​

O que dividir em partes

Ótimos candidatos para o Devin:

• Migrações
• Refatorações
• Modernizações
• Backlogs de dívida técnica

Por exemplo, ao trabalhar em uma migração de código, ela deve ser dividida em partes isoladas, cada uma tratada em uma sessão individual do Devin.

​

Verificação

Uma slice deve ser a menor unidade atômica do projeto.

Exemplos de Slices
Arquivo
Notebook
Módulo

Requisito	Detalhes
Limite de tempo	Cada slice deve exigir menos de 90 minutos de trabalho manual de engenharia.
Verificação	Deve incluir uma forma de validar alterações de código, como: - Executar testes - Fazer o build do código - Verificações de CI - Um script de verificação personalizado

Devin deve ter um mecanismo claro de verificação de sucesso ou falha.

Evite tarefas com muitas dependências ou que envolvam sistemas externos. Devin é excelente em tarefas de programação.

​

Execução paralela

Requisito	Descrição
Isolamento	Cada slice deve ser independente e retrocompatível.
Execução paralela	Use o paralelismo do Devin para executar os slices simultaneamente.
Revisão humana	Após a conclusão de cada slice, ele deve ser submetido a revisão humana antes de ser mesclado em main.

​

Considerações sobre Escalabilidade

Princípio	Descrição
Confiabilidade em nível de slice	Devin é otimizado para máxima confiabilidade no nível de slice individual.
Consideração de escalabilidade	Ao escalar para milhares de slices, manter alta confiabilidade é fundamental.
Impacto de erros	Mesmo uma pequena taxa de erro pode se acumular quando se opera em grande escala.

​

Melhores práticas para definição de tarefas

Requisito	Descrição
Detalhamento claro das etapas	Forneça instruções explícitas para cada etapa.
Referência de ponta a ponta	Um guia detalhado ou vídeo ajuda a garantir a consistência.
Exemplos de Antes/Depois	Ofereça vários exemplos de código de antes/depois (pares de entrada/saída).
Acesso a dependências	Garanta que o Devin tenha todas as dependências necessárias para a tarefa.

Devin é excelente em tarefas contínuas relacionadas a dívida técnica (por exemplo, revisão de PRs, automação de QA) quando são bem divididas e estruturadas.

Migrações, modernizações e refatorações são ótimos casos de uso se puderem ser realizadas de forma incremental. Por exemplo, uma migração de repositório completo que exija todas as mudanças de uma só vez não é recomendada.

Estudo de caso: Estudo de caso de migração da Nubank