Por que aprender SDD para programar com agentes de IA

Ver no idioma original →

Autoria: Rafael Quintanilha – QuantBrasil · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Por que aprender SDD para programar com agentes de IA · Canal: Rafael Quintanilha – QuantBrasil · 32:24 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA

Resumo

O vídeo apresenta o Spec-Driven Development (SDD) como uma forma de preparar e dividir tarefas para que agentes de IA produzam mudanças mais fáceis de revisar e validar. Rafael Quintanilha relaciona esse processo ao método PERA — preparar, executar, revisar e acelerar — e explica como histórias de usuário podem se desdobrar em tarefas e critérios de aceitação. Ele recomenda que PRDs sejam curtos, claros e centrados no problema, na solução, nas restrições e nos critérios de aceitação. A escolha entre SDD e um simples prompt depende da complexidade e do risco da tarefa: quanto mais difícil for validar o resultado, mais importante é especificar e dividir o trabalho.

Pontos-chave

• O SDD organiza o desenvolvimento em torno de uma especificação definida antes da implementação.
• O método PERA estrutura o trabalho com agentes em preparação, execução, revisão e aceleração.
• Uma história de usuário pode ser dividida em requisitos e tarefas distintas de frontend e backend.
• Tarefas menores facilitam a revisão e ajudam a relacionar cada mudança a critérios de aceitação.
• Um PRD deve ser curto, simples e compreensível para as pessoas envolvidas.
• O PRD deve registrar o problema, a solução, as restrições e os critérios de aceitação.
• Tickets derivados do PRD podem gerar pull requests menores e, quando apropriado, ser trabalhados em paralelo.
• Para tarefas simples e de baixo risco, um prompt pode bastar; tarefas complexas exigem mais especificação para gerar confiança.

Capítulos

Início	Capítulo	Resumo
00:00	O problema que o SDD busca resolver	O vídeo apresenta a dificuldade de validar o trabalho de agentes em tarefas complexas e introduz o SDD.
04:10	O método PERA	O apresentador descreve as etapas de preparar, executar, revisar e acelerar o trabalho com agentes.
07:21	O que é Spec-Driven Development	O SDD é explicado como desenvolvimento orientado por uma especificação que serve de referência para validar mudanças.
10:33	De histórias de usuário a tarefas	Uma história de usuário sobre assistir a uma aula é desdobrada em requisitos de interface, API e acesso ao conteúdo.
15:51	Desenvolvedores como gestores de agentes	O apresentador compara a decomposição de tarefas para agentes ao trabalho de gestão de equipes de desenvolvimento.
18:01	Demonstração de testes com Test Sprite	Uma história de usuário para alterar um nome na aplicação Canvas Collab é convertida em um teste executável.
21:38	Como estruturar um PRD	O vídeo aborda as fontes de ideias para funcionalidades e recomenda PRDs curtos, claros e centrados no problema.
24:55	Solução, restrições e critérios de aceitação	O apresentador detalha como registrar no PRD a solução desejada, o que não pode ser alterado e como verificar a conclusão.
27:05	Do PRD aos tickets e pull requests	O PRD dá origem a tickets menores, que podem ser revisados individualmente e, quando adequado, trabalhados em paralelo.
29:49	Quando usar SDD ou apenas um prompt	A necessidade de especificação depende da complexidade, do risco e da dificuldade de validar o resultado da tarefa.
31:53	Encerramento	O apresentador pede comentários sobre o uso de SDD e encerra agradecendo ao público e à Test Sprite.

Citações

Você diz o que quer que seja feito, diz como seu sistema precisa funcionar, e o desenvolvimento será inteiramente orientado por isso. — 07:55

Isso é o que chamamos de desenvolvimento orientado por especificação. — 15:20

Não crie um documento gigante, cheio de texto que ninguém vai ler. — 23:19

Se você precisa ter um alto grau de confiança na tarefa, precisa, de um jeito ou de outro, fazer algum tipo de SDD. — 30:19

Conceitos e entidades

• Spec-driven development (conceito): Abordagem que orienta o desenvolvimento por uma especificação criada antes da implementação e usada para validar o resultado.
• PERA method (conceito): Método apresentado no vídeo para trabalhar com agentes por meio de preparação, execução, revisão e aceleração.
• test-driven development (TDD) (conceito): Abordagem mencionada em que os testes são escritos primeiro e o código é desenvolvido até que eles passem.
• Behavior-driven development (BDD) (conceito): Abordagem que define o comportamento esperado do aplicativo, muitas vezes expresso em histórias de usuário.
• user story (conceito): Descrição de uma ação ou capacidade que uma pessoa usuária deve poder realizar no sistema.
• Product requirements document (PRD) (conceito): Documento de requisitos do produto que, no exemplo do vídeo, registra o problema, a solução, as restrições e os critérios de aceitação.
• Acceptance criteria (conceito): Conjunto de condições verificáveis que precisam ser atendidas para considerar um projeto ou tarefa concluído.
• TestSprite (ferramenta): Ferramenta demonstrada no vídeo para criar e executar testes de uma aplicação.
• Canvas Collab (ferramenta): Aplicação usada na demonstração do Test Sprite para criar um teste de alteração do nome de usuário.
• Rafael Quintanilha (pessoa): Apresentador do vídeo, no qual explica o SDD e o uso de agentes no desenvolvimento de software.

Tradução completa (pt-BR)

00:00 À medida que os modelos de inteligência artificial ficam cada vez melhores, é natural que nossas tarefas também se tornem mais ambiciosas. No entanto, conforme a complexidade e o tamanho dessas tarefas aumentam, também fica mais difícil validar e garantir que o agent de IA esteja fazendo exatamente o que queremos. Foi justamente para resolver esse problema que surgiu o conceito de SDD, ou Desenvolvimento Orientado a Especificações. Mas você

00:32 realmente precisa usar SDD? Não é só burocracia? Quais são os principais casos de uso? Quando você deve usar um SDD e quando talvez só precise enviar um prompt? Você precisa criar um PRD? Essas são algumas das perguntas que quero discutir com vocês no vídeo de hoje. Pessoal, a área de desenvolvimento de software orientado a agents, o que costumamos chamar de programação agêntica, é algo muito novo.

01:04 Na verdade, os agents ficaram mais autônomos nos últimos 12 a 18 meses, certo? Então, é natural que estejam sendo criados frameworks e boas práticas para lidar com essa nova forma de desenvolver software. Você necessariamente precisa aprender a programar com agents? Olha, se quiser continuar relevante no mercado, provavelmente sim. Então, é normal tentarmos estabelecer um conjunto de boas práticas, e essas boas

01:35 práticas vão evoluir com o tempo. Uma das principais técnicas que surgiram e vêm sendo aprimoradas para desenvolver software com agents se chama SDD. E, no vídeo de hoje, vamos fazer isso neste formato aqui, no tablet. Fiz isso no meu último vídeo, em que expliquei por que você deveria aprender prompt engineering, e o feedback foi muito bom. Então, vamos continuar com esta série sobre os fundamentos da programação com IA, ou seja, o uso de IA por quem quer

02:06 desenvolver sistemas com inteligência artificial. Vou deixar aqui o link para você assistir ao vídeo sobre prompt engineering, certo? Então, o que aconteceu, pessoal? As pessoas perceberam que era possível pegar um agent e, em vez de desenhar o robô — vou usar aqui esta figurinha de um robô —, dar uma tarefa a um agent de IA, certo? Você envia um prompt aqui, e esse agent trabalha e, no fim, gera várias

02:37 modificações no seu código, certo? Então, ele faz algumas adições aqui, remove algumas linhas, acrescenta outras, e aí você terá aqui mais 129 linhas escritas e menos 67 linhas removidas, por exemplo, certo? Você verá isso em uma solicitação, e ótimo, vai lá e revisa, certo? Agora você revisa aqui, uma pessoa entra em cena aqui, certo? Ela precisa revisar e, então,

03:07 em algum momento você vai ficar satisfeito e aprovar esse código, certo? Se aprovar, pode seguir e fazer o merge, certo? Esse é o workflow de alguém que programa com um agent. Este prompt aqui pode vir do próprio agent ou de uma pessoa, certo? A pessoa pode ser quem envia o prompt. No caso de a IA enviar o prompt para si mesma, é isso que chamamos de loop engineering,

03:39 a IA descobrindo o que realmente vai fazer. Então, temos aqui este fluxo básico de programação agêntica. Vou chamar isso de fluxo de programação agêntica, certo? É isso que normalmente entendemos por programar com agents. Certo, pessoal, mas no vídeo de hoje quero dar atenção especial a esta etapa aqui, a etapa do prompt. Quando desenvolvemos com agents, temos

04:10 várias etapas, certo? Para deixar um pouco mais claras as etapas da programação agêntica, vou mostrar o que chamei de método PERA. Ou método PERA, como você preferir. O que seria isso, pessoal? São todas as etapas que você precisa seguir para trabalhar bem com um agent. Então, a primeira coisa que você vai fazer é preparar aquilo em que vai trabalhar, preparar a tarefa. A

04:42 segunda etapa seria a execução. Depois de preparar, você executa a tarefa. Depois de executá-la, você a revisa, certo? Precisa revisá-la para ver se está adequada. E, por fim, quando tiver esse bom fluxo de preparação, execução e revisão, poderá acelerar, que seria a parte

05:13 em que você paraleliza. Aqui podemos falar sobre trabalhar com agents na nuvem, agents na nuvem. Também podemos falar sobre fazer loop engineering, certo? Em outras palavras, maneiras de trabalhar mais rápido com IA. É isso que vai fazer de você um engenheiro 10x, certo? Usando uma expressão que as pessoas gostavam muito de usar antigamente, certo? Aquele engenheiro que trabalha por dez. Então, quando você conseguir dominar esta

05:46 etapa — a primeira etapa, de preparação; a segunda, de execução; e a terceira, de revisão —, quando conseguir fazer isso com IA de uma forma muito bem estruturada e dominar todo esse workflow, estará pronto para acelerar, e é aí que as coisas começam a ficar interessantes, certo? Este método, o método PERA, é uma das coisas que ensino no meu curso de programação agêntica, que faz parte da trilha AI Engineer.

06:18 A trilha AI Engineer, pessoal, será lançada no dia 30 de setembro, às 7h, certo? Então, convido vocês a se inscreverem pelo link que está tanto na descrição quanto no comentário fixado, para receberem uma notificação quando nossa trilha for lançada. Por quê? Porque o grupo fundador terá condições especiais que não serão repetidas, certo? Então, se vocês têm interesse em aprender comigo a desenvolver com agents de IA em uma trilha que aborda os fundamentos da engenharia de IA, além de programação agêntica,

06:49 que é o foco do vídeo de hoje, e também um curso de Prompt Engineering, que foi o assunto do último vídeo. Sem dúvida, essa trilha será útil para vocês. Então, não se esqueçam de se inscrever aqui na lista de inscrição para receber uma notificação quando o evento começar. Vocês já perceberam por que o SDD é relevante: ele atua diretamente nesta primeira fase, a fase de preparação. É aí que entra o nosso SDD. Se você não tem

07:21 essa base sólida, não adianta executar se não estiver preparado. Não adianta revisar algo que você não preparou e não entende bem, muito menos acelerar um processo que está quebrado, certo? Ótimo, pessoal. Vamos falar mais sobre SDD agora, certo? SDD significa desenvolvimento orientado a especificações, certo? O que cada uma dessas coisas quer dizer? Significa desenvolvimento

07:55 orientado à especificação. Então, aqui, por “spec”, estamos falando de uma especificação, certo? Você diz o que quer que seja feito, diz como seu sistema precisa funcionar, e o desenvolvimento será inteiramente orientado por isso. Essa especificação será algo que você gera antes de começar a trabalhar, para que possa se transformar em um pull request em que cada alteração possa ser

08:28 atribuída diretamente. Assim, posso validar muito melhor. Posso validar com base na spec. Posso receber o código e dizer: “Nossa, este código está atendendo à especificação um aqui. Ah, ótimo, está certo. Este código está atendendo à especificação dois. Ótimo, está funcionando. Certo, vamos continuar. E a especificação três, opa, essa está faltando; não foi implementada ou foi implementada

08:59 incorretamente. Então, vamos continuar trabalhando até que a especificação esteja completamente concluída. Isso seria desenvolvimento orientado a especificações. Agora, algumas pessoas podem argumentar que não há nada de muito novo no SDD, que as pessoas usam esses métodos de desenvolvimento há muito tempo, e isso é verdade, certo? Por exemplo, muita gente gostava de trabalhar com TDD, que seria desenvolvimento orientado a testes, certo

09:30 ? Também havia BDD, que já existia e continua existindo, certo? Claro, que é desenvolvimento orientado a comportamento, certo? Então, o que seria TDD? Você vai lá e escreve os testes, e escreve o código até que os testes passem, certo? E então isso se torna documentação. No caso do BDD, você vai lá e define o comportamento que seu app deve ter, e isso também se torna uma especificação. Geralmente, isso

10:01 se transforma em histórias de usuário. E eu, pessoalmente, sempre gostei de trabalhar com histórias de usuário. Na verdade, já fiz um vídeo sobre Spec Driven Development que também convido vocês a assistir depois deste. Vou deixar o link para vocês verem mais tarde. Nele, falo sobre como eu costumava escrever, sei lá, há 10 anos, e como gostava de criar histórias de usuário. E o que são histórias de usuário? Bem, normalmente são

10:33 ações que o usuário pode realizar no seu sistema. Então, você terá algo como, sei lá, imagine que está criando um sistema para as pessoas assistirem a um curso, como no caso do programa. Então, você escreveria assim: como usuário, devo poder assistir a uma aula de um curso que comprei. Pronto, isso é um recurso, é uma ação que

11:03 que o usuário precisa conseguir fazer. Se ele comprou um curso, precisa conseguir assistir àquela aula. E, com base nisso, você vai criar os recursos, criar as telas, criar tudo o que for necessário para que ele consiga assistir à aula. Então, vamos pensar, certo? Vamos, vamos pensar nessa história aqui, certo? História de usuário número um. Como usuário, posso assistir a uma aula de um

11:37 curso que comprei, certo? Então, essa é a nossa bússola. Precisamos garantir que isso seja verdade. Então, para que isso seja verdade, o que preciso fazer aqui? Certo? Para que isso seja verdade, preciso, bem, preciso ter uma tela, preciso de uma tela com os cursos, com os cursos do usuário, certo? Então, isso precisa acontecer para que essa

12:09 história de usuário seja verdadeira. Bem, também preciso, dentro dessa tela do curso, listar todas as aulas. Listar todas as aulas. E aí a pessoa vai lá, clica em uma aula, e preciso ter um player de vídeo. E esse player de vídeo precisa estar disponível para quem comprou o curso, certo? Então, disponível para os compradores. Perceba como uma única história de usuário pode

12:40 se desdobrar em várias coisas que você precisa fazer. Agora vamos entrar aqui: uma tela com os cursos do usuário. Bem, então aqui, em um nível mais baixo, preciso ter uma API que retorne, não sei, cursos, certo? Uma API get courses para o usuário, para a qual você envia as credenciais dele, e ela retorna todos os cursos, os cursos a que ele tem acesso. Também é necessário ter um frontend, uma tela, uma UI com os cursos. Então,

13:11 você já entendeu que isso virou uma tarefa de backend, e isso virou uma tarefa de frontend. E talvez você tenha uma equipe com vários desenvolvedores, certo? Você tem alguém de backend na sua equipe. Tem alguém de frontend na sua equipe. Você vai lá e passa esta tarefa para essa pessoa e passa a outra tarefa para a outra. E continua fazendo isso para todos os requisitos aqui, até conseguir listar esta história de usuário, certo? Agora, pessoal,

13:45 olha, você poderia muito bem enviar este prompt para um agent, e ele produziria um PR para você. Vamos pegar nosso agent aqui, olha. Você manda para ele, e ele produz um PR para você, certo? Só que esse PR vai estar cheio de inferências, porque o escopo não está muito claro. Se você só enviar isso para ele, veja quantas coisas precisam ser detalhadas. E cada uma

14:15 delas pode ser feita de maneiras diferentes. Por exemplo, ah, vou criar uma API. Vai ser uma API /courses? Vai ser uma API /me/courses? E como exatamente vai ser essa UI, certo? Vou listar todas as aulas, vou ter um player de vídeo. Qual player vou usar? Ah, ele precisa estar disponível para os compradores. Mas, se eu quiser ter uma aula grátis, se eu quiser que todo curso tenha uma aula grátis, certo? Como incorporo isso ao meu PR?

14:48 Então, você percebe que, embora seja possível fazer um exercício com este prompt que leve a uma tarefa executável por meio de código, ainda foi necessário passar por uma etapa de detalhamento, certo? Você pega uma tarefa grande e a divide, como peças de Lego, em várias outras, certo? E cada uma delas pode ser validada muito

15:20 melhor. Então, aqui você tem a tarefa um, aqui a tarefa dois, aqui a tarefa três e aqui a tarefa quatro, certo? Muito melhor do que enviar aquele bloco inteiro para o agent, pessoal. É isso que chamamos de desenvolvimento orientado a especificações. Na verdade, não há nada de revolucionário nisso. Não há nada que não pudesse ser feito antes. Agora, pessoal, não é por acaso que dizemos que um bom gerente, ou seja, um bom gestor de pessoas — quem seria um bom gestor de pessoas neste caso? Um Tech Lead, um Engineering Manager, alguém acostumado a liderar outros desenvolvedores — será um bom gerente de agents, porque a ideia é parecida. Você vai fazer todo esse detalhamento de tarefas da mesma forma que

15:51 faria antes para outra equipe.

16:24 Mas tem uma ressalva, pessoal: se, no passado, para ser gerente você precisava ser Tech Lead ou Engineering Manager, agora qualquer pessoa virou gerente de agents. Aqui, literalmente qualquer pessoa. Então, se antes talvez você não precisasse entender tanto este conceito e só se preocupasse com esta parte, tipo: “

16:55 Tailwind ou qualquer outra coisa que você usaria em uma stack, certo, como desenvolvedor web, agora a IA meio que faz isso por você, certo? Claro, você precisa entender para validar e tudo mais, mas a IA faz uma grande parte disso. Você está supervisionando; seu trabalho passou a ser muito mais o de gerenciar agents. Então, precisa entender a técnica de como atribuir tarefas a um agent de IA. E é exatamente aí que entra SDD.

17:28 Tailwind, ou qualquer outra coisa que você usaria em uma stack, certo, como desenvolvedor web. Agora, a IA meio que faz isso por você, certo? Claro, você precisa entender para validar e tudo mais, mas a IA faz uma grande parte disso. Você supervisiona; seu trabalho passou a ser muito mais o de gerenciar agents. Então, você precisa entender a técnica de como atribuir tarefas a um agent de IA. E é exatamente aí que entra o SDD.

18:01 Agora, antes de continuar mostrando as melhores práticas para um bom SDD, quero dar exemplos concretos de como histórias de usuário podem se transformar em testes do mundo real, certo? Para isso, vou usar o Test Sprite, parceiro do nosso canal e deste vídeo, para mostrar como o que apresentamos no quadro se torna realidade, certo? Então, considerem o seguinte, pessoal. Imaginem que tenho este aplicativo aqui, chamado Canvas Collab, certo? E ele tem vários recursos. Posso escrever, posso colocar um círculo aqui, posso mudar a cor. E tudo isso pode virar uma história de usuário, certo? Tudo isso pode ser algo que será feito por meio de SDD, certo? Quero fazer um teste aqui com vocês para mostrar como isso funciona na prática, certo? Estou aqui na interface do Test Sprite, certo? O link para vocês testarem o Test Sprite estará na descrição, no comentário fixado. E aqui tenho a opção de adicionar testes com IA e manualmente. Vamos fazer manualmente para vocês verem, certo?

18:33 colocar um círculo aqui, posso mudar a cor. E tudo isso pode se transformar em uma história de usuário, certo? Tudo isso pode ser algo que será feito por meio de um SDD, certo? E quero fazer um teste aqui com você para que possa ver como isso funciona na prática, certo? Estou aqui na interface do Test Sprite, certo? O link para você testar o Test Sprite estará na descrição, no comentário fixado. E aqui tenho a opção de adicionar testes tanto com IA quanto manualmente. Vamos fazer isso.

19:03 Configurei este projeto Canvas Collab na interface do painel do Test Sprite, e vamos executar um teste. Aqui eles chamam isso de caso de teste; vocês podem pensar nisso como uma história de usuário, certo? Vejam o exemplo que eles fornecem. O usuário pode entrar com credenciais válidas. É uma história de usuário. E aqui está a descrição, o que este teste verifica, certo? Então, vamos pensar em um teste simples aqui, certo? Aqui no Canvas Collab. Posso clicar nesta letra e mudar meu nome, certo? E então posso salvá-lo, e pronto. Está ali. R. Se eu atualizar a página, o R continua aqui porque está salvo no armazenamento local, certo? Então, vamos criar um teste para isso. Vamos dizer que posso clicar aqui e mudar meu nome. E então a primeira letra será a letra do meu nome. Podemos criar um teste para garantir que isso esteja funcionando. Então, posso escrever algo assim, por exemplo. O usuário pode mudar o nome. Esse seria o título que quero criar. E depois, a descrição. O usuário deve conseguir clicar na

19:34 posso salvar, e pronto. Está bem ali. R. Se eu atualizar a página, o R continua aqui porque está salvo no armazenamento local, certo? Então, vamos criar um teste para isso. Vamos dizer que posso clicar aqui e mudar meu nome. E então a primeira letra será a inicial do meu nome. Podemos criar um teste para garantir que isso esteja funcionando. Então, posso colocar algo assim, por exemplo: o usuário pode mudar o nome. Esse seria o título que quero criar. E então, a descrição. O usuário deve poder clicar no

20:05 letra, mudar o nome, e a letra passará a ser a primeira letra do nome. E o Test Sprite permite adicionar cada etapa, certo? Ação, clicar, verificar isto ou aquilo, mas nem precisa fazer isso. Você pode simplesmente inserir este caso de teste aqui, veja? Ele aparece como um teste planejado. Agora clico aqui e posso executá-lo. Veja que posso configurar o tempo limite, posso configurar a janela de visualização. E olha, o Test Sprite tem

20:36 Já começou a adicionar as etapas, viu? Primeiro, acesse o site do Canvas. Depois, clique no botão para editar o nome de exibição. Ele já está vendo isso aqui, já consegue editar. Assim, temos a garantia de que a história de usuário tem um teste correspondente que me permite validar se o trabalho do meu agent foi bem feito. E olha só, pessoal, terminou. O Testprite adicionou alguns outros campos aqui. Ele até tem um vídeo em que posso clicar e assistir, viu?

21:08 Mudou o nome, salvou. Maravilha. Vejam: era Sen, mudou para Alice, salvou, e o A apareceu ali. Então, certo, está funcionando. Posso passar para as próximas histórias de usuário e continuar assim até concluir todo o meu recurso, certo? Repito o convite para vocês testarem o Testprite de graça pelo link que está tanto na descrição quanto no comentário fixado. Muito bem, pessoal. Então, ficou claro que, se passarmos apenas este prompt, vai ser difícil

21:38 validar o resultado. Então, qual seria a melhor forma de trabalharmos nisso? Certo? Normalmente, em um workflow com SDD, tudo começa com uma ideia, certo? Você vai ter uma ideia que virá de várias fontes. Por exemplo, pode vir das suas análises; pode vir, por exemplo, de entrevistas com usuários. Também pode

22:12 vir de gravações de sessões. Você vai até lá e assiste às gravações de como as pessoas estão usando o seu app. Ah, também pode vir de uma ordem da diretoria, certo? Uma ordem executiva de negócios. Olha, agora precisamos fazer isso porque queremos vender para determinado cliente. Então, tudo isso vai servir de base para você trabalhar em um recurso, certo? E, pessoal, isso vai evoluir para o que chamamos de PRD, certo? Um documento de requisitos de produto

22:47 certo? E, pessoal, não existe uma única maneira, nenhuma solução mágica para escrever um PRD, mas neste vídeo quero mostrar o que gosto de ver em um PRD, certo? Primeiro, pessoal, um PRD precisa ser simples e curto, certo? Por favor, não

23:19 façam isso, não criem um documento enorme, cheio de conteúdo lixo gerado por IA e de um monte de texto que ninguém vai ler. Lembrem-se: um bom gestor de pessoas também será um bom gestor de agents. Ninguém é um bom gestor por entregar um arquivo, um documento de 10 páginas cheio de texto que não escreveu, e pedir ao desenvolvedor que o leia, porque ele não vai ler, certo? Então, não façam isso. Criem um PRD

23:53 simples, curto e, acima de tudo, fácil de entender para as pessoas. Olha, pessoal, eu preciso entender aquilo. Preciso estar alinhado com quem me apresentou o problema. Então, se eu fosse dividir um PRD em seções, faria assim: sempre definiria o problema, certo? E, de novo, este é um problema descrito para uma pessoa. Olha, temos este problema e aquele

24:25 problema. É muito importante fazer isso, porque o problema define o contexto do que você está resolvendo, certo? E é preciso entender o contexto. Por quê? Porque aqui temos o papel de quem define o problema, de quem é responsável pela execução e de quem fará a implementação. Você pode ter um PM aqui, um engenheiro aqui e um agent aqui. Muitas vezes, será a mesma pessoa desempenhando três papéis diferentes, mas são três

24:55 fases do ciclo de desenvolvimento. Lembram-se do método PERA? Preparar, executar, revisar. Cada uma dessas etapas precisa estar ciente do contexto do problema, certo? Por isso, é muito importante incluir isso no PRD. E, claro, se você tem o problema, também vai definir a solução. Olha, vimos que isso está acontecendo e queremos resolver dessa forma. Normalmente, é aqui que entram as histórias de usuário, descrevendo o que precisa acontecer,

25:26 certo? Depois de definir a solução, você vai listar as restrições, ou seja, o que não é negociável na implementação, certo? Geralmente, são coisas definidas de cima para baixo, algo que já foi estabelecido ou que se baseia em algum limite por um motivo. Pensem no nosso exemplo aqui, certo, da aula do curso sobre o reprodutor de vídeo; podemos

25:58 já ter definido que o reprodutor será via Cloudflare. Por quê? Talvez já tenha havido uma pesquisa que determinou que a Cloudflare é a melhor opção, ou talvez a empresa já tenha um acordo com eles; não importa. Isso não é negociável. Você vai incluir isso no PRD para que o desenvolvedor saiba no que não pode mexer e onde tem liberdade criativa, certo? E então, depois de definir tudo o que não pode ser alterado, entram os critérios, os critérios de aceitação, certo

26:33 — os critérios de aceitação. E aqui você terá um conjunto de caixas de seleção para as coisas que precisam ser verdadeiras para que o projeto esteja concluído, certo? Por que isso é importante, pessoal? Como você vai validar se a solução é adequada? Vai validar verificando, opa, se todas as caixas estão marcadas. Assim, no meu ciclo PERA, na etapa de revisão, posso verificar facilmente

27:05 se tudo o que foi definido para mim foi feito, certo? Por isso, pessoal, considero muito importante desenvolver um PRD ao trabalhar com SDD. SDD é o método. O PRD é um documento que vai dar origem a vários chamados. Esses chamados serão unidades de trabalho de programação, certo

27:36 ? O resultado de um chamado é um pull request. Então, um chamado vai gerar um pull request, no qual você pode revisar cada um deles com muito mais facilidade. Aí você vai lá e diz: “Ei, não gostei disso, refaça esta parte aqui.” Então, vou lá e faço de novo. Depois, vou lá e aprovo, certo? Então, o PRD dá origem aos chamados. E esses chamados são trabalhados

28:09 isoladamente. Mas olha que legal: agora que dividi o que quero fazer em várias tarefas, talvez eu possa trabalhar em paralelo, certo? Isso pode ser feito em paralelo. Então, quando esse esquema é bem executado pelo método PERA, você pode acelerar as coisas, porque agora tem seis chamados para trabalhar. Mas olha, em vez de ter uma coisa enorme aqui para revisar, com, digamos, 127 arquivos, você dividiu tudo em seis partes, com cerca de 20 arquivos cada. Mas agora, pessoal, vocês têm uma vantagem, porque cada chamado pode corresponder a um critério de aceitação específico. Então, este está relacionado ao critério um, este aponta para os critérios dois e três, este para o critério quatro, e assim por diante. Assim, posso sempre validar acompanhando

28:43 o PRD e comparando meu código com o que eu queria desenvolver no começo, certo? Fica muito mais fácil ter confiança no que estou fazendo. E, pessoal, a última coisa que eu queria fazer antes de terminar este vídeo é abordar o elefante na sala: quando usar SDD, certo? Quando preciso disso, quando preciso de um PRD? Pessoal, isso

29:14 obviamente vai depender da complexidade da tarefa. Bem, pessoal, quanto maior a complexidade do problema, mais difícil é validá-lo. E, se for difícil validar, fica mais difícil confiar no trabalho, confiar no agent. Então, se você precisa ter um alto grau de confiança na tarefa que será

29:49 realizada, precisa, de um jeito ou de outro, fazer algum tipo de SDD. Ah, Rafael, eu sempre preciso ter um alto grau de confiança? Não sei, às vezes o chamado tem baixo risco, certo? Se o chamado tem baixo risco, se é de baixo risco, então você pode se dar ao luxo de resolver com o prompt; talvez um prompt resolva. Talvez um prompt resolva. Talvez o assistente seja bom o suficiente e você só precise do prompt para resolver, certo?

30:19 Mas, na prática, com que frequência isso vai acontecer? E, melhor ainda, toda vez que você divide um recurso maior nesses recursos pequenos, eles se tornam tarefas que um prompt consegue resolver. Então, em vez de dar um único prompt para tentar resolver 10 coisas de uma vez, você pega o que queria fazer, divide em 10 coisas menores e, aí sim, para essa tarefa menor, tem muito mais confiança de que o prompt vai resolvê-la, pessoal. Eu falo sobre isso e

30:50 Mas, realisticamente, com que frequência isso vai acontecer? E, melhor ainda, toda vez que você divide um recurso maior nesses pequenos recursos, esses menores se tornam tarefas que um prompt vai resolver. Então, em vez de dar um único prompt para tentar resolver 10 coisas de uma vez, você pega o que queria fazer, divide em 10 coisas menores e, aí sim, para essa tarefa menor, tem muito mais confiança de que o prompt vai resolvê-la, pessoal. Eu falo sobre isso e

31:21 com muito mais detalhes e profundidade na minha formação em engenharia de IA. Por isso, vou repetir o convite para você se inscrever na lista de interesse da formação de engenheiros de IA, que acontecerá em 30 de setembro de 2026, às 7 horas. Inscreva-se na lista para receber uma notificação. É muito importante que você receba essa notificação, porque teremos condições especiais para a turma fundadora, certo? Então, não se esqueça de se inscrever para participar do nosso evento de lançamento. E quero saber de você agora: você

31:53 tem usado SDD no seu dia a dia? Gosta da ideia de escrever um PRD mais curto, dividi-lo em critérios de aceitação e passá-lo para um desenvolvedor — que pode até ser você — para então trabalhar com seu agent? Conte nos comentários, porque quero saber como você tem usado agents para programar. Também aproveito esta oportunidade para pedir que você curta este vídeo e se inscreva no canal. Aqui falamos sobre tudo relacionado à engenharia de IA, tudo sobre programação agêntica e engenharia de harness.

32:24 Os fundamentos da engenharia de IA são temas recorrentes aqui no canal. Então, por favor, inscreva-se, curta o vídeo e compartilhe. Se estiver no celular, toque em curtir, o que também nos ajuda muito. Sou imensamente grato por você ter ficado comigo até aqui. Agradeço à Test Sprite pela parceria neste vídeo e até a próxima.

Transcrição original

[00:00] As artificial intelligence models keep getting better, it is only natural that our tasks also become more ambitious. However, as the complexity and size of these tasks increase, it also becomes harder to validate and ensure that the AI agent is doing exactly what we want. It was precisely to solve this problem that the concept of SDD, or Spec Driven Development, was created. But do you

[00:32] actually need to use SDD? Isn’t it just bureaucracy? What are the main use cases? When should you use an SDD and when might you just need to send a prompt? Do you need to create a PRD? These are the questions and others that I want to discuss with you in today’s video. Guys, the field of agent-oriented software development, what we commonly call agentic programming, is something very new.

[01:04] Actually, agents have become more autonomous in the last 12 to 18 months, right? So it is natural that frameworks and best practices are being created to deal with this new way of developing software. Do you necessarily need to learn how to program with agents? Look, if you want to stay relevant in the market, most likely yes. So it is normal that we try to establish a set of best practices and these best

[01:35] practices will evolve over time. So one of the main techniques that emerged and is being improved to develop software with agents is called SDD. And in today’s video, we are going to do it in this format, right, here on the tablet. I did this in my last video, where I explained why you should learn prompt engineering, and the feedback was very good. So let’s keep going with this series on the basics of AI programming, right, the use of AI for those who want

[02:06] to develop systems with artificial intelligence. I will put the link here for you to watch the prompt engineering video, okay? So, what happened, folks? People realized that you could take an agent, and instead of drawing the robot —I’ll use this little figure here of this robot. You could take an AI agent and give it a task, right? You send it a prompt here, and this agent will work and eventually it will spit out several

[02:37] modifications to your code, right? So it will make some additions here, remove some lines, add others, and then you’ll have here plus 129, right, lines written, minus 67 lines deleted, for example, right? You’ll see this in a request, and great, you go there and review it, right? So now you review it here, a human comes in right here, right? They need to review it, and then

[03:07] eventually you’ll be happy and approve that code, right? So if you approve it, you go ahead and do the merge, right? So this is the workflow for someone programming with an agent. This prompt here can come from the agent itself or from a human, right? The human can be the one sending the prompt. In the case of AI sending the prompt to itself, that’s what we call loop engineering,

[03:39] the AI figuring out what it’s actually going to do. So we have this basic flow here for agentic programming. I’ll call this the agentic programming flow, alright? So that’s what we typically understand by programming with agents. Alright folks, but in today’s video, I want to zoom in exactly on this step here, the prompt step. When we’re developing with agents, you have

[04:10] several steps, okay? And to make the steps we have in agentic programming a bit clearer, I’ll show you what I’ve dubbed the PERA method. Or the PERA method, whichever you prefer. What would that be, folks? These are all the steps you need to go through to work well with an agent. So, the first thing you’ll do is prepare what you’re going to work on, prepare the task. The

[04:42] second step, then, would be the execution part. Once you’ve prepared, you go ahead and execute the task. After you execute it, then you review it, right? You need to review it to see if it’s adequate. And finally, when you have this nice flow of preparation, execution, and review, you can then accelerate, which would be the part

[05:13] where you parallelize. Here we can talk about working with agents in the cloud, cloud agents. Here we can talk about doing loop engineering, okay? In other words, ways for you to work faster with AI. This is what will make you a 10x engineer, right? To use an expression people really liked using back in the day, right? That engineer who works for ten. So, when you manage to master this

[05:46] stage—the first stage of preparation, the second stage of execution, and the third stage of review—when you can do this with AI in a very well-structured way and master this entire workflow, then you’re ready to accelerate, and that’s when it starts to get interesting, okay? This method, the Pera method, is one of the things I show in my agentic programming course, which is part of the AI Engineer track.

[06:18] The AI Engineer track, everyone, will be launched on September 30th at 7 AM, alright? So, I invite you to sign up using the link that is both in the description and in the pinned comment so you can be notified when our track launches. Why? Because the founding group will get special conditions that won’t be repeated, okay? So, if you’re interested in learning with me how to develop with AI agents in a track that covers the fundamentals of AI engineering, as well as agentic

[06:49] programming—which is what we’re focusing on in today’s video—and also a course on Prompt Engineering, which is what we talked about in the last video. This track will undoubtedly be useful for you. So, don’t forget to sign up here on the subscription list to be notified when the event goes live . So, you’ve already realized why SDD is relevant, because it directly attacks this first phase, the preparation phase. So, this is where our SDD comes in. If you don’t have

[07:21] this solid foundation, there’s no point in executing if you’re not prepared. It’s no use reviewing something you haven’t prepared and don’t understand well, and even less so accelerating a process that is broken, okay? Great, everyone. Let’s talk more about SDD now , okay? So SDD stands for spec-driven development, right? What does each of these things mean? It means development

[07:55] oriented toward the specification. So, by “spec” here, we are talking about a specification, okay? You say what you want to be done, you say how your system needs to work, and your development will be entirely oriented toward it. This specification will be something you generate before you start working, so that it can turn into a pull request where each change can be

[08:28] directly attributed. So I can validate much better. I can validate against the spec. I can receive the code and say: “ Whoa, this code is meeting specification one here. Ah, great, that’s OK. This code is meeting specification two. Great, it’s working. OK, let’s keep going. And specification three, oops, that one is missing; it’s not implemented or it’s implemented

[08:59] incorrectly. So let’s keep working until the specification is completely finished. So that would be specification-driven development. Now, some people might argue that there’s nothing very new here in SDD, that people have had these development methods for a long time, and that’s true, right? For example, a lot of people liked working with TDD, which would be test-driven development, right

[09:30] ? There was also BDD, it already existed and still exists, right? Of course, which is behavior driven development, right? So, what would TDD be? You go there and write the tests, and you write the code until the tests pass, right? And then that becomes documentation. In the case of BDD, you go there and define the behavior your app must have, and that will also become a specification. Usually, this

[10:01] turns into user stories. And I, personally, have always liked working with user stories. In fact, I’ve already made a video about Spec Driven Development that I’ll invite you to watch after this one too. I’ll leave the link for you to see later. In it, I talk about how I used to write, I don’t know, 10 years ago, how I liked to create user stories. And what are user stories? Well, they are typically

[10:33] actions that the user can perform in your system. So you’ll have something like, I don’t know, imagine you’re creating a system for people to watch a course, like in the case of the program . Then you would write it like this: as a user, I must be able to watch a lesson from a course I bought. Done, that’s a feature, that’s an action that

[11:03] the user must be able to perform. If they bought a course, they must be able to watch that lesson. And based on that , you will create the features, create the screens, create everything necessary for them to be able to watch the lesson. So let’s think, right? Let’s, let’s think about this story here, right? User story number one. As a user, I can watch a lesson from a

[11:37] course that I bought, right? So this is our compass. We have to ensure that this is true. So, for this to be true, what do I need to do here? Right? For this to be true, I need, well, I need to have a screen, I need a screen with the courses, with the user’s courses, right? So that needs to happen for this

[12:09] user story to be true. Well, I also have to, within this course screen, I have to list all the lessons. List all the lessons. And then the guy goes there, clicked on a lesson, I need to have a video player. And this video player has to be available to those who bought it, right? So available to the buyers. See how a single user story can

[12:40] unfold into several things you need to do. Now let’s go in here, have a screen with the user’s courses. Well, then here I need to have, at a lower level, an API that returns, I don’t know, courses, right? A get courses API for the user, where you pass their credentials, it will return all the courses, the courses they have access to. You also need to have a front end, a screen, a UI with the courses. So,

[13:11] you already understood here that this has become a back-end task, and this has become a front-end task. And maybe you have a team with multiple developers, okay? You have your back-end person there on your team. You have the front-end person there on your team. You go there and hand this task to this guy and pass the other task to him. And then you keep doing this for all the requirements here until you can list this user story, okay? Now, folks,

[13:45] look, you could very well send this prompt here to an agent and it will produce a PR for you. Let’s take our agent here, look. You threw it to him, he will produce a PR for you, okay? Except this PR here will be full of inferences, because the scope isn’t that clear. If you only send this to him, look at the amount of things that have to be broken down. And then each

[14:15] of these will have different ways of being done. For example, ah, I’m going to create an API. Will it be a/courses API? Will it be a/me/courses API? And this UI, how will it necessarily be, right? I will list all the lessons, I will have a video player. Which player am I going to use? Ah, it has to be available for buyers. But if I want to have a free lesson, if I want every course to have a free lesson, right? How do I incorporate that into my PR?

[14:48] So you see that this prompt, even though you can perform an exercise here that leads to a task actionable via code, it still had to go through a breakdown stage, right? You take a big task here and you break it down like Lego into several others, okay? And for each one of them, you can validate much

[15:20] better. So here you have task one, here you have task two, here you have task three, and here you have task four, okay? Much better than sending that entire block to the agent, folks. This is what we call spec-driven development . Actually, there is nothing revolutionary here. There is nothing that couldn’t be done before. Now, folks, it’s no coincidence that we

[15:51] say a good manager, that is, a good people manager, who would be a good people manager in this case? A Tech Lead, an Engineering Manager, someone used to leading other developers, will be a good manager for agents, because the idea is similar. You will do all this task breakdown in the same way you

[16:24] would have done before for another team . But there is a catch, folks: if in the past to be a manager you had to be a tech lead or an eng manager, now anyone has become an agent manager. Here, it’s just anyone. So, if in the past you perhaps didn’t need to understand this concept as much, you only worried about this part, like,”

[16:55] I’m very good at backend, I can handle any backend ticket, “you know, very fast, very easily. Many people spent many years in their career as software engineers, as developers, just being programmers. Like, I’m very good at doing backend, I’m very good at doing frontend. I myself specialized in being a frontend developer. I was always very good at creating UIs, at managing to build really good screens with React and all that. So, instead of you necessarily learning React, CSS,

[17:28] Tailwind, or whatever else you would do in a stack, right, as a web dev. Now, the AI kind of does that for you, right ? Of course, you need to understand it to validate and all that, but AI does a large part of it. You’re supervising it ; your job has become much more about being an agent manager. So you need to understand the technique of how to assign tasks to an AI agent. And that’s exactly where SDD comes in.

[18:01] Now, before I continue showing you the best practices for a good SDD, I want to give you concrete examples of how user stories can become real-world tests, okay? So, for this, I will use Test Sprite, which is a partner of our channel and a partner in this video, to show you how what we’ve shown here on the board becomes reality, alright? So, consider the following, folks. Imagine I have this application of mine here called Canvas Collab, right? And it has several features. I can write, I can

[18:33] put a circle here, I can change the color. And all of this can be turned into a user story, okay? All of this can be something that will, you know, be done through an SDD, okay? And I want to do a test here with you so you can see how this works in practice, okay? I’m here in the Test Sprite interface, okay? So the link for you to test Test Sprite will be in the description, in the pinned comment. And here I have the option to add tests both with AI and manually. Let’s do it

[19:03] manually so you can see, okay? So I already have this Canvas Collab project set up in the Test Sprite dashboard interface, and we’re going to run a test. Here they call it a test case; you can think of this as a user story, right? Take a look at the example they provide. User can log in with valid credentials. It’s a user story. And here is the description, what this test verifies, okay? So let’s think about a simple test here, okay? Here in Canvas Collab. I can click here on this letter and change my name, okay? And then I

[19:34] can save it and that’s it. It’s right there. R. If I refresh, it keeps the R here because it’s saved in local storage, okay? So let’s create a test for this. Let’s state that I can click here and change my name. And then the first letter will be the letter of my name. We can create a test to ensure that this is working. So I can put something like this, for example. User can change name. This would be the title I’m looking to create. And then the description. The user should be able to click on the

[20:05] letter. change the name and the letter will become the first letter of the name. And here in Testprite it lets you add each step, right? Action, click, verify this or that, but you don’t even need to do that. You can simply put this test case here, see? It’s here as a planned test. I click here now and I can execute it. See that I can configure the timeout, I can configure the viewport. And look, Testprite has

[20:36] already started adding the steps, see? First, go to the Canvas site. Then click on the edit display name button. It’s already seeing it here, it’s already able to edit. And so we have the guarantee that what was a user story has a corresponding test that allows me to validate that my agent’s work was done well. And look at that, folks, finished. Testprite added a few other fields here. It even has a video that I can click and watch, see?

[21:08] Changed the name, saved it. Wonderful. See, it was Sen, changed to Alice, saved, and the A appeared there. So, alright, it’s working. I can move on to the next user stories and continue like this until my whole feature is complete , okay? I repeat the invitation for you to test Testprite for free via the link that is both in the description and in the pinned comment. Very well, folks. So, it became clear that if we just pass this prompt, it will be hard to

[21:38] validate the result. So, what would be the best way for us to work on this? All right? Typically, in a workflow with SDD, everything starts with an idea, right? You will have an idea here that will be fed from various sources. For example, it can come from your analytics, for example, it can come from user interviews. For example, it

[22:12] can come from session recordings. You go there and watch recordings of how people are using your app. Ah, it can also come from an executive order, right? Executive business order. Look, now we have to do this because we want to sell to such and such client. So all of this here will be the substrate for you to work on a feature, alright? And so, folks, this will evolve into what we call a PRD, okay? Which is a product

[22:47] requirements document, alright? And here, folks, there is no single way, no silver bullet for writing a PRD, but in this video I want to show you what I like to see in a PRD, alright? First thing, guys, a PRD has to be, you know, simple and short, okay? Please don’t

[23:19] do it, don’t create a giant document full of AI slop with a bunch of text that no one is going to read. Remember that a good people manager will be a good agent manager? No person is a good manager by handing over a file, a 10- page document full of text they didn’t write, asking their developer to read it, because they won’t, okay? So don’t do that. Make a PRD that is

[23:53] simple, that is short, and above all, that is human-friendly. Look, folks, I need to understand that. I need to be on the same page as whoever, you know, gave me the problem. And so, if I were to break a PRD into sections, I would do it this way: I would always establish the problem, okay? And again, this is a problem described for a human . Look, we have this problem and that

[24:25] problem. This is very important to do, because the problem is what will set the context of what you are solving, okay? And the context needs to be understood. Why? Because here we have the role of the one who sets the problem, the one responsible for execution, and the one who will do the implementation. You might have a PM here, you might have an engineer here, you might have an agent here. Often it will be the same person in three different roles, but they are three

[24:55] phases of the development cycle. Remember the PERA method? Prepare, execute, review. Each of these stages needs to be aware of the problem’s context, okay? So this is very important to have in the PRD. And of course, if you have the problem, you will also establish the solution. Look, we saw that this is happening and we want to solve it this way. This is typically where the user stories will enter, describing what needs to happen,

[25:26] right? After you have established the solution, now you will list what the constraints are, meaning, what is non-negotiable in the implementation, okay? This is usually something that is top-down, something that has either already been established or is based on some limit for a reason. Take our example here, right, from the course lesson, regarding the video player; we

[25:58] may have already established that the player will be via Cloudflare. Why? Because perhaps there was already research that determined Cloudflare is the best situation, or because the company already has an agreement with them, it doesn’t matter. This here is non-negotiable. You will put that in your PRD so the developer knows what they cannot touch and where they have creative freedom, okay? And then, after you’ve determined everything they cannot change, that’s when the criteria come in, the acceptance criteria, right

[26:33] , acceptance criteria. And here you will have a set of checkboxes for things that must be true for this project to be complete, okay? Why is this important, guys? Because how are you going to validate if the solution is adequate? You will validate it by checking, oops, if each checkbox is filled. So here in my cycle, right, of PERA, in the review stage, I can easily

[27:05] verify that everything established for me has now been done, okay? So, that’s why, guys, I consider it very important that you develop a PRD when working with SDD. SDD is the method. The PRD is a document that will give rise to several tickets. These tickets, then, will be units of programming work, okay

[27:36] ? The result of a ticket is a pull request. So, a ticket will generate a pull request, where you can review each of them much more easily. And then you go there, hey, I didn’t like this, redo this part here. Then I go and do it again. And then I go and approve it, okay? So the PRD gives rise to the tickets. And these tickets are worked

[28:09] on in isolation. But look how cool, because now that I’ve broken down what I want to do into various tasks, I can perhaps work in parallel, okay? This here can be parallelized. So, when you have this scheme well-executed in the PERA method, you can now accelerate things, because now you have six tickets to work on. But look, instead of having a huge thing here to review

[28:43] with, say, 127 files, you have now divided this into six parts of about 20 files each. But now, folks, you have an advantage, because each ticket can map to a specific acceptance criterion. So, this one is talking to criterion one, this one is pointing to criterion two and criterion three, this one to criterion four, and so on. So, I can always validate by keeping an eye on

[29:14] the PRD, mapping my code to what I wanted to develop in the beginning, okay? It’s much easier to have confidence in what I’m doing. And hey, guys, the last thing I wanted to do before ending this video is address the elephant in the room, which is: when to use the SDD, right, when do I need it, when do I need a PRD, folks, this will

[29:49] obviously depend on the complexity of the task. Well, guys, the greater the complexity of the problem, the harder it is to validate. And so, if it’s difficult to validate, it’s harder to trust the work, to trust the agent. So, if you need to have a high degree of confidence in the task that will be

[30:19] done, you need, one way or another, to do some kind of SDD. Ah, Rafael, isn’t it always that I need to have a high degree of confidence? I don’t know, sometimes the ticket has a low risk, right? If the ticket has low risk, if it is low risk, then you can, you know, afford the luxury of doing it in the prompt, maybe one prompt will solve it. Maybe one prompt will solve it. Maybe the assistant is good enough and you only need the prompt to solve it, okay?

[30:50] But realistically, how often will that happen? And better than that, every time you break a larger feature into these small features, these small ones become tasks that a prompt will solve. So, instead of giving one prompt to try to solve 10 things at once, you take what you wanted to do, you break it into 10 smaller things, and then yes, for that smaller task, you have much greater confidence that the prompt will solve it, folks. I talk about this and

[31:21] much more in much more detail and depth in my AI engineering training. That’s why I’ll repeat the invitation for you to sign up for the opening list for the AI engineer track, which will happen on September 30, 2026, at 7 o’clock. Sign up for the list so you can be notified. It is very important that you are notified, because we will have special conditions for the founding class, alright? So don’t forget to sign up so you can participate in our launch event . And I want to know from you now, have

[31:53] you been using SDD in your day-to-day life? Do you like the idea of writing a shorter PRD, breaking it down into acceptance criteria, and passing it to a developer, which could even be you, to then work with your agent? Tell me in the comments, because I want to know how you have been using agents for programming. I also take this opportunity to ask you to like this video and subscribe to the channel. Here we talk about everything regarding AI engineering, everything about agentic programming, and harness

[32:24] engineering. The fundamentals of AI engineering are recurring topics here on this channel. So, please, go ahead and subscribe, like the video, and share it. If you are on your phone, hit like, which also helps us a lot. I am immensely grateful to you for being with me until now. I thank Test Sprite for partnering on this video, and see you next time.