De desenvolvedor a gestor de agentes: por que aprender SDD

O vídeo apresenta o Spec-Driven Development (SDD), ou desenvolvimento orientado a especificações, como uma prática para aumentar a previsibilidade e a capacidade de revisão quando agentes de IA executam tarefas de software cada vez maiores e mais complexas.

O fluxo da programação agêntica

Um agente recebe um prompt, altera o código e produz uma mudança que precisa ser revisada por uma pessoa antes da aprovação. O prompt pode ser escrito por um humano ou gerado pelo próprio agente em um processo de iteração contínua. O ponto crítico é preparar corretamente a tarefa antes da execução.

O vídeo organiza esse fluxo no chamado método Pera:

1. Preparar a tarefa e o contexto.
2. Executar o trabalho com o agente.
3. Revisar o resultado e verificar se ele atende ao que foi pedido.
4. Acelerar, paralelizando tarefas ou usando agentes na nuvem e ciclos automatizados.

A aceleração só é confiável quando as fases de preparação, execução e revisão estão bem estruturadas. Não adianta executar ou paralelizar uma tarefa mal definida.

O que é SDD

No SDD, a equipe descreve previamente o que deve ser construído, como o sistema deve se comportar e quais condições precisam ser atendidas. O código produzido pelo agente é então comparado com essa especificação.

A validação deixa de ser uma avaliação ampla e subjetiva. Cada requisito pode ser conferido individualmente: se a especificação foi implementada, se foi implementada corretamente ou se ainda está faltando. A implementação continua até que todos os requisitos estejam atendidos.

A ideia se relaciona a práticas anteriores, como:

• TDD: desenvolvimento orientado a testes; o código é escrito até que os testes passem.
• BDD: desenvolvimento orientado a comportamento; o comportamento esperado do sistema é descrito e usado como especificação.
• User stories: ações que o usuário precisa conseguir realizar no produto.

O SDD não é apresentado como uma invenção completamente nova, mas como uma forma de aplicar esse tipo de decomposição e validação ao trabalho com agentes autônomos.

De user story a tarefas implementáveis

O exemplo usado é uma plataforma de cursos. A user story é: “Como usuário, quero conseguir assistir a uma aula de um curso que comprei”. Para que isso seja possível, o sistema pode precisar de:

• uma tela com os cursos aos quais o usuário tem acesso;
• uma lista das aulas de cada curso;
• um player de vídeo;
• controle para que o conteúdo fique disponível aos compradores;
• uma API, como GET /courses, que retorne os cursos autorizados;
• uma interface de front-end para exibir esses cursos e aulas.

Uma user story ampla pode resultar em tarefas de back-end, front-end, autorização e interface. Se ela for enviada inteira ao agente, o agente terá de tomar várias decisões não especificadas: estrutura das rotas, formato da API, tecnologia do player, comportamento de aulas gratuitas e regras de acesso, por exemplo.

O SDD propõe decompor essa tarefa maior em unidades menores, cada uma com escopo e critério de validação mais claros. O resultado são tickets isolados, que podem gerar pull requests menores e mais fáceis de revisar.

Relação com o trabalho de um gestor

O vídeo compara o trabalho com agentes ao trabalho de um tech lead ou engineering manager. Um gestor precisa decompor objetivos em tarefas, distribuir o trabalho, acompanhar a execução e revisar os resultados. Com agentes, esse papel de decomposição e supervisão passa a ser necessário mesmo para quem antes atuava principalmente como desenvolvedor de front-end ou back-end.

A IA pode produzir boa parte do código, mas ainda é necessário entender o sistema o suficiente para definir tarefas, estabelecer limites e validar a implementação. O desenvolvedor passa a atuar mais como gestor e revisor do trabalho do agente.

PRD no fluxo de SDD

O fluxo começa com uma ideia, que pode vir de analytics, entrevistas com usuários, gravações de sessões ou uma necessidade de negócio. Essa ideia evolui para um PRD, ou documento de requisitos de produto.

A recomendação do vídeo é que o PRD seja curto, simples e amigável para humanos. Ele não deve ser um documento extenso gerado automaticamente, cheio de texto que a equipe não consiga ou não queira ler.

O PRD deve conter principalmente:

• Problema: qual situação precisa ser resolvida e qual é o contexto.
• Solução: o que deve acontecer para resolver o problema, incluindo as user stories.
• Restrições: decisões inegociáveis da implementação, como usar um determinado provedor ou tecnologia.
• Critérios de aceite: condições objetivas que precisam ser verdadeiras para considerar o trabalho concluído.

O problema fornece contexto para quem define o trabalho, quem executa e quem implementa. Esses papéis podem ser exercidos pela mesma pessoa, mas representam fases diferentes do ciclo: preparar, executar e revisar.

As restrições delimitam onde o agente ou desenvolvedor não pode alterar a solução. Já os critérios de aceite funcionam como uma lista de verificação para a revisão.

PRD, tickets e pull requests

No modelo apresentado:

PRD → tickets → pull requests

O PRD é dividido em tickets, e cada ticket representa uma unidade de trabalho de programação. O resultado de cada ticket é um pull request que pode ser revisado separadamente.

Essa divisão reduz o tamanho das mudanças. Em vez de revisar uma feature que altera, por exemplo, 127 arquivos, a equipe pode revisar seis tickets menores, cada um com cerca de 20 arquivos. Cada ticket também pode ser associado a um ou mais critérios de aceite do PRD.

Isso permite rastrear o código até o requisito original e facilita a identificação do que foi implementado, do que está incorreto e do que ainda falta. Tickets independentes também podem ser trabalhados em paralelo, inclusive por agentes diferentes.

User stories como testes

O vídeo mostra uma aplicação chamada Canvas Collab, na qual o usuário pode alterar seu nome e a letra exibida na interface. Essa funcionalidade é descrita como uma user story: o usuário deve conseguir clicar na letra, alterar o nome e ver a primeira letra do novo nome aparecer.

A ferramenta TestSprite é usada para transformar essa descrição em um caso de teste. O teste verifica se o nome pode ser alterado, se o valor é salvo e se a interface exibe a nova inicial depois da atualização da página.

A execução registra as etapas realizadas e disponibiliza um vídeo do resultado. Assim, a user story deixa de ser apenas uma descrição e passa a ter uma forma prática de verificar se o trabalho do agente foi concluído corretamente.

Quando usar SDD e quando usar apenas um prompt

A escolha depende da complexidade e do risco da tarefa. Quanto maior e mais complexa a mudança, mais difícil é validar o resultado completo e maior é a necessidade de confiança no processo.

Para uma tarefa pequena, simples e de baixo risco, um prompt direto pode ser suficiente. Para uma feature maior, o recomendado é decompor o trabalho em partes menores por meio de uma especificação, de modo que cada parte possa ser validada separadamente.

A decomposição também transforma uma tarefa grande em várias tarefas pequenas que podem ser resolvidas com prompts individuais. Em vez de pedir ao agente que implemente dez coisas de uma só vez, a equipe separa os dez requisitos e executa cada um com escopo mais claro e maior capacidade de revisão.

O vídeo conclui que o SDD é especialmente útil quando a tarefa exige alto grau de confiança, quando há múltiplos requisitos, quando o trabalho será paralelizado ou quando a implementação precisa ser rastreável a critérios de aceite. A trilha de engenharia de agentes apresentada no vídeo tem lançamento anunciado para 30 de setembro de 2026, às 7 horas.