Desenvolvimento de software com Devin: Envio de uma fatia vertical (Parte 2)

Bem-vindo de volta! No primeiro tutorial desta série, Devin tirou a poeira do meu antigo repositório fp-ts-exercises e abriu um PR de atualização de dependências. Nesta segunda parte, aumentaremos a dificuldade e criaremos recursos de pilha completa.

Você pode acessar todos os tutoriais da série Devin aqui:

1. Configuração e primeira solicitação pull (parte 1)
2. Enviando uma fatia vertical com Devin (Parte 2) 
3. Integrações, testes e CI/CD (Parte 3) 
4. Segurança, implementação e manutenção (Parte 4)

Quando chegar ao final desta segunda parte, você terá:

• A Playground Next.js 14, onde os alunos editam o código no navegador;
• Testes Vitest ao vivo que ficam verdes (ou vermelhos) em tempo real; e
• A NestJS com banco de dados SQL que salva o progresso com nada mais do que um UUID anônimo no localStorage.

Ao longo do caminho, permitiremos que o Devin gere sua própria lista de tarefas, observe-o fazer malabarismos com tíquetes de front-end e back-end e intervenha quando ele tropeçar em problemas de configuração. Mostrarei a você onde gastei (e economizei) ACUs, o que consertei manualmente e como manter as sessões eficientes.

Recapitulação e pré-requisitos

Ao longo desta série de tutoriais, estamos trabalhando no meu repositório de exercícios fp-ts (anteriormente) abandonado.

O projeto é uma coleção de pequenos desafios destinados a ensinar conceitos de programação funcional (como Option, Either, etc.) em TypeScript. No momento, é um repositório de clonagem e execução: os alunos o baixam, editam os arquivos localmente e executam os testes em seu próprio terminal.

O objetivo é transformar esses exercícios em um playground interativo baseado em navegador, no qual as pessoas podem ler uma explicação, ajustar o código em um editor na página e ver os testes serem aprovados (ou reprovados) instantaneamente. Os alunos também terão a oportunidade de fazer login para salvar seu progresso.

O que realizamos na primeira parte

Lembre-se de que no primeiro tutorial, nós:

• Modernizou o antigo repositório fp-ts: dependências mais recentes, linting, verificações de tipo.
• Conectamos o Devin ao GitHub e provamos que ele pode abrir uma solicitação pull limpa.

Ferramentas locais que você precisa para a segunda parte

Para este segundo tutorial, precisaremos de você:

• Node 20+ e npm 10 (vem com suporte a espaços de trabalho pronto para uso).
• Docker executando um contêiner do PostgreSQL (ou uma instância local do PostgreSQL).

Configurações recomendadas do Devin

Recomendo as seguintes configurações para o Devin:

• Defina um limite flexível de 5 ACUs por sessão em Configurações > Uso e limitesVocê pode definir um limite máximo de 5 ACUs por sessão em Settings > Usage & limits; vamos criar uma nova sessão para cada fase.
• Mantenha a guia de lapso de tempo visível para pausar ou cutucar o Devin se ele parar.

Deixe Devin escrever o plano de jogo

Achei que seria interessante começar testando as capacidades de planejamento de Devin. Criei um prompt e pedi a Devin, usando o recurso "Ask" (atualmente gratuito na versão Beta), que me ajudasse a planejar o trabalho que faríamos hoje.

Sugestão:

Quero transformar meu repositório fp-ts-exercises Node + TypeScript existente (atualmente, exercícios CLI de clonagem e execução) em uma plataforma de aprendizado baseada em navegador que programa o progresso. 

Experiência alvo: 

- Os alunos abrem um aplicativo da Web Next.js, escolhem um exercício, editam o código no navegador e veem os testes Vitest serem aprovados ou reprovados instantaneamente. 

- O progresso (slugs concluídos) é armazenado no lado do servidor e recarregado em visitas posteriores, mas ainda não estamos adicionando contas de usuário (use um UUID anônimo armazenado no navegador). 

Escolhas técnicas para as quais estou inclinado: 

- Frontend: Next.js 14 (React 18, App Router) 

- Editor e executor de código: Sandpack + @vitest/browser 

- API: NestJS 13 com @nestjs/graphql (driver Apollo) 

- Banco de dados: Prisma 5 com PostgreSQL 

- Workspace: workspaces npm simples (apps/web, apps/api, packages/exercises) 

Proponha um plano de implementação passo a passo (lista de tarefas) que dê vida a essa fatia vertical. Faça uma estimativa do custo relativo da ACU para cada tarefa e sinalize as etapas de longa duração (por exemplo, grandes migrações ou instalações de dependências pesadas).

Devin, de forma útil, retornou uma lista de tarefas de seis fases com estimativas de ACU para cada uma delas e sinalizou as etapas de "instalação de dependência pesada".

Resposta de Devin:

Fase 1: Configuração do espaço de trabalho (2-3 ACU)

• Inicializar a estrutura do espaço de trabalho do npm (1 ACU)
• Criar aplicativos/web, apps/apie packages/exercises diretórios
• Configurar a raiz package.json com definições de espaço de trabalho
• Mova os arquivos de exercícios existentes para packages/exercises/src/
• Configurar o front-end do Next.js 14 (1-2 ACU - Long-running: instalação de dependência)Inicialize o Next.js com o App Router em apps/webConfigurar o TypeScript e o Tailwind CSSConfigurar a estrutura básica de roteamento

Fase 2: Migração de pacotes de exercícios (3-4 ACU)

• Extraia o conteúdo do exercício para o pacote compartilhado (2 ACU)
• Criar pacotes/exercícios com extração de metadados de exercícios
• Analise os arquivos de exercícios existentes para extrair:
• Instruções
• Código inicial
• Soluções
• Definir interfaces TypeScript para a estrutura do exercício
• Implementar o sistema de descoberta de exercícios (1-2 ACU)
• Crie um scanner do sistema de arquivos (como fs.readdirSync em exercise.js:17-28)
• Exportar metadados do exercício: título, descrição, dificuldade, testes

Fase 3: API de back-end (4-5 ACU)

• Configurar a API do NestJS com GraphQL (2 ACU - Longa duração: instalação de dependência)
• Inicialize o projeto NestJS em apps/api
• Configurar o servidor Apollo GraphQL
• Configurar endpoints básicos de verificação de integridade
• Implementar Prisma + PostgreSQL (2 ACU - Longa duração: configuração do banco de dados)
• Esquema de design para:
• Sessões de usuários
• Exercícios concluídos
• Configurar o cliente Prisma e as migrações
• Criar resolvedores de programas de controle de progresso
• Gerenciamento de sessões de usuários anônimos (1 ACU)
• Gerar UUID e armazenar no navegador localStorage
• Habilitar a persistência do progresso baseado em sessão sem autenticação

Fase 4: Recursos principais de front-end (5-6 ACU)

• Interface do navegador de exercícios (2 ACU)
• Listar exercícios por categoria (opção, ou, tarefa, etc.)
• Mostrar indicadores de progresso e status de conclusão
• Permitir a seleção e a navegação de exercícios
• Integração com o editor de código Sandpack (2-3 ACU - Em andamento há muito tempo: Configuração do Sandpack)
• Configurar o Sandpack com suporte a TypeScript
• Carregue o código inicial e o fp-ts dependências
• Configurar o sistema de arquivos para arquivos de exercício + teste
• Integração do corredor do navegador Vitest (1 ACU)
• Substituir execSync Chamadas do Vitest (exercise.js:45-47) por @vitest/browser
• Permitir a execução de testes em tempo real e a exibição de resultados

Fase 5: Programa de progresso (2-3 ACU)

• Gerenciamento do progresso no lado do cliente (1 ACU)
• Configurar o cliente Apollo para GraphQL
• Sincronizar o progresso com o backend
• Detecção de conclusão de exercício (1-2 ACU)
• Adaptar a lógica de detecção de sucesso existente (exercise.js:48-49)
• Acionar atualizações de progresso do backend na aprovação do teste

Fase 6: Polonês e implantação (2-3 ACU)

• Aprimoramentos de UI/UX (1-2 ACU)
• Garantir um design responsivo
• Adicionar estados de carregamento e tratamento de erros
• Melhorar a exibição das instruções de exercícios
• Configuração da implantação de produção (1 ACU)
• Configure o Docker para ambos os aplicativos
• Gerenciar variáveis de ambiente
• Configurar a implantação do banco de dados

Custo total estimado: 18-24 ACU

No geral, o plano foi muito bom. Mudei algumas coisas, principalmente na fase seis, já que abordaremos a implantação no quarto tutorial.

Fase 1: Espaço de trabalho e andaime frontal

Objetivo: Crie espaços de trabalho npm, mova os arquivos herdados e inicie um shell Next.js 14 em branco.ACU burn: 3,66 (planejado 1-2).Resultado: O repositório agora tem /apps/web, packages/exercises compartilhado e um aplicativo Next.js pronto para o Tailwind em execução em localhost:3000.

O prompt

Pedi a Devin que criasse o plano que ele fez para a primeira fase. O Agentic Devin não tem contexto do que você poderia ter perguntado anteriormente no recurso "Ask Devin", portanto, você precisa criar um prompt separado e fornecer o contexto. 

Não vou colar todos os prompts neste artigo, mas aqui está o primeiro:

Sugestão:

Tarefa: Inicialize a estrutura do espaço de trabalho npm e o front-end Next.js para a plataforma do navegador fp-ts-exercisesContext:

Estou convertendo meu sistema de aprendizado baseado em CLI fp-ts-exercises existente em uma plataforma baseada em navegador. O sistema atual tem exercícios organizados em 10-from-either.exercise.ts:1-3 com a configuração do TypeScript em tsconfig.json:88 e a configuração do Vitest em vitest.config.ts:7 .

Requisitos:

• Crie uma estrutura de espaço de trabalho npm:
• Root package.json com a configuração do espaço de trabalho para apps/web, apps/api, packages/exercises
• Mova os arquivos de exercícios existentes do src/ atual para packages/exercises/src/
• Preservar a convenção de nomenclatura do arquivo de exercício atual (.exercise.ts e .solution.ts)
• Inicialize o front-end Next.js 14 em apps/web:
• Use o roteador de aplicativos (não o roteador de páginas)
• Configure o TypeScript com configurações rígidas semelhantes às atuais tsconfig.json:88
• Adicionar CSS do Tailwind para estilização
• Criar uma estrutura básica de roteamento para navegação de exercícios
• Manter a compatibilidade:
• Garantir que a estrutura de exercícios e as importações existentes ainda funcionem
• Mantenha as dependências do fp-ts acessíveis em todo o espaço de trabalho
• Preservar os padrões atuais de configuração do Vitest

Entregáveis:

• Package.json configurado no espaço de trabalho na raiz
• Aplicativo Next.js em apps/web/ com TypeScript e Tailwind
• Exercícios migrados em packages/exercises/
• Estrutura básica de roteamento (/exercícios, /exercícios/[categoria], /exercícios/[categoria]/[slug])

Pilha tecnológica:

• Next.js 14 com o App Router
• TypeScript (modo estrito)
• Tailwind CSS
• Espaços de trabalho npm (não yarn/pnpm)

Submissão:

• Garantir a aprovação do script de verificação de tipo e lint
• Crie um PR com suas alterações

Todos os prompts que escrevi posteriormente seguiram o mesmo padrão: destaque da tarefa, contexto, requisitos, resultados, pilha de tecnologia e detalhes de envio.

O que Devin realmente fez

Demorou bastante tempo para decidir seu curso de ação (cerca de quatro minutos), mas conseguiu:

1. Criou o esqueleto do espaço de trabalho
2. Você migrou todas as pastas de exercícios para packages/exercises/src.
3. Você fez o bootstrapped do Next.js 14 com o App Router, TypeScript e Tailwind.
4. Adicionados scripts de verificação de tipo e lint ao aplicativo front-end (depois que eu o cutuquei).

Por que o custo da ACU aumentou

O custo da ACU aumentou porque:

• Devin passou um minuto inteiro fazendo looping em npm install tentativas após um tempo limite do espelho.
• Você tentou interromper o servidor de desenvolvimento e os processos com q no Vim e, em seguida, com Ctrl-C, e ambos falharam. Dei a ele um pouco de tempo para tentar consertá-lo sozinho, mas acabei intervindo manualmente e encerrando os processos nas duas vezes. Cada minuto extra significava ACUs extras, e eu não teria detectado esse problema rapidamente se não estivesse acompanhando de perto as ações de Devin.

Intervenções humanas e lições aprendidas

Aqui está um resumo das correções que precisei fazer:

Mover grandes árvores de arquivos é mais rápido manualmente e muito mais barato, pois Devin cobra por tempo/tarefa. Arrastei as pastas, fiz o commit e deixei que o agente pegasse a nova estrutura. Ele conseguiu extrair minhas alterações sem problemas e fazer uma mesclagem sozinho!

Dito isso, tive que solicitar que ele executasse os scripts lint e typecheck, mesmo que eu tivesse especificado isso em meu prompt inicial. No final, os dois funcionaram, mas falharam. Mesmo assim, Devin considerou o evento um sucesso e seguiu com as relações públicas.

Corrigi os dois problemas localmente, executei os scripts e executei o novo servidor de desenvolvimento da Web para garantir que ele iniciasse como pretendido e enviei o commit.

Fase 2: Empacotamento dos exercícios

Objetivo:  Extraia todos os arquivos de desafios em um pacote reutilizável packages/exercises e gere metadados para cada exercício.ACU burn:  0,6 (planejado 2+).Resultado: O pacote compartilhado exporta metadados digitados que o aplicativo da Web e a futura API podem importar com import { exercises } from '@exercises/registry'.

O que Devin realmente fez

Devin criou:

• Interfaces TypeScript estruturadas para exercícios, metadados, categorias e o catálogo completo.
• Analisador de exercícios que:
• Extrai metadados de comentários de código e assinaturas de funções
• Analisa o código inicial, o código da solução e os casos de teste do Vitest
• Gera automaticamente tags a partir do uso do fp-ts
• Converte nomes camelCase em títulos legíveis
• Sistema de descoberta de exercícios que:
• Você verifica o sistema de arquivos em busca de pares .exercise.ts e .solution.ts
• Cria um catálogo baseado em slug (por exemplo, option-01 )
• Organiza os exercícios por categoria, com armazenamento em cache para melhorar o desempenho
• Exportações convenientes para consulta de exercícios e categorias:
• getExercises(), getExerciseBySlug(), getExercisesByCategory(), getCategories(), getCategoryBySlug()

Por que Devin terminou abaixo do orçamento

A Devin conseguiu manter o custo da ACU baixo - eis como ela fez isso:

• Sem instalações pesadas ou chamadas de rede
• A movimentação de arquivos foi simples; Devin usou git mv (barato) em vez de copiar e colar e diff
• A geração de metadados era pura TypeScript, rápida para planejar e executar

Intervenções humanas

Desta vez, você não terá nenhum!

Aprendendo com a última vez, verifiquei a ramificação do Devin e executei os scripts localmente. Tudo foi compilado e o registro exporta definições de tipo limpas, o que o torna o material de entrada perfeito para a interface do usuário e a API que criaremos em seguida.

Fase 3: NestJS + GraphQL API

Objetivo: Monte um serviço NestJS 13 que exponha o progresso do exercício via GraphQL e persista os dados no PostgreSQL com Prisma.ACU burn: 4.2 (planejado 4).Resultado: apps/api boots on localhost:4000/graphql. Você pode consultar e alterar os registros de progresso com a chave de um ID de sessão anônimo.

O que Devin realmente fez

Para a terceira fase, Devin:

1. Você criou uma API NestJS completa em apps/api com TypeScript e Apollo GraphQL
2. Integração do PostgreSQL com o Prisma ORM e configuração do esquema com os modelos Session e CompletedExercise
3. Implementação do gerenciamento de sessões anônimas usando UUIDs (sem necessidade de autenticação)
4. Você criou resolvedores GraphQL para criação/validação de sessões, consultas de exercícios e acompanhamento do progresso.
5. Conectar o backend ao pacote de exercícios compartilhados (packages/exercises ) para descoberta de dados
6. Você configurou o CORS para dar suporte à comunicação com o front-end Next.js
7. Garantiu a compatibilidade de tipos entre o esquema GraphQL e as interfaces TypeScript existentes.
8. Configurar scripts de desenvolvimento, fluxo de migração de banco de dados e integração com o Prisma Studio

Onde Devin tropeçou

Estes são os problemas que encontrei durante a terceira fase e as correções que tive de fazer:

Lições aprendidas

Estas são minhas conclusões:

• Configuração vs. código: O Devin é excelente quando o modelo de estrutura está em vigor, mas o diagnóstico de problemas de dependência ainda precisa de um olho humano.
• Sempre execute localmente: Eu já havia criado um banco de dados PostgreSQL local em minha máquina, e as instruções do PR para executar a migração do Prisma e iniciar o ambiente de desenvolvimento foram claras e fáceis de seguir (veja a imagem abaixo). O comentário de Devin diz que você conseguiu executar a API localmente, mas o npm run dev travou até que o reflect-metadata fosse adicionado.

• Devin é bom em lidar com comentários de RP. Comentei sobre o PR, explicando a Devin que eu havia tentado executar a API localmente e encontrei um erro. Imediatamente, ele me mostrou um pequeno emoji de olho, e a sessão foi retomada por si só para corrigir o erro, e uma correção foi enviada alguns minutos depois.

• Sempre verifique se há arquivos secretos: Devin havia enviado um arquivo .env com uma variável DATABASE_URL, que continha um nome de usuário e uma senha fictícios. Depois de extraído localmente, alterei o nome de usuário e a senha para os identificadores do meu banco de dados local e me certifiquei de remover o arquivo do sistema de rastreamento git e adicioná-lo ao site .gitignore. Nos próximos tutoriais, você verá como lidar com segredos com segurança.

Fase 4: Playground do Sandpack e testes ao vivo

Objetivo: Ofereça aos alunos um editor de navegador que executa soluções fp-ts e verificações Vitest em tempo real.Queima de ACU: 7.2 (planejado 3-4).Resultado: Ao acessar /exercises/option-01, você abre uma exibição dividida: O editor do Sandpack à esquerda, o túnel de teste à direita, e uma mensagem de sucesso é exibida no momento em que todas as especificações são aprovadas.

O que Devin realmente fez

Aqui está o que Devin fez na quarta fase:

• Páginas de navegação e listagem de exercícios construídas com suporte dinâmico a categorias e slug
• Editor Sandpack integrado com suporte a TypeScript, fp-ts e sistema de arquivos em tempo real
• Substituição do executor de testes CLI pelo Vitest no navegador e feedback ao vivo
• Conectar o front-end ao back-end por meio do Apollo Client para acompanhamento do progresso baseado em sessão
• Implementação de uma interface de usuário responsiva com estados de carregamento e tratamento de erros

Onde Devin queimou ACUs extras

Devin queimou mais ACUs do que o esperado para essa fase - aqui está o motivo:

Lições aprendidas

Minhas conclusões desta vez são:

• Assistir silenciosamente = queimar dinheiro. Mantenha a guia Timelapse aberta e, se o Devin fizer um loop, empurre-a ou pause.
• Exclua o código morto com antecedência. O Devin realmente não exclui o código obsoleto por si só, a menos que você o solicite. Cometi o erro de pedir anteriormente que ele movesse os arquivos sem que dissesseexplicitamente para excluí-los, e assim acabamos com vários pontos de entrada que confundiram muito o pobre Devin nessa fase.

Devin demorou um pouco aqui. Ele entrou em loop e entrou em loop, tentando salvar os mesmos problemas, não conectando o backend e o frontend corretamente, fazendo alterações, reiniciando os servidores, verificando no navegador se funcionava etc. Foi como um trabalho de desenvolvimento normal, suponho...

Agora você tem um aplicativo funcional. Consegui iniciar os servidores da API e da Web, navegar até localhost, editar a função stub, pressionar Save e ver o painel de teste passar de vermelho para verde. Então, percebi que ele só fazia o trabalho até a metade e codificava o teste e a solução do primeiro exercício em todas as páginas de exercícios. Apontei o problema e, depois de mais loops, ele conseguiu corrigi-lo e enviar suas correções.