Full Course: Spec-Driven Development with Coding Agents

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 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., 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 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.

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