[Next Vibe Coding] Step 2: The Implementation, Review, and PR Workflow—Verify AI-Generated Code Before Trusting It
When AI says “implementation complete,” do you take it at face value? This Step 2 course has Claude Code and Codex handle everything from understanding the repository to implementation, testing, review, and PRs, while teaching you to evaluate results based not on completion descriptions, but on the scope of approval, execution evidence, and change risks.
You can read the AI’s completion report divided into the approval scope, execution evidence, changes made, and unverified items.
By defining permissions, branches, environments, and baselines, you can safely delegate implementation to agents.
You can look at the diff and test results to determine whether it’s okay to merge now or whether you need to ask more questions.
The Next Step After Vibe Coding · Stage 2
[Next Vibe Coding] Step 2: Before trusting AI-generated code
“I’ve completed the implementation.” How much should you trust that statement?
Once you’ve organized the specifications in Step 1, it’s time to entrust the actual coding. But the moment the agent says, “It’s all done,” it can be daunting to know what to look at before accepting it. No one else will tell you whether the tests ran, whether it touched files outside the plan, or whether it’s safe to merge.
This course is not about writing better prompts. It is a two-stage course where you entrust Claude Code and Codex with everything from understanding the repository to implementation, testing, review, and PRs, and judge the results based not on completion descriptions, but on the scope of approval, execution evidence, and the risks of the changes.
Learn together that “I built it” and “I verified it” mean different things.
01 · Reframing the Problem
A completion report is a claim, not a result.
The agent confidently explains what it did. However, that explanation may contain or omit actual test results, changes that were not in the plan, or items that were not verified. If you merge based solely on the explanation, it can be difficult to trace back later what went wrong and where.
It’s not because artificial intelligence (AI) lies. It’s because we haven’t decided what evidence we’ll accept as a basis. Step 2 is about deciding where to verify that evidence before entrusting it and after receiving it.
Scope of approval
Did it change only within the plan I approved?
Execution evidence
Did the tests, type checks, and linting actually run, and are the results recorded?
Changes made
Can you explain the changed files and the reasons for the changes using the diff?
Unverified items
What is written as not verified?
If you can answer these four questions, you’ll have a standard for reading completion reports. The course addresses these questions one by one in the order of safeguards, repository understanding, planning, implementation, testing, review, and PRs.
02 · From Assignment to Merge
Let's go through the process of assigning a feature, checking it, and merging it together.
First, buckle up the seatbelt.
Separate permissions for reading, editing, running, and making external changes, and use branches and Worktrees to isolate them from the original work. Distinguish between development and production environments, and before implementation, record a baseline to check whether any tests were already failing. You need to start from a reversible state to delegate work in small increments.
Then, have it read the repository and align on the plan.
Before writing code, have the agent investigate the repository structure, rules, and relevant code, then review its record. Receive an implementation plan, define the approval scope and work order, and only then allow the first change. The Stage 1 specification is transformed here into the brief for today’s work.
Finally, I read the evidence and make judgments based on the diff.
Learn the rhythm of building small and checking immediately, and receive test results as execution records rather than words. Find changes outside the plan in the Diff, distinguish between “ready for review” and final merge approval, and leave even unverified items in the PR.
03 · One Continuous Example
Add a cancellation feature to the meeting room reservation service.
You need to follow a feature from beginning to end to see how the scope defined in the plan carries over into implementation, testing, review, and the PR. Therefore, from Lesson 1 through Lesson 30, we use the task of adding a “cancel your own reservation that has not yet started” feature to a meeting room reservation service as one continuous example.
This isn’t meant to explain the reservation service itself. It’s an example used to show how small decisions—such as identity verification, pre-start conditions, and the scope of notifications—manifest in permissions and planning, Diffs, and tests.
It follows directly from the specification in Step 1.
If Stage 1 taught you how to organize the goal, scope, and completion criteria, Stage 2 is the process of turning that specification into actual code. Even if you haven’t taken Stage 1, you can follow along as long as you can write down the goal, scope, and completion criteria yourself.
Over the course of 30 lessons, we'll proceed in this order.
We start with how to read a completion report. We establish safeguards around permissions, branches, the environment, and the baseline, then read the repository and align on the plan. We build in small increments and verify immediately, use tests as evidence, review the diff and make a judgment, then wrap up with a PR—bringing the 30 lessons together.
04 · Check Before Enrolling
This is a good fit for people who:
Those who have completed Step 1 and now want to entrust us with the actual coding.
Those who constantly wonder how much they should trust PRs created by AI
Those who use Claude Code or Codex but lack criteria for reviewing the results
Those who want to establish a workflow for safely integrating agent work into their team
This isn’t a follow-along hands-on course.
This isn’t a course on completing an app in a specific language. Each lesson is about 7 minutes long, and across 30 lessons, we’ll read through the agent’s research notes, plans, execution results, and Diffs together to develop sound judgment. We focus on a review workflow that you can apply directly to your next task, regardless of which tool you use.
I’ll answer only the questions you’re likely to have first.
Is it okay if I didn’t attend Step 1?
That’s fine. If you can organize the goal, scope, and completion criteria on your own, you can start right away. You’ll see the specification from Step 1 transformed into a brief in the first section of Step 2, so if you’re curious, you can refer back to Step 1 then.
Do I have to write the code myself?
No. There are no coding exercises, assignments, or environment setup. You’ll simply read through the code created by the agent, the Diff, and the test results together. What matters isn’t how quickly you write code, but knowing what evidence to use when deciding whether to accept the results you receive.
Would it be okay to listen at increased speed?
I enhanced the instructor’s audio with AI to reduce noise and improve pronunciation. I improved the sound quality and pronunciation so that the explanation remains clear even when listening at 2× speed.
Recommended for these people
Who is this course right for?
Those who have completed Step 1 and now want to entrust us with the actual coding.
Those who constantly wonder how much they should trust PRs created by AI
Developers and planners who use Claude Code and Codex but have no standards for reviewing the results
Need to know before starting?
It’s helpful if you’ve completed Step 1 (the core principles of SDD) or can independently organize the objectives, scope, and completion criteria.
You don’t need to know programming syntax. Terms like branches, tests, diffs, and PRs are explained in the course.
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.