[Next Vibe Coding] Step 1: The Core Principles of SDD That Reduce AI Rework by 80%
Do the results of vibe coding keep turning out differently from what you intended? Learn a workflow that uses specification-driven development (SDD) and Spec Kit to define goals, scope, business rules, and completion criteria, then shares the same specifications with Claude Code and Codex to reduce repetitive revisions.
I can turn an ambiguous request into a specification containing the Goal, Context, Constraints, and Done when.
You can distinguish the roles of Spec, Plan, Tasks, and Implement, and verify the results of AI implementation.
The Next Step After Vibe Coding · Step 1
[Next Vibe Coding] Step 1: Reduce rework with SDD
The code comes out quickly, but why do we keep going back to the beginning?
When you try vibe coding, it’s truly fast. But as soon as a feature becomes even slightly complex, you reach a point where you think, “This isn’t the flow I had in mind.” By the time you add more explanations, fix it again, and check it yet again, the time you saved at the beginning quickly disappears.
This course isn’t about writing impressive prompts. It’s an introduction to SDD, where you surface the decisions you need to make before building and ensure those decisions carry through to implementation and verification.
Rather than learning how to give instructions effectively, let’s practice together what needs to be decided first to keep things on track.
01 · Reframing the Problem
The problem wasn’t the length of the prompt.
If you ask, “Build an expense request feature,” you’ll get results quickly. But if it’s unclear who submits and who approves, what statuses exist, and what counts as complete, the implementation can keep changing.
It’s not because the artificial intelligence (AI) worked carelessly. It’s because it filled in the parts we hadn’t defined in its own way. SDD is a method for identifying these gaps before coding.
Goal
What problem are you trying to solve?
Context
What is the current situation?
Constraints
What rules must be followed without fail?
Done when
What needs to be verified for it to be considered complete?
If you can answer these four questions, the specification can be brief. Conversely, if the answers are missing, even lengthy requirements can easily fall apart. SDD is less about creating piles of documents and more about ensuring that important decisions aren’t overlooked.
02 · From Decisions to Implementation
We carry a feature through together from start to finish.
First, we identify the decisions that are missing.
We follow the order in which users actually move through the product, drawing out the scope, states, permissions, and exceptions one by one. You don’t need to write a perfect document from the start. Answer the questions and expand the specification only as much as needed.
Then, make sure decisions don’t get lost between documents.
We examine why the Constitution, Spec, Plan, and Tasks are separated. Rather than memorizing difficult document names, focus on how the goals and completion criteria defined in the feature specification carry through to the plan and tasks.
Delegate the implementation, but judge for yourself whether it’s finished.
Have the AI Agent investigate the repository and propose an implementation approach. The human reviews the pros, cons, and risks, then chooses one. After implementation is complete, don’t simply trust “It’s done”; check the test, type-checking, lint, and build results.
03 · One Continuous Example
This is not a course on how to submit expense claims.
You need to follow one feature from beginning to end to see how the decisions defined in the Spec carry through to the Plan and Tasks, implementation, and verification. That’s why Lessons 1 through 29 use an expense approval system as one continuous example.
The goal isn’t to explain expense operations themselves. It’s an example used to show how user flows, states, permissions, exceptions, data, and interfaces connect within an SDD document.
At the end, we completely change the example.
In Lesson 30, we move on to reservation cancellation and refund features. We’ll apply the questions and workflow we learned earlier to a new problem and check whether the same approach can be used for other features as well.
Over the course of 30 lessons, we’ll proceed in this order.
We start by understanding why SDD is needed. We write as much specification as necessary and define the scope and user flow. After working through the states, permissions, and exceptions, we connect the data and interfaces. Then we choose the implementation approach, break down the work, and hand it off to an agent to carry out the implementation and verification, followed by handling changes.
04 · Check Before Enrolling
This is a great fit for people who want to:
Those who frequently have to fix AI-generated results again
Those who want to reduce the decisions that fall through the cracks between planning and development
Those who want to create an AI coding workflow that can be reused by their team
Those who felt unsure about what to check after assigning a feature task.
This isn’t a course where you simply follow along to recreate a finished app.
This isn’t a class where you replicate an app using a specific language or framework. While you’ll learn primarily through the GitHub Spec Kit workflow, the focus isn’t on memorizing commands. Instead, we focus on a flow of specification, planning, and validation that you can apply again to future features.
I’ll start by answering only what you’re likely to be curious about.
Is it okay if I don’t have much development experience?
That’s okay. You don’t need knowledge of any specific language or framework. If you’ve run a basic command in a coding agent at least once, you’ll be able to follow along more easily.
I’m currently using Claude. Do I really need to install Codex too?
No. In the course, we provide the same specification to Claude Code and Codex, but it’s perfectly fine to follow along using whichever one you’re more familiar with. What matters is not the tool, but how consistently you communicate the goal and the criteria for completion.
Is it okay to listen at a faster speed?
I enhanced the instructor’s audio with AI to reduce noise and refine the pronunciation. I improved the sound quality and pronunciation so the explanation remains clear even when listened to at 2× speed.
Recommended for these people
Who is this course right for?
An early- to mid-level developer who repeatedly reworks AI-generated results because they differ from their intentions
Planners and PMs who want to clearly communicate product goals and business rules to Claude Code and Codex
Need to know before starting?
No prior knowledge of any particular language or framework is required.
It would be good if you could install Claude Code or Codex and run basic commands.
I am Haeyeo, someone who explores the infinite possibilities of AI and computer science and wishes to share that journey with all of you.
During my undergraduate years, my passion for my major was so intense that I was nicknamed a 'Computer Science Addict.' I graduated at the top of my class with a major GPA of over 4.4. I then earned my Master's degree in AI from Seoul National University and further deepened my expertise through a doctoral program.
However, as I felt as much of a fascination for solving real-world problems with AI as I did for theoretical exploration, I took a break from my doctoral studies to gain valuable hands-on experience by working on AI-based LLM and video analysis projects at a startup.
Currently, I am working as an LLM project developer and PM at one of the top three conglomerates in Korea, contributing to creating positive changes that AI technology will bring to our lives. I will generously share with you the challenges I faced, the problem-solving processes I went through, and the vivid know-how I gained in the field. I will be your reliable guide on this journey into the exciting world of AI.