Curso
Bem-vindo de volta! Ao final do do segundo tutorialtínhamos um playground fp-ts com tema pastel, um backend NestJS + PostgreSQL e um programa de acompanhamento de progresso UUID anônimo.
Você pode acessar todos os tutoriais da série Devin aqui:
- Configuração e primeira solicitação pull (parte 1)
- Enviando uma fatia vertical com Devin (Parte 2)
- Integrações, testes e CI/CD (Parte 3)
- Segurança, implementação e manutenção (Parte 4)
O que fizemos até agora é ótimo para hackers individuais, mas está na hora de ver como o Devin se integra aos fluxos de trabalho da equipe. Neste terceiro tutorial, você verá:
- Integrações: Devin abrirá tíquetes do Jira, trabalhará neles e transmitirá cada status de PR diretamente para o Slack.
- Portões de qualidade: Adicionaremos testes de unidade Jest para a API, fluxos de ponta a ponta do Playwright para a interface do usuário e aplicaremos 90% de cobertura.
- CI/CD: O GitHub Actions fará a lint, a verificação de tipo, executará todos os testes e anexará relatórios do Playwright às solicitações pull antes que qualquer coisa possa ser mesclada.
Ainda não há implementações de autenticação nem de produção, elas acontecerão na Parte 4!
Configurar uma integração do Slack no Devin
A conexão do Devin ao seu fluxo de comunicação e de tíquetes é totalmente manual e feita por meio da interface do Devin.
Você pode se conectar ao Slack na guia de integração das configurações do Devin ou instalar o aplicativo "Devin AI" no diretório de aplicativos do Slack.
O aplicativo ainda mostra "Não aprovado pelo Slack" na caixa de diálogo do OAuth. A Cognition diz que sua revisão de segurança está pendente e que a funcionalidade não foi afetada.
Em seguida, escolha um canal:
Você pode conversar com Devin com apenas uma menção:
E ele inicia uma sessão que você pode acessar na interface do usuário:
Por padrão, você é notificado sobre as atualizações de RP no canal de sua escolha, mas há algumas configurações de notificação diferentes que podem ser ajustadas nos parâmetros de cada sessão.
Configurar uma integração do Jira no Devin
Para integrar-se ao Jira, você precisa criar uma conta de usuário de bot dedicada (por exemplo, devin-bot@…
) e vincular essas credenciais em Devin → Equipe ▸ Integrações ▸ Jira.
Na sua conta pessoal, você pode criar um novo tíquete e adicionar a etiqueta devin
.
Devin publica um comentário de análise com um esboço de plano e um prompt "Iniciar sessão?". Digite "yes" para permitir que ele codifique ou remova o rótulo para manter o tíquete somente para humanos.
Observação: Devin não moverá cartas automaticamente pelo seu tabuleiro. Você ou seu PM ainda deve arrastá-los para Em andamento ou Concluído. Isso mantém o controle do fluxo de trabalho em mãos humanas.
Permitir que o Devin trabalhe com os tickets do Jira
Depois que o Slack e o Jira foram conectados, fiz um verdadeiro experimento de "agente como colega de equipe" e enviei tíquetes reais para o Devin para ver se ele poderia implementá-los sem precisar de ajuda.
O fluxo de trabalho que usei
Este é o meu fluxo de trabalho:
- Crie um tíquete em meu projeto JIRA recém-criado e escreva um critério de aceitação claro.
- Adicione o rótulo
devin
, que é o sinal de Devin para você analisar. - Devin comenta com um plano passo a passo, uma estimativa de confiança e pergunta: "Iniciar sessão?"
- Eu respondi: "Sim". O tíquete mostra "Sessão iniciada" e fornece o link do IDE da Web. Quando o PR chega, Devin publica "Merged ✅" no Slack, e eu movo a carta no quadro. Nada disso custa ACUs até que eu responda "Sim".
Cinco bilhetes reais, cinco resultados totalmente diferentes
Aqui está um resumo do que aconteceu com cinco tíquetes reais:
Bilhete |
Trabalho planejado |
ACUs |
Como Devin realmente se saiu |
Migrar SQLite→Postgres |
Trocar o mecanismo de banco de dados, executar migrações |
0.6 |
Sem falhas. Em um commit, os testes permaneceram verdes. |
Melhorar a interface do usuário do Sandpack e corrigir testes com falhas |
Ajustes na interface do usuário + teste de confiabilidade |
5.0 (duas sessões) |
Você insistiu em mudar de para SQLite, perdeu scripts de migração, queimou ACUs. Finalmente, dividi a interface do usuário e os testes em dois prompts para que você pudesse terminar com o limite. |
Mostrar os ticks de conclusão nas listas |
Adicionar ✓ emblemas na lista de exercícios |
0.8 |
Sucesso de uma só vez; até adicionou uma interface de usuário otimista. |
Validar o sistema de descoberta |
Verificação de ponta a ponta de que cada arquivo é analisado |
2.6 |
As verificações de back-end foram aprovadas, mas o erro de front-end permaneceu. Você precisava de dois empurrões. |
Remover o código de conquista abandonada |
Excluir sinalizador de recurso + componentes obsoletos |
0.4 |
Devin avisou "Baixa confiança" e, em seguida, removeu cirurgicamente 30 arquivos e atualizou as importações sem nenhuma falha. |
Coisas que pareciam aleatórias
Esses são os aspectos que precisariam ser aprimorados:
- Títulos de relações públicas: Especifiquei um padrão de nomenclatura em cada prompt, mas Devin inventou um novo formato a cada vez.
- Fidelidade ao banco de dados: Em um tíquete, ele migrou para o Postgres e, em outro, reintroduziu silenciosamente o SQLite.
- Estimativas da ACU: O comentário da análise afirmava que o tíquete do sandpack levaria 1,5 ACUs; na realidade, foram duas sessões e 5 ACUs.
- A confiança versus a execução: Um tíquete com baixa confiança foi executado em 3 minutos, e com perfeição. Um com alto grau de confiança levou 45 minutos para ser ajustado.
Devin, no Jira, é promissor: dois tíquetes foram fechados perfeitamente, um deles com um leve empurrão, e mesmo o pior caso custou apenas tempo, não uma reversão. Mas a consistência ainda não está presente, portanto, o escopo restrito e as restrições explícitas são seus amigos.
Adicionar testes automatizados com o Jest e o Playwright
Com o fluxo de bate-papo e tíquetes, a próxima etapa era garantir que o código corrompido não passasse despercebido. Pedi a Devin duas coisas: testes unitários de back-end e testes Playwright de ponta a ponta que imitam um aluno editando um exercício no navegador.
Testes de unidade de back-end: surpreendentemente simples
Pedi a Devin suítes de teste Jest que abrangessem o resolvedor GraphQL, a camada de serviço e os modelos Prisma. Quando solicitei uma estimativa de ACU, ele respondeu 20 ACUs!!!
Achei que devia ser um erro e iniciei a tarefa mesmo assim. Custou 1,1 ACUs e foi facilmente a tarefa mais bem executada até agora.
Dramaturgo e2e: parede vermelha, parede verde
Esse foi um pouco mais caro e custou 2,3 ACUs.
O fluxo registrado: abrir /learn/option-01
→ editar código → aguardar ✓ → atualizar página → ✓ persiste.
Na primeira execução, cerca de 70% das afirmações falharam. Houve muitas falhas de redimensionamento, contagens de painel obsoletas e até mesmo o caminho feliz falhou.
Apesar do comando "Ignore failing tests, we'll fix later" (Ignorar testes com falha, corrigiremos mais tarde) no meu prompt, Devin continuou corrigindo o código até que o conjunto ficasse quase todo verde (útil, mas não o que eu pedi).
Ainda temos alguns testes que falharam porque temos alguns bugs no sistema. Mas tudo bem, vamos resolver as coisas mais tarde para garantir que todos esses testes sejam verdes.
Adicionar um pipeline de GitHub Actions com um clique
Com os testes unitários e de ponta a ponta implementados, a última etapa foi garantir que cada pull request executasse essas verificações automaticamente. Pedi ao Devin um fluxo de trabalho básico, sem artefatos, sem portas de cobertura, apenas lint → verificação de tipos → testes.
Devin entregou um pipeline surpreendentemente polido em uma única tentativa, sem a necessidade de qualquer acompanhamento:
- Desvio de configuração zero: Devin reutilizou os scripts npm existentes, portanto, você não precisa aprender novas ferramentas.
- Tudo em paralelo: O Lint, a verificação de tipo e os dois conjuntos de testes são executados lado a lado, de modo que todo o fluxo de trabalho é concluído em cerca de 4 minutos nos executores gratuitos do GitHub.
- Limpar a triagem: Se o ESLint falhar, mas os testes forem aprovados, o trabalho de resumo ainda informará o erro do lint; você nunca mesclará o código "parcialmente vermelho".
Devin enviou o fluxo de trabalho, esperou que a verificação fosse concluída no GitHub e só então decidiu que estava pronto. Devo dizer que 0,4 ACU para um pipeline em pleno funcionamento é difícil de superar. YAML é claramente o lugar feliz de Devin.
Com esse fluxo de trabalho mesclado, cada PR deve ser aprovado no lint, na compilação e nos dois conjuntos de testes antes que alguém pressione o botão verde!
Wiki do produto de Devin
O Devin vem com um "Wiki" integrado que pode ficar ao lado do seu código. É uma base de conhecimento leve e gerada automaticamente, na qual o agente pode ler e gravar enquanto trabalha. Depois de conectar o Slack, o Jira e o CI, este Wiki é um bom local para anotações de arquitetura. Vale a pena dar uma olhada!
Pelo que sei, isso não é editável manualmente, e você deve contar com Devin para manter o Wiki atualizado.
Instantâneo e reflexões sobre custo e tempo
Quando todas as integrações, os testes e o pipeline estavam ativos, eu contabilizei a conta e o relógio:
Pedaço de trabalho |
ACUs |
Tempo prático |
Notas |
Conexão com o Slack e o Jira |
0.0 |
10 min |
Cliques manuais do OAuth; sem tempo de agente. |
5 tíquetes do Jira |
9.4 |
2h de empurrar e revisar |
Dois tíquetes estavam corretos, um precisava de empurrões, novas tentativas e testes, um estava parado na troca de SQLite. |
Conjunto de unidades Jest (API) |
1.1 |
Revisão de 5 minutos |
O susto de "20 ACU" de Devin se transformou em uma joia de 1 ACU. |
Playwright e2e suite (web) |
2.3 |
Revisão de 10 minutos |
Devin ignorou a frase "não corrija o código" e aplicou o patch até que três testes ficassem vermelhos. |
Pipeline de GitHub Actions |
0.4 |
Ajuste de 3 minutos |
YAML de uma página; primeira tentativa verde. |
Total |
13.2 ACUs |
≈ 2h 30 min |
≈ US$ 30 no nível de preço Core. |
Portanto, cerca de 2 horas de esforço humano para obter tíquetes, testes e CIs. É mais rápido do que eu teria feito, com certeza.
No entanto, neste momento, estou em conflito. Ainda há muitos bugs e, se eu mesmo tivesse escrito toda a base de código, provavelmente conseguiria corrigir os problemas mais rapidamente do que o Devin queima créditos.
Mas Devin escreveu a maior parte do aplicativo, então o agente realmente "conhece" a estrutura melhor do que eu. Ainda assim, ele se esforça para substituir valores codificados por valores dinâmicos, deixa pontas soltas no código em todos os arquivos e precisa que eu fique sentado em frente ao meu laptop para cuidar de todas as suas ações.
Também achei o processo um pouco frustrante, mas não da mesma forma que eu ficaria ao perseguir um bug que não consigo entender. Há uma grande diferença (pelo menos para mim) entre ficar frustrado porque o código não funciona e ficar frustrado porque um agente de IA não consegue seguir algumas instruções básicas. O último é absolutamente irritante.
Acho que o Devin pode ser muito útil quando bem utilizado, mas, como acontece com todos os agentes de IA existentes, ele não pode substituir um engenheiro de software. Não há problema em usá-lo para algumas tarefas, mas não acho que seja muito adequado ou sustentável usá-lo para todos os tíquetes.
O que vem a seguir?
Estamos conectados ao Slack e ao Jira, os testes são verdes e o portão de CI bloqueia todos os PRs desleixados. Mas para um lançamento de produção real, ainda faltam quatro pilares:
- Autenticação Você pode usar as credenciais NextAuth → cookies JWT →
GqlAuthGuard
no NestJS para que o progresso seja vinculado a usuários reais. - Fortalecimento da segurança: Rastreamento de erros do Sentry nos tempos de execução da Web e da API.
- Implantação contínua: Um pipeline Vercel (Web) que ativa URLs de visualização em cada ramificação e promove para
prod
quando a ramificação principal fica verde.
Essa é a agenda da Parte 4, a reta final em que descobriremos se Devin pode proteger, implementar e cuidar do aplicativo quase sem intervenção humana. Fixe seu banco de dados no Postgres (de novo!), proteja as ACUs e vejo você no último capítulo.
Se você estiver pronto para continuar, clique no último item da lista abaixo para ir para o quarto tutorial:
- Configuração e primeira solicitação pull (parte 1)
- Enviando uma fatia vertical com Devin (Parte 2)
- Integrações, testes e CI/CD (Parte 3)
- Segurança, implementação e manutenção (Parte 4)