Phase 3: The Generate-Validate Loop · 40 min · Claude Code · Python

The Generate Phase: Steering Agents Effectively

Prompt from the spec, not from the vibe. Review the plan before there's any code to get attached to.

Hiring signal: The gap between 'make it better' and a specific, actionable correction is exactly what separates engineers who steer agents effectively from those who just re-roll the dice on the same vague prompt.

What you will learn

Prompt an agent from a written spec's acceptance criteria rather than an unstructured description
Explain why reviewing an architecture plan before code exists catches problems more cheaply than reviewing after
Break a large spec into buildable chunks sized for one generation pass
Distinguish specific, actionable feedback from vague feedback that just triggers another guess

Introduction

The Generate Phase: Steering Agents Effectively

Two engineers each ask an agent to implement the same acceptance criterion from a spec: "stacked discounts must never produce a negative price, applied sequentially, capped at 100% per coupon." The first types roughly that sentence into the agent and lets it go. The second does the same thing, but first asks the agent to lay out its planned approach — which function it'll modify, what the loop structure will look like, how it'll handle the cap — before generating a single line of code. The plan reveals a problem in ten seconds: the agent intends to cap the sum of all coupons at 100%, not cap each individual coupon at 100% before applying it sequentially, which is a different (and wrong, per the spec) behavior. The second engineer catches this before any code exists. The first engineer catches it, if they catch it at all, after reviewing a finished implementation that already "works" in the sense that it runs — reviewing architecture inside code that's already written is measurably harder than reviewing architecture as a plan, because by the time code exists, there's a sunk-cost pull toward accepting what's there instead of a clean comparison against what should be there.

Prompting from the spec, not the vibe

This phase assumes you already have a spec, built in c12-01, and a context architecture, built in c12-02. The generate phase's job is narrow: turn a spec's acceptance criteria into a prompt an agent can act on directly, instead of re-describing the feature from memory in whatever words feel natural in the moment. "Add discount stacking" is a vibe. "Implement discount stacking per spec/spec.md's acceptance criteria: discounts apply sequentially, each individual coupon capped at 100%, and the final price must never go negative — see test cases 1-3 for expected behavior" is a spec-grounded prompt. The second version isn't just more polite phrasing of the first; it gives the agent the actual constraints instead of leaving it to guess them, which is exactly what c12-01's "why specs before code" lesson was building toward using them for.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Plan mode: review the architecture before it's code, Breaking big specs into buildable chunks, Specific feedback versus vague feedback, Build It — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.

Key terms in this lesson

Agent