Full Course: Spec-Driven Development with Coding Agents transcript

Welcome to this course on specdriven development built in partnership with Jet Brains. Spec driven development is currently the best type of workflow for building serious applications with agentic coding assistance. Give your coding agent a markdown file or a long prompt explaining exactly what to build and it implements that spec. Rather than writing code by hand, you focus on writing down the context that the agent doesn't already have.

I'm delighted that our instructor for this course is Paul Everett, who's developer advocate at Jet Brains. Thank you, Andrew. And wait, I didn't know you wore spectacles. >> You're right. I don't actually need these. Okay, that's what I thought. Anyway, Spectrum development has three main benefits that you'll start to see right away. First, you can control large code changes with small changes to the spec. One sentence like use SQLite with Prisma or might affect hundreds of lines of code.

Change that to MongoDB for the same downstream amplification. This makes writing specs really efficient, far more so than writing code. Second, specs help eliminate context decay between sessions, preserving the non-negotiables. Agents are stateless, so loading them with the highest quality context right when they boot up is important. And finally, specs improve your intent fidelity. You define the problem, success criteria, constraints, and so on.

And the agent can elaborate to create a fuller plan. One way I often write a spec is by having a conversation with an agent like cloud code or Gemini or CHB codeex to make the key architectural choices using my knowledge of how I want to make different tradeoffs. Then have the agent summarize the key decisions in a markdown file. Writing a spec requires thinking and this is hard work. You have to decide what product you want to build.

What is features is technical architecture. And without the spec, you'd be leaving these important decisions up to the wins of the coding agent, which might be okay if you want to move really fast and just roll the dice, but certainly leads to less maintainable code and sometimes pretty weird products. For example, I've seen teams working on a complex software product where there was no clear spec and this led to many downstream headaches from these different coding agents under the direction of different developers building quickly but in contradictory ways.

Specdriven development involves developing a constitution at the project level to define the immutable standards then iterating through feature development loops. These loops isolate each feature on its own branch with plan, implement, and verify steps that leave a clean slate between features and reduce headaches and context switching. This same workflow supports both green field and brownfield projects. In green field projects, you start from scratch.

You'll develop the constitution in a conversation with the agent. In brownfield existing code bases, you'll generate the project constitution. based on the existing codebase. In both cases, you'll then iterate through these feature development loops, managing versioning in small steps. In this course, you'll also see how to write your own agent skills to automate your spec driven workflow. You know, if you can accomplish what you need in just one short prompt, that's great.

I'm definitely an advocate of lazy prompting when it works. But the great developers I know out there almost always will write detailed specs for projects with any significant complexity because they have unique context and an opinion on what or how to build that'll be superior to letting the OM which is missing that context pick randomly. If your coding agent is going to go off and write code for 20 or 30 minutes, which may correspond to several hours of traditional developer work, you're often better off sitting down for three or four minutes and writing it really clear instructions.

Many people have contributed to this course, including Constantine Chiker and Zena Smeova from Jet Brains and Isabel Zaro from deep learning.ai. Let's go on to the next video and let's write some specs. When you hear a coding, you might think vibe coding. Let's compare the two and see how specri development gives better results by bringing back engineering. Vibe coding gives quick results. You write a prompt describing what you want, like create me a button, and hope for the best.

Then you look at the result. That's a big button. It's kind of close, but off on some important things. So you point out the mistakes to the agent, it tries again and so on until you are satisfied. As a result, you will end up with a long dialogue with the agent the history of which will not even be saved. This approach works okay for a button, but it doesn't scale to a large ongoing project. While high-level prompts are fast, they lead to disposable code and mounting technical debt.

We need engineering, a well-maintained specification that creates a permanent technical artifact. Specdriven development is the professional response to the chaos of unsupervised AI generation. It is a paradigm shift where the specification explaining the what and why is decoupled from the implementation, the how. With specs, we get a contract between the humans, but also with the agent. Your main task as the human now shifts.

Learn how to convert your intentions into clear specifications. Spectdriven development with aentic coding assistance has three main benefits. First, you're able to control large code changes with small changes to the spec. A few sentences in the spec outlining the look and feel of the app might translate to hundreds of lines of CSS. This specdriven approach reduces the cognitive overhead needed for working with these ultra fast coding agents.

Second, specs eliminate the context decay problem that derails multi-turn agent sessions. As you work with your coding agent, its context window will fill up, often leading to more mistakes as the agent tries to cope with a full working memory. Specs persist between sessions and even agents, anchoring the agent to the core context needed to work in a codebase and implement a feature. Third, specs improve intent fidelity, meaning that the agent is more likely to produce code that matches your goals.

That's because specs force you to define the problem, success criteria, constraints, user flows, and so on before the agent starts generating code. Specs are a key differentiator between vibe coding some slop and engineering a viable software product. Whether you are starting a new project from scratch or want to implement the STD approach into a project that has been running for years, specs help solve the drift and productivity problems.

As a comparison, think of compilers which convert understandable source code into machine code. STD guides the agent and prompts converting specs into source code. Even better, the specs are in a human language, making it easy for stakeholders. Speciven development has taken off recently as a solution to concerns about productivity. Multiple STD projects, tools built around spec authoring, conference talks on capturing intent.

This is all part of a broader push to bring engineering lessons learned from the software development life cycle to agentic coding. Spectdriven development is used with coding agents, not simple chat bots. A chatbot can talk about code, but the chatbot doesn't have access to your project's code, nor tools you have installed. It just responds to your prompts. Agents are different. They take your prompt, make a plan, and guide themselves to a result using reasoning along the way.

Importantly, agents have access to your code base and your development tools. In the STD workflow, we treat these agents as highly capable pair programmers. They provide the technical knowledge and the speed and you, the senior architect, provide the blueprints. As we move forward in this course, remember the agent is the muscle, but the spec is the brain. With practice, you ensure that the software produced is not just functional, but is aligned with your long-term goals.

Speciven development tells the agent how to build what you want upfront for the project, then for each feature, getting better as you go. With STD, we help the agent with the best quality context. First with decisions about the project, then with details about each feature. This spec is very detailed. One key skill in STD is knowing the right level of detail. If you treat your agent as a highly capable pair programmer, you'll often hit the right level.

Lots of context about the goals, mission, target audience, and constraints and less about the low-level decisions the agent can figure out on its own. What does this SD workflow look like? First, we specify the constitution. What is the mission? The tech stack, the road map. A constitution is just one way to formalize these project level details. Many developers use a tople agents.md file for this purpose, but a project constitution is agent agnostic and more structured.

The constitution captures the agreement on key decisions between the human and the agent, but also the agreement between the humans. The mission explains the why, this project's vision, audiences, scope, etc. Defining these parameters in advance is very common in software projects and helps guide ongoing decisions. The tech stack is for the engineering team, a common understanding of development and deployment technologies and constraints.

The road map is a living document with a sequence of phases, each implemented with their own feature spec process. Once the constitution has been drafted, we work on each feature with a repeatable process. First, plan the feature, implement it, and finally validate the result. In between features, it's time for the replanning phase. Revise your constitution, update the road map, even improve the process itself. As you heard a moment ago, one of the key skills of STD is providing the right level of detail to create the highest quality context.

In the feature phase and the replanning phases, you steer the agent. Look at it this way. Imagine that you are an architect and you give detailed drawings of a building to builders. Then it's up to them. Your role is to design, supervise the construction, then review and accept the results or ask for changes. You'll want to avoid telling the builders how to do their jobs and focus on providing the context they don't know.

Spectriven development gets you from thinking at the start to delivering at the finish. Best of all, it keeps you improving from there. This is one std workflow that modern developers are starting to use. Soon we'll look at the start, the project constitution. But first, let's do a little setup preparation. To get set up with the project repo, follow instructions in the next reading item. The following video setup is optional.

If you're already comfortable with setting up a coding agent like Claw Code in an IDE such as WebStorm, feel free to skip this optional video. See you in the next video or the next one. Before you send your first prompt, let's talk a little bit about setting up your workspace. If you're already comfortable with setting up a coding agent like Claude Code in an IDE such as WebStorm, feel free to skip this optional video.

Spec driven development is a best practice that isn't tied to any specific IDE or coding agent. So you can choose the setup you're already using or the same one you'll see in this course. VS Code with the codec CLI, Z editor with a local model, all great for specdriven development. Since we are planning to develop a web application, this course will use the WebStorm IDE with Cloud Code as a coding agent. Instructions on downloading and installing both have been included in the previous reading item.

Let's open up WebStorm and start a brand new project named Agent Clinic. This will be a TypeScript project with a Git repository to keep close track of versioning your code and specs. Although many IDEs, including WebStorm, offer a chat panel, we know there's a lot of diversity in how you interact with your coding agents. In Spectrum and Development with agents, it's important to keep close track of versioning your code.

Let's say we want to create an initial commit using the agent. Every time it needs to execute a command, it will ask you for the confirmation unless you start clawed code in an unsafe mode. Pay close attention to what Claude code asks you to do. The ultimate responsibility for the code is yours. Throughout the coming lessons, you'll see several tricks and best practices for specri development with Git. Great. We've got our setup ready and you've got yours ready.

Let's get started. You need to tell your agent about your project, the mission, audience, and other decisions. In this lesson, we'll work together with the agent to write the constitution. What really is your project? Say you're working on a new web app for your company. What's the core idea behind its development? How does it fit within your company's preferred tech stack? what features are planned. These three foundational principles form the constitution, a global set of high-level requirements that will guide future feature development and explain the project shape to stakeholders.

For example, you have so many choices for your tech stack. You'll want to narrow down your options based on appropriate trade-offs and what you use at your company. We need to write this down for the agent, for your teammates, for the future. But we don't write it alone. We write it in a conversation with the agent. He'll be surprised at the great questions that we'll ask, architecture patterns you hadn't considered, external packages that already do the work, or tradeoffs, for example, speed versus data fidelity.

The emission, text stack, and road map aren't just properties of a green field project you're starting from scratch. Existing code bases use these three pillars, too. We will talk about bringing the SD workflow to existing projects in just a few videos from now. Here's the example project we'll use throughout this course. We are writing Agent Clinic, a place for AI agents to get relief from their humans. Agent Clinic is a fun parody of the popular learning project Pet Clinic.

Coding agents are doing a lot of work. It's stressful. Hallucinations, context, rot, memory issues, and co-worker sub agent coordination all take a toll on agent health. Let's build a clinic where they can get help with their issues. It's a full stack web app with a Nex.js backend and a React front end. The app allows you to manage appointments, ailments like hallucination, and treatments like a context infusion. Let's take a look at how you might go about writing a detailed spec for a project like this.

Let's chat with the agent. First, we provide our project description to the agent and tell it that our stakeholders gave their input in readme.md which we added to the repo. In the important note, we directly mention Claude codes ask user question tool. This tool is totally optional, but we just like the way it looks in the interface. Also, for the project's constitution, tell the agent to work with you on a mission, tech stack, and road map.

Spectriven development works best with a human in the loop approach where you review small changes. So tell the agent to organize the road map in small steps. As we work together, you'll see the agent asks some really good questions. You might see different ones. The first question says, "What tone should the mission MD take?" I'll choose, you guessed it, playful. That covers the mission. Now, some questions for the text stack.

Our engineers are used to TypeScript on the back end. So let's add that to the requirements. Next, for our road map, it asks how granular it should be. I'll choose the first option. We finished the initial interview. Let's choose submit answers. The agent will ask you for write permissions. This keeps changes under your control. If you are comfortable with the security trade-offs, you can select the option to approve all instances of a particular command for this session.

You'll see this in the rest of the course. Now, we're done and we have three files in the specs directory. Mission.md, text.md, roadmap.mmd. It's human in the loop time. Let's review. For example, the mission left out a target audience. That's reasonable. How could the agent know your business? Instead of editing directly, let's continue the conversation. To keep all artifacts consistent, it is better practice to ask the agent to make changes to them manually, and you might miss updating related documents.

We want to use SQLite for this project. Since this is a quick prototype, we didn't mention it, but the agent figured it out in recommendations. It's now part of our text stack. Do one final review. It's important to get everything right up front. Let's commit the constitution so it will be a living document for the project. Agent Clinic now has a constitution mission road map text stack to guide our project. We're ready to tackle our first feature.

We now have a road map with features. But how do we build them with specs of course starting with the first road map feature. Let's take a look at the agent clinic road map. Here's our phase one feature. Hello Hano. But it's too early to start coding. We need to discuss the spec and clarify all the details. A good plan outlines the approach, the sequence of work, and how to validate success. Let's start with fresh agent context.

The agent can get what it needs from the official source, the constitution. We will work on this feature in a separate branch, which we will indicate to the agent. Our prompt will help start a conversation with the agent about the feature spec, a plan for tasks, collect requirements, and a scorecard for validation. The agent will ask you to make key decisions. Pay attention to potential conflicts or problems. You don't have to agree with the solutions proposed by the agent.

Make sure to clarify anything that bothers you. First, regarding phase 1 scope, we'll keep it exactly as written. For the requirements, let's pin the HANA version and enforce strict TypeScript. For the confirmation, manual curl looks good. Then, let's submit. That was fast. Must have been the nano. Work is done and the ball is back on our side for reviewing the feature spec created by the agent. Let's review the feature plan first.

It's important to get these docs right in the beginning to keep the agent on track. If you find something wrong, ask the agent to fix it to make sure it keeps the requirements and validation in sync. For example, we would like a nice looking placeholder homepage in this first feature spec. We make the change via the agent. Next, the requirements. These were also updated to reflect the homepage update. This is the right place to indicate any important technical needs or constraints.

Don't speed through this, but don't state minor technical details like variable names here. We want to control the process, but not over steer the agent. Last, the validation. Make sure the agent can check that it got it right. Again, these were updated for the homepage. We're done with the feature spec. Let's create a commit in the IDE. Nice. We formulated a feature spec strategy. Made a feature branch. Interviewed with the agent about what the feature should do.

Put the results in markdown documents. Reviewed these spec files. Committed. The changes you make here in the specs will expand downstream into hundreds of lines of code. So time spent here is well spent. It's time for implementation. We're working on the plan for the first feature in the project roadmap. We finished the feature spec. Let's do the full implementation of this feature. Just to refresh ourselves, we do a quick review of this feature specs plan.

This was the first feature. Hello HANA. The feature spec documents have what we need. To start your implementation, you'll want to clear out your context with a slashclear command. Let's go back to the agent and enter a prompt to implement all the task groups. Sometimes you might choose to do task groups one at a time for even smaller steps and commits. This technique is especially helpful for areas where small mistakes can compound later, like in security or database management.

While claw is running, you can observe the changes it displays in the console to see its progress in real time. Afterwards, we can watch for the final changes in the commit window and visit the changes. This gives us an early jump on reviewing the work. This is the key role of the developer in such a paradigm to act as an architect or supervisor and ensure that the agent is provided with a clear contract. We can also see the summary of what was done.

As you can see, the agent provides extra details on the work performed for each of the task groups. Now, let's go to the package.json file and in there, let's run the app. The server starts in the console. The browser shows the result of this feature spec. Not much. We said nano, but it's a good feeling to see pixels on the screen. We just implemented a feature. The agent did its validation. In the next lesson, we'll do ours.

It's nice to have a feature ready, but don't merge yet. In this last feature step, we collaborate with the agent to review the work. Fortunately, programmers have good tools for this validation task. After all, programmers have long spent several hours per week on code review. Start with the commit view. Let's go through the changes. Focus your review on high-level concerns like whether the features work and reflect the spec rather than details like which CSS classes were implemented.

For example, the home.tsx is minimal. Nano really meant nano. We want a layout component with clear landmarks for header, main, and footer, but do these as subcomponents and create a CSS file. As it turns out, this mistake in the code flowed from a mistake in the plan. We didn't ask for this. Let's ask the agent to do the fix, thus correcting both spec and implementation. This process that consists of the agent generating something and us verifying it is known as the human in the loop.

Because agents are so fast at writing code, software developers have lately been talking about cognitive debt, the mental load of tracking what your code is doing and how it has evolved. That is why in order for this process to be fast and easy to control and to reduce cognitive debt, the changes should be manageable. The agent is making our changes but also validating that these changes didn't break anything. Good news, the agent finished and gave us a quick summary.

You can also see this in the editor. The feature plan was changed to add a group five to list these new steps. The code now has a layout component and a CSS file was added. It looks like the three subcomponents were just put in the same file, but that doesn't follow conventions. Let's put these in their own files using the IDE move tool. These kinds of changes are easy in editors and we've always been good at this. No need for an agent, right?

Let's just do it. Not so fast. This can lead to drift where other artifacts, specs, readmes get out of sync. Let's ask the agent to fix any mentions and to make sure this doesn't waste some time later. All changes are done. Did we break something? Test would help, but the agent didn't install our testing package. Since this is needed for all features, we'll cover it in the next lesson. Now, we're ready to mark this work as complete and merge our results.

Notice that the part of the constitution was updated alongside the feature in this branch. How to handle versioning of the specs and how to associate which specs created which code changes is an evolving topic in the community. The change to the road map is small. Just checking off a step in the road map. So, it's okay to keep these updates on the same branch. If the overall constitution update is more complicated, it might be better to do this in a separate branch.

Now, we're ready to mark this work as complete and merge our results. We just used specdriven development to develop and validate our first feature. But wait, shouldn't we take another look at the project's broader scope? We successfully implemented the first feature. Can't wait to do it again and again. Don't rush into it. Take a step back and reflect with some replanning. You have to run slow to run fast. We have a workflow step called validation.

Tests are good for validation, but we didn't give the agent all our testing preferences. Let's make a replanning branch to update the text stack in our constitution. As you saw in the previous video, spec versioning is an evolving topic. The Constitution is a living document. It's good practice to make updates to it in its own separate branch so you can keep track of which versions of it produced which code. We'll use a prompt to state our policy.

It looks like the agent updated the package.json just to have a script, no dependency. Something to note for later when we do run tests. This change to add a testing framework applies to future code. But let's tell the agent to update existing feature specs and implementation based on this constitution change. After these two prompts, we have some good changes. The agent set up this testing change but didn't write the test themselves.

Let's tell the agent to write some new tests. With this setup, we can run tests conveniently in our editor. Let's run under the debugger to give us a chance to step through code execution as part of the human in the loop. Looks good. We now have tests as part of validation. Let's commit. Sometimes we realize we want to do something differently in the product plan. For example, after implementing the first feature, we got an update from the product manager.

Because 40% of our users are on mobile, we want to emphasize a responsive design. Let's go to the agent. Tell the agent we want responsive design and to correct the product specs and feature specs as well as any code. Since we're so early on in development, this update is a small change. So, it makes sense to directly implement it during replanning. But if the new work is big, it's better to schedule it on the road map as its own feature phase instead of just doing it in replanning.

Use your judgment. Remember, we want the specs to capture decisions, not just the code. We want to try to keep both in sync to help team communication. The agent has implemented our responsive fix with updates not just in code but also to the product and feature specs. Time for us to do our part and review the changes. Let's go through the diffs. This looks good. Let's do a commit. Remember, working in small steps with frequent commits keeps the review from overloading your brain.

While this first part of replanning is working, let's step back and do some project housekeeping. For example, let's revisit the project road map and look at the next task. Does it still make sense? The road map shows the next feature which we cover in the next lesson. Is it still the correct one? Looking through the road map, it looks like features 2, three, four, and five kind of hang together. Let's update the road map to tackle those in one step.

We'll commit and start on this new feature shortly. The replanning step can be about a feature or the whole project, but replanning can also be about improving your specdriven development workflow across projects across your organization. For example, maybe you have a few non-technical stakeholders that want to monitor the project's progress. You'd like it to update a change log on each merge domain. Most AI coding agents support skills, a package of instructions and resources providing the agent new capabilities and expertise.

Skills are great for definable, repeatable workflows that require context specific to your project or organization. A skill would be great for implementing a change log update. You could write this skill by hand, but many agents actually have skills that help you write a skill. Let's use the agent to help us write and maintain a change log skill. The agent gets to work. One thing for us to consider is this skill unique to this project or should it be a standard part of all projects.

This is a style choice and you'll gain better understanding as you use it. You'll learn to automate your STD workflow with skills. For example, your validation step might include updating the readme, linting, formatting, test running, and other quality checks. You can work with your agent to package those into a validation skill. Repeatable process, less manual work. The agent is finished. We can scroll through the window to see what it created and how to use it.

Note that it chose to create this in the global skills area. This skill will now be usable across all projects. Also, cloud code used the new skill to generate a change log in this project. Change logs are how you talk to your stakeholders, including the agent. So, let's open it and review it manually. Looks good. We are finished with this replanning work. Let's wrap up with a commit, then merge the branch. Now that most of your work as a developer is in planning and validation rather than implementing, make time between features to replan.

In the next video, we'll work on another roadmap feature. We have an improved constitution and an improved workflow. We're getting better. But before moving on to the next road map feature, let's tackle some strategies to deal with a common pain point. AI fatigue. Agents can generate a lot of code with a lot of changes. This massive amount of code makes the human in the loop validation exhausting. So much to review. To fight this confusion, make sure you have a clean division between each feature phase.

We should start each feature in the right flow state. Do I have unfinished work? Did I merge the last feature branch to main? Is the next road mapap item the right thing to do? Did I clear the A's context to ensure the specs capture the intent instead of memory snapshots and to let it focus its limited context budget on the next work. Take a moment to make a good start to help yourself finish. We've done all this. Let's clear the context and start the next feature, agents and ailments.

As a note, we keep typing the same thing. We'll talk about how you can streamline this repeated prompting into a custom workflow in a future lesson. As before, the agent asks good questions. The first one is about whether to keep all these features in one phase. We already decided to do this together in the previous lesson, so we'll say yes. For the migrations, we'll choose plain SQL. For validation, let's select one, two, and three.

That's good. Now, let's submit. When the agent drafts the spec, we can see some of its choices. The agent's reasoning process is useful to watch. If you're using an agent with verbose mode, that could give you even more insight into its intermediate ideas. Looks good. But we want to make one small change to capture our intent. We want to use Pico CSS as our CSS framework. Next, we review the three files in the feature spec.

Starting with the requirements. Let's ask the agent to change the requirements to make sure any other files reflect the change. When the work is finished, let's commit the feature spec. This time, we'll let the agent come up with the message. With the spec for the second feature ready, let's go to implementation. The division between the planning phase and the feature phase helps us to not overflow context. Ours and agents.

If the feature seems too big to implement all at once, ask the agent to implement part of the feature plan first. This will keep the size of the changes manageable. Our agent has implemented the phase 2 feature. We watched the agents progress so we have a rough idea of what was done. But that's not enough. Slow down. Do some thinking. Let's do an indepth review of the changes. Everybody has their own style on how much to review the agents results.

To play to the agents strengths and reduce AI fatigue, stick to higher level requirements. Avoid nitpicking stuff like variable names. Just make sure it creates code that you can commit under your name. For example, it used inline type information for the props. We'd like the prop definition in a standalone TypeScript type. Let's tell the agent to fix this everywhere in the code. You probably didn't include this decision in your spec.

Remember, an emission such as extracted prop types isn't a failure. You are evolving the spec as you discover new details, and capturing that leads to better future results. We're finished with our review. This is a good moment for another smallstep commit. Last step, validation. Let's review what the agent plans to do for the validation step in this features spec. Looks good. Let's do our validation. Remember, we want to make sure the changes are good by running the application.

But we also want to prevent cognitive debt by validating that we understand these changes. Tests are a great place to work through the flow. Let's read some tests and run them under the debugger as exploration. Sometimes you need to validate that you weren't lied to. Tell the agent to spawn several sub aents to do a deep review of the entire project with this feature change. This deep review gives the agent more space to think about the changes and using sub agents preserves the main agents context window rather than polluting it.

These sub agents will come back with a number of issues and recommendations. All of these look good. So, let's proceed. The agent goes off, does a bunch of fixes, runs tests, and gets our project into a good state. Keep this in your tool chest. The agent can usually find important issues during a second look. Once we are finished with our validation, our feature is complete. It's time to commit our feature work. As our last step on this feature, let's use the change log skill that we made in the previous lesson.

We've now documented the changes on this feature branch. One more commit, then merge the branch. In a previous lesson, we saw the replan step in between features. Let's do a quick version of this by looking at the road map. Does the next feature still seem right? Looks good. Our project is in good shape, ready for the next feature. This clean break between features helps manage AI fatigue. Now you can take a break for some coffee.

We're starting to see a repeatable STD process for feature development. One that captures our decisions. In the next step, let's test that hypothesis. Do we have enough to build an MVP? We made a lot of progress. two features implemented with our spec workflow, but management just asked of course for an MVP. Have we made enough progress to do an experiment? Let's do a variation of our standard feature spec prompt. This time, we'll tell it to implement the rest of the road map and give some guidance about existing feature specs.

In general, you should only implement such a large chunk if you feel confident in the quality of your constitution and spec. The better the context you provide your agent, the more confident you can be in getting a result aligned with your intentions. And you should be sure that you can handle review and validation. But since we've taken this risk, now let's view the MVP as an extreme test of our constitution and completed feature specs.

If we now get something different from what we wanted, it means we need to very responsibly carry out another replanning phase to eliminate whatever led the agent astray. The agent asked me some questions. Again, these are good questions and recommendations. A lot of spec files start as a back and forth conversation with an agent. Finished with the interview and we selected submit answers. Let's write the MVP specs to disk.

It's always good to review the specs. You'll often notice incorrect assumptions the agent made to fill the gaps. Let's give a quick look at the plan, the requirements, and the validation. As always, we like to work in small steps with frequent commits. Let's save the planning stages feature spec. We are finished with planning. It's time for the agent to go do a big implementation step. The agent now does a lot of work.

Once it's finished, it's showtime. Let's see the MVP. We'll go to our scripts to run the application. As you can see, each section now has much more driven by sample data queried from the database. At this point, usually we would validate the code results, but this is an MVP. Let's ask the agent to validate the specs. As it turns out, this was useful. The agent showed places where the MVP found holes in our planning.

We can share this evaluation with the stakeholders for their MVP review, then merge or archive the branch. Our specdriven workflow succeeded. After a constitution and two features, the MVP produced a useful demo thanks to our guidance. Of course, not all software projects involve building an MVP. Many projects are so-called brownfield. They start from an existing codebase. Next, let's see how to introduce this workflow to legacy projects.

People say spec driven development and even AI are only good for green field projects, but STD is also good for existing legacy projects. In this lesson, we'll introduce STD to an existing project. To make it easy, we'll start with a project you already know, the agent clinic MVP. We'll make it a legacy by starting on main without the specs folder in a new cloud code session in a different project directory. We have some project background in the readme.md file with some open work listed in to-do.md.

Your legacy project might have full product plans in issue trackers, spreadsheets, word documents, etc. Remember our workflow? We'll start with the constitution step. We'll use almost the same prompt from lesson 4. This time we'll tell it to look for road map items in existing artifacts. In this case, a to-do file. Remember, the agent will discover and in a sense reverse engineer the SD artifacts from the existing codebase.

The constitution will help align future code changes made by the agent with what past devs have already created. You can always add more context if you have it. For example, you might have been dropped into this project in order to improve its efficiency while implementing highly requested features. The process is the same, but the conversation might be richer as the agent has more artifacts, code, commits, documents, etc.

You'll see a lot of tool calls here as the agent explores the codebase. Let's look at the constitution for our legacy project. In the mission, we have an audience, the project idea, and some extra information about the project. The text stack shows that Claude extracted the project file structure, framework versions, and the clarifications we were asked. In the road map, we can see the work is organized in phases matching the to-do file.

Let's create a commit for the constitution files that we produced with a commit message. Remember that in SDDD specs are part of your versioning strategy. Our legacy project is now placed on an SD foundation. From now on, the workflow is exactly the same as we discussed in previous lessons. First, we grab the next feature on the road map and plan it in a conversation with the agent. We'll be doing phase one feedback form.

Very good. We now have a branch and specs for this feature. Let's review the feature spec, the plan, the requirements, and the validation. Then we commit the feature spec. After we have made any corrections by chatting with the agent, we proceed to implement the feature. Once the agent is finished, we do our validation to make sure the code is good and the feature works as expected. Our feature loop is done. We can commit and then merge the branch domain.

Now it's time for replanning. Make sure you give time for this. Since you just added SDDD into your project, you may find a lot of things to tune. We now have a legacy project rebased onto specdriven development without a bunch of manual work. This gives us a well doumented flow working in steps using engineering and staying in control. The spec is now the memory of the project. Just don't fade. You've now mastered an SD workflow.

Want something faster and lighter weight? In this lesson, we will automate things, but doing it our way with a custom process. We previously showed agent skills, an open standard to give agents new capabilities and expertise. For example, we repeat the same prompt when starting a feature spec. Do this, do that, write these three files. Let's automate this with a skill and with help from the agent to write it. Ask the agent to use its skill creator to talk through this with us.

As a note, there are many of these skill skills in the community that you can also install and use. As the agent runs, it might ask some follow-up questions. These are usually quite good. When the interview is done, we submit the responses and the agent proceeds. While the agent is working on the skill, keep an eye on the output. Is it making the choices you wanted success? As you can see, the agent wrote the skill to this directory.

As a note, skills can be per project or global. Skills can be invoked in several ways. In your prompt, refer to the skill before saying what to do. Also, you can ask the agent to call a skill from another skill. According to the skills open standard, agents use the skill description to decide when to call it in a process called progressive disclosure. But their judgment isn't always perfect, especially as the context window gets larger.

Use the same heristic as file tagging. If you know you want a skill used, name it. That saves you some thinking tokens. Agents have built-in slash commands like slashcle. Though initially popular, many agents are moving from custom slash commands over to skills. Sometimes you need to give the agent more resources like access to some API, a private knowledge base, database and so on. Until now, the universal way to extend an agent has been MCP model context protocol.

For example, agents need current quality context about packages. The most popular choice, context 7, an MCP that brings updated documentation of packages into your agent context. Now your agent can stay upto-date with React 9.2 and higher instead of React 9.0. MCP servers are still popular, but skills that use code tools like a CLI command line interface often accomplish the same purpose more elegantly. Contact 7 now suggests this a skill that calls a CLI tool for context 7.

Let's install the context 7 package for claude code. During the setup, we see this immediately a choice between MCP server and CLI plus skills. We'll use the second choice. If this is your first time, you'll need to make an account. We already did so and logged in. Once done, we can go back into clawed code and put it to use with an example prompt that uses context 7. As the agent runs, we see it detects the need to use context 7.

When it completes, the agent shows it now knows how to find out information about our text stack. This trend from MCP servers to skills plus CLI is accelerating. People are rethinking MCP because CLI tools can take action with less setup and less context usage. As you scale your workflow implementation, skills, etc., you will want to share it with yourself across machines with teammates, perhaps with the outside world.

Some agents, such as Clawed Code, have plugins, a collection of agent extensions that can be installed and updated. There's a growing community of free plugins. Check them out to see if any will boost your SD productivity. Remember, plugins are not yet a cross agent standard. Like apps or dependencies, plugins can execute code, so make sure you trust them on install and update. GitHub's spec kit is one attempt at formalizing a specdriven development workflow with agents.

Installing specit for a project gives you access to slash commands in your agent similar to the workflow you used in this course. Specit.comstitution plan tasks and implement. Another popular alternative is openspec from visionai. Openspec follows a similar propose explore apply archive workflow where propose and explore match with the plan step. apply matches with implement and archive matches with replanning. It also has canonical patterns for quick features.

Both packages include helpful features like branch management, verification scripts, and opinionated spec document formats. I encourage you to experiment with these open- source workflows to help refine your own. Sometimes in the middle of a feature, you have an idea. You want to research it with the agent, but you don't want to stop your branch work. For example, a choice of databases, but you're not yet committed to this idea, so you don't want it on the road map.

The conversation produces some good ideas and some good questions. We accept most of the recommendations, but change our mind on one of them. You don't want to lose it. So, let's keep a backlog of research by telling the agent to write a report in a well-known location. This file is a record of your conversation and results. You can later ask the agent to schedule this research on the road map with a link to the backlog file.

As this grows, you can write a skill to automate your research. Specdriven development helps the agent write code your way. You can adopt an existing STD framework or tool, then customize it using skills to operate your projects with your team your way. Specdriven development moves the work from the how to the what and why. Since agents and models progress so fast, you don't want your workflow tied to just one choice.

In this lesson, we see how standards let us switch agents while keeping our workflow and even our tools. These agent standards help for this goal. MCP for external tools, agents.md for rules, agent skills for capturing repeatable workflows with extra context, and ACP for connecting agents to clients. For example, Codeex is a leading AI agent from OpenAI. It runs in a desktop app and in editors as well as in a terminal.

Let's see it in action. Here is our feature spec skill from lesson 12 copied into codecs which stores them in a different path. It runs just fine once migrated. This lets you switch back and forth between agents in the same project, keeping your SD workflow. We can also use different editors with different agents using the agent client protocol standard. ACP makes it easy to connect agents and editors. If your agent and client support ACP, you have a perfect match.

To make this plug-and-play even easier, the ACP registry automates finding, installing, and connecting agents within clients. The ACP registry covers the whole life cycle, making it easier to mix and match. For example, in Jet Brains, the AI chat window leads to installation from the ACP registry. The IDE can then show a listing of compatible agents. Open Code is a popular open-source agent. The ACP registry makes it easy to add to our IDE.

Clicking install automates both the installation of Open Code itself if needed, which is nice, and integration into the IDE. Once finished, your IDE now has native integration with a new agent. You can use this new agent alongside the other agents in your same editor as part of SDDD. These new agent standards are bringing new possibilities. But how do they actually work? The ACP architecture was designed to ease plugging together agents and clients.

In fact, the protocol matches what's used in LSP. ACP is more than you think. For example, it covers next edit suggestion in the editor and plan mode. To go one step further with ACP, you can write your own custom agent installed locally in your tool. Which agent to choose? The industry changes fast and benchmark sites have sprung up with leaderboards providing different evaluations. Of course, these leaderboards change fast.

So, make sure to keep up to date and base your decision on the criteria that matter to you. Our specs work at a higher level, not tied to any one agent or IDE. In this lesson, we prove that we built our workflow and tools to be independent of the agent. As more standards emerge, this flexibility should grow. Great work completing this course. You've seen how to go from vibe coding where you hope the agent does what you want to specriven development where you get closer to what you actually need.

You've written constitutions, planned features through conversation, validated as the human in the loop, and automated your workflow with skills and standards. The specs you write today become the memory of your projects tomorrow. Keep them sharp. Keep improving your process. And remember, the best code starts with a great spec. You and many of the engineers I know may have seen the consequences of moving too fast. Let's bring back some engineering.

Let's keep you as the driver of your software. I really care about finding the joy and purpose in all things, and I'm excited to see what you do with this. Take it sleazy. Go do some cool stuff.