Por que aprender SDD para programar com agentes de IA

Author: Rafael Quintanilha – QuantBrasil · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Por que aprender SDD para programar com agentes de IA · Channel: Rafael Quintanilha – QuantBrasil · 32:24 · Watch on YouTube

Topics: AI agents, Software engineering with AI

Summary

Spec-Driven Development (SDD) helps make agentic programming more reliable by turning a broad idea into clear specifications, smaller tasks, and criteria that can be checked. The video introduces the PERA workflow—prepare, execute, review, and accelerate—and explains how SDD strengthens the preparation and review stages. A concise PRD can describe the problem, solution, constraints, and acceptance criteria, then lead to tickets that are easier to implement, review, and parallelize. The level of SDD needed depends on task complexity and the confidence required: a low-risk task may need only a prompt, while larger features benefit from being broken down first.

Key points

As AI agents handle more ambitious tasks, it becomes harder to verify that their work matches what was intended.
PERA stands for prepare, execute, review, and accelerate; acceleration is most effective after the earlier stages are well structured.
SDD means Spec-Driven Development: development guided by specifications that can be checked against the resulting code.
A user story can be decomposed into smaller front-end, back-end, and other implementation tasks, reducing ambiguity for an agent.
Acceptance criteria make it easier to review whether a ticket or feature is complete.
A PRD should be short, simple, and human-friendly, and should explain the problem, solution, constraints, and acceptance criteria.
A PRD can generate tickets, each producing a pull request that is easier to review and map to specific criteria.
Breaking work into smaller tickets can enable parallel execution and improve confidence in the result.
The need for SDD depends on complexity, risk, and how much confidence the task requires; a small, low-risk task may be handled with a prompt.

Chapters

Start	Chapter	Summary
00:00	Why SDD matters for AI agents	The video introduces the challenge of validating increasingly complex work from AI agents and frames SDD as a possible solution.
03:39	The PERA workflow	PERA organizes agentic programming into preparation, execution, review, and acceleration.
06:49	What Spec-Driven Development means	SDD uses specifications prepared in advance so code changes can be checked against what the system is supposed to do.
09:30	From user stories to implementation tasks	The example of watching a purchased course lesson shows how a user story can be expanded into smaller requirements and tasks.
15:20	Managing agents through task breakdown	The video compares managing agents with leading a development team and argues that task assignment and breakdown are increasingly important.
18:01	Turning user stories into tests	A Canvas Collab example demonstrates creating a test for a user story and using it to check whether the behavior works.
21:38	Writing a useful PRD	The video describes how ideas can lead to a concise PRD that explains the problem, solution, constraints, and acceptance criteria.
27:05	From PRD to tickets and pull requests	A PRD can produce isolated tickets that are easier to review, map to acceptance criteria, and potentially work on in parallel.
29:14	When to use SDD	The video recommends choosing the level of SDD according to task complexity, risk, and the confidence needed in the result.
31:21	Closing remarks	The speaker invites viewers to discuss their use of SDD and closes with channel and video acknowledgments.

Quotes

You say what you want to be done, you say how your system needs to work — 07:55

This is what we call spec-driven development. — 15:20

Make a PRD that is simple, that is short, and above all, that is human-friendly. — 23:19

you will validate it by checking, oops, if each checkbox is filled. — 26:33

The greater the complexity of the problem, the harder it is to validate. — 29:49

Concepts and entities

Spec-driven development, PERA method, test-driven development (TDD), Behavior-driven development (BDD), user story, Product requirements document (PRD), Acceptance criteria, TestSprite, Canvas Collab, Rafael Quintanilha

Full transcript (original language)

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.