Module 6: The Fundamental Workflow — Research → Plan → Execute → Validate
Research → Plan → Execute → Validate: The Fundamental Workflow
Description
This capsule is the most important of the module — and possibly of the entire guide. Here you learn the four-phase workflow that the most effective developers use with coding agents: Research → Plan → Execute → Validate.
It's not a theoretical framework invented for this guide. It's the common pattern that emerges from observing how productive developers work with AI, documented by Anthropic, validated by the METR study, and practiced in teams that consistently get good results.
The Problem This Workflow Solves
The most common (and most costly) pattern
Developer receives a task
│
▼
"Hey Claude, implement authentication with JWT"
│
▼
Claude generates 200 lines of code
│
▼
Developer: "Looks good" → accepts
│
▼
3 hours later: it doesn't work with the existing auth middleware
│
▼
3 more hours: complete refactoring
│
▼
Total time: 6+ hours
(Time if they had researched first: 2 hours)
Why it happens
- Illusion of speed: The agent generates code in seconds, so it seems "fast"
- Completeness bias: Seeing code that compiles gets confused with code that works
- Hidden cost of debugging: Fixing generated code without context takes more than writing it well
- Lack of process: Without a defined workflow, every task is an improvisation
What the METR study revealed
The developers who were slower with AI shared a pattern: they went straight to "Execute" — they asked the agent to implement without researching first what existed, without planning the approach, and without defining how to verify.
The developers who were faster did something consistent: they separated thinking from execution.
The Workflow: Research → Plan → Execute → Validate
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ RESEARCH │ ──▶ │ PLAN │ ──▶ │ EXECUTE │ ──▶ │ VALIDATE │
│ │ │ │ │ │ │ │
│Understand│ │ Design │ │ Direct │ │ Verify │
│ before │ │ before │ │the impl. │ │ before │
│ acting │ │ coding │ │ │ │declaring │
│ │ │ │ │ │ │ victory │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
│ │ │ │
▼ ▼ ▼ ▼
Complete Defined Directed Verified
context approach code confidence
The fundamental principle
Think before executing.
Each phase produces a "deliverable" that the next phase needs. If you skip a phase, the next one operates with incomplete information — and you produce incomplete results.
Phase 1: Research — Understand Before Acting
What it is
Research is the phase where you build context. You're not coding — you're understanding. The goal is to have a complete picture of the problem, the constraints, and the existing code before making a single implementation decision.
The most common error
Skipping Research because "I already know how to do it." The problem isn't that you don't know how to do authentication — it's that you don't know how authentication works in this specific codebase.
What to research
1. CODEBASE CONTEXT
→ What already exists?
→ Are there established patterns?
→ What conventions does the project follow?
→ Is there similar code that could serve as a reference?
2. TECHNICAL CONTEXT
→ What dependencies are available?
→ What versions?
→ Are there technical limitations?
→ What APIs/services are involved?
3. BUSINESS CONTEXT
→ What problem exactly does it solve?
→ Who uses it?
→ What edge cases matter?
→ Are there non-functional requirements?
4. RISK CONTEXT
→ What can go wrong?
→ What parts of the system does it affect?
→ Is it reversible?
→ What level of confidence do I need? (from Module 05)
How to use the agent for Research
The agent is extraordinarily useful in this phase — probably more useful here than in Execute. The difference is that you ask it to explore, not to implement.
── EFFECTIVE PROMPTS FOR RESEARCH ──
✅ "Explore the src/auth/ directory and explain how the current
authentication works. Don't change anything."
✅ "Read the project's configuration files and list
the dependencies related to authentication."
✅ "Find all the authentication middleware that exists
and show how it's used in the routes."
✅ "Analyze the database schema for the users
and sessions tables. What fields are there?"
── INEFFECTIVE PROMPTS FOR RESEARCH ──
❌ "Implement authentication with JWT"
(This is Execute, not Research)
❌ "How does JWT work?"
(This is general education, not Research of the codebase)
❌ "Read the whole project"
(Too broad — no focus)
The deliverable of Research
By the end of Research, you should be able to answer:
□ What already exists that's relevant?
□ What patterns does the codebase follow?
□ What technical constraints are there?
□ What level of confidence do I need? (trust calibration from M05)
□ What can go wrong?
If you can't answer these questions, you're not ready to plan.
How much time to invest in Research
Simple task, known codebase → 2-5 minutes
Moderate task, known codebase → 5-15 minutes
Complex task, new codebase → 15-30 minutes
Task with high risk → 30+ minutes
The rule: invest 10-20% of the total estimated time in Research
Concrete example: Research
TASK: Add rate limiting to an existing REST API
RESEARCH (10 minutes):
1. "Claude, explore the routes in src/routes/ and show
how they're organized. Don't change anything."
→ I discover: They use Express with a middleware chain pattern.
2. "Is there any rate limiting middleware already implemented
or any dependency like express-rate-limit?"
→ I discover: express-rate-limit is already in package.json
but is only used on the /api/auth/login route.
3. "How are the global middleware configured vs per-route?
Show me examples from the current codebase."
→ I discover: The global middleware go in app.ts,
the specific ones in each router file.
4. "Are there tests for the existing middleware?"
→ I discover: Yes, in src/__tests__/middleware/.
They use supertest. There's an established pattern.
CONTEXT BUILT:
→ Express + middleware chain
→ express-rate-limit already available, underutilized
→ Clear pattern for middleware (global vs per-route)
→ Existing tests with supertest as a reference
→ Risk: low (an extension of an existing pattern)
Without Research, the developer would have asked "implement rate limiting" and the agent would have generated a solution from scratch — possibly installing a new library, with a different pattern from the codebase, without tests, and without taking advantage of what already existed.
Phase 2: Plan — Design Before Implementing
What it is
Plan is the phase where you define exactly what you're going to do and how. You're not coding yet — you're making design decisions with the information Research gave you.
The most common error
Planning in your head without externalizing it. If the plan isn't written, it isn't a plan — it's an intent. The difference matters because:
- A written plan is verifiable. You can review it before executing.
- A written plan is communicable. The agent can follow it.
- A written plan is evaluable. Afterward you can compare plan vs result.
What a plan includes
1. APPROACH
→ What general approach am I going to use?
→ Why this one and not another?
2. CONCRETE STEPS
→ An ordered list of what's going to be done
→ Each step is specific and verifiable
3. FILES INVOLVED
→ What files get created?
→ What files get modified?
→ What files get deleted?
4. EDGE CASES
→ What atypical scenarios should I consider?
→ How do I handle them?
5. DEFINITION OF "DONE"
→ How do I know I finished?
→ What tests should pass?
→ What acceptance criteria are there?
How to use the agent for Plan
── EFFECTIVE PROMPTS FOR PLAN ──
✅ "Based on what we explored of the codebase, design a plan
to implement rate limiting. Don't code yet — just
the plan with files to modify and concrete steps."
✅ "Propose two approaches for this task. For each one,
list pros, cons, files involved, and risk.
I want to choose before implementing."
✅ "Review this plan and tell me if I'm missing something:
[your plan]. Are there edge cases I'm not considering?"
── INEFFECTIVE PROMPTS FOR PLAN ──
❌ "What should I do?"
(Too vague — it doesn't guide the agent)
❌ "Make a plan and then implement it"
(Combines Plan + Execute — you lose the chance to review)
The key moment: separating Plan from Execute
⚠️ THIS IS WHERE MOST PEOPLE FAIL ⚠️
"Plan and implement rate limiting" ← This combines Plan + Execute
You lose the review checkpoint
"Plan rate limiting. Don't implement." ← This separates the phases
"[You review the plan]" You have the chance to:
"Okay, implement according to the plan." → Detect problems
→ Adjust the approach
→ Add constraints
Concrete example: Plan
TASK: Add rate limiting to the REST API
RESEARCH: ✅ Completed (context from the previous example)
PLAN (5 minutes):
APPROACH:
Extend the use of express-rate-limit that's already in the project.
Configuration by levels: global (general), per route group
(auth more restrictive), and a reusable middleware.
STEPS:
1. Create src/middleware/rateLimiter.ts with configurations per level
2. Apply the global rate limiter in app.ts
3. Apply the specific rate limiter in src/routes/auth.ts (already partial)
4. Add rate limit headers to the responses (X-RateLimit-*)
5. Add tests in src/__tests__/middleware/rateLimiter.test.ts
6. Update API documentation if it exists
FILES:
→ Create: src/middleware/rateLimiter.ts
→ Create: src/__tests__/middleware/rateLimiter.test.ts
→ Modify: src/app.ts (add global middleware)
→ Modify: src/routes/auth.ts (replace ad-hoc implementation)
EDGE CASES:
→ What happens when the limit is exceeded (response 429 + Retry-After)
→ Rate limiting in the testing environment (must be disableable)
→ Different limits for authenticated vs unauthenticated
DEFINITION OF DONE:
→ Rate limiting works globally and per route
→ Tests pass (happy path + rate exceeded)
→ Rate limit headers present in the responses
→ The ad-hoc implementation in auth.ts is unified
How much time to invest in Plan
Simple task → 2-5 minutes (it can be mental, but write it down)
Moderate task → 5-15 minutes
Complex task → 15-30 minutes (here the plan saves hours)
Team task → 30+ minutes (the plan becomes a shared document)
The rule: invest 10-15% of the total estimated time in Plan
Phase 3: Execute — Direct the Implementation
What it is
Execute is the phase where the code gets written. But "execute" doesn't mean "I give the plan to the agent and go get coffee." It means actively directing the implementation, step by step, verifying each step before advancing to the next.
The most common error
Delegating the whole implementation in a single prompt. This produces:
- Too much code to review at once
- Compound errors (an early error contaminates everything that follows)
- Loss of control over intermediate decisions
The principle: incremental implementation
❌ A SINGLE PROMPT (risky):
"Implement the whole rate limiting plan"
→ 400 lines of code
→ Multiple files modified
→ Where's the error if something fails?
→ What intermediate decisions were made?
✅ STEP BY STEP (controlled):
"Implement step 1: create rateLimiter.ts with the configurations"
→ Review → Okay
"Now step 2: apply the global middleware in app.ts"
→ Review → Adjustment → Okay
"Step 3: integrate into the auth routes"
→ Review → Okay
When to use a single prompt vs step by step
A SINGLE PROMPT works when:
→ The task is simple and well-defined
→ The codebase is familiar to you
→ Trust calibration: LIGHT (from Module 05)
→ The code is easily reversible
STEP BY STEP is necessary when:
→ The task is complex or multi-file
→ The codebase is new to you
→ Trust calibration: COMPLETE or FOCUSED
→ Errors are costly to revert
How to direct the agent during Execute
── TECHNIQUES FOR EFFECTIVE DIRECTION ──
1. REFERENCE TO THE PLAN
"Implement step 3 of the plan: [specific reference]"
→ The agent has clear context
2. EXPLICIT CONSTRAINTS
"Implement X. Don't modify Y. Use the pattern that already exists in Z."
→ You reduce the agent's decision space
3. CHECKPOINT AFTER EACH STEP
"Show me what changed before continuing."
→ Incremental verification
4. EARLY CORRECTION
If something isn't right: "Stop. The approach for X should be Y.
Rewrite only that part."
→ You don't let an error propagate
5. ADDITIONAL CONTEXT WHEN NECESSARY
"For this step, keep in mind that [a constraint you discovered
in Research that the agent might not know]"
→ You compensate for the context window's limitations
The developer's role during Execute
Developer during Execute:
You are NOT: You ARE:
→ A spectator → A director
→ An automatic approver → An active reviewer
→ A passive user → A technical collaborator
Your job:
→ Verify each step before advancing
→ Detect when the agent takes an incorrect path
→ Provide context the agent doesn't have
→ Decide when to accept, adjust, or redo
Concrete example: Execute
TASK: Add rate limiting
RESEARCH: ✅ | PLAN: ✅
EXECUTE (directed implementation):
Step 1:
Developer: "Create src/middleware/rateLimiter.ts with three levels
of rate limiting: general (100 req/15min), auth (20 req/15min),
and strict (5 req/min). Use express-rate-limit which is already
installed. Follow the pattern of the other middleware in src/middleware/."
Agent: [generates the file]
Developer: [review]
→ Note: the agent used windowMs in milliseconds correctly ✅
→ Note: the handler for when the limit is exceeded is missing
→ "Add a custom handler that returns a JSON with a
message, retry_after in seconds, and status 429."
Agent: [adjusts]
Developer: [review] → ✅ Next step.
Step 2:
Developer: "Now apply the general rate limiter in app.ts.
Put it after the cors middleware and before the routes.
Show me the diff."
Agent: [modifies app.ts]
Developer: [review]
→ Correct. Middleware order respected. ✅
Step 3:
Developer: "Integrate the auth rate limiter in src/routes/auth.ts.
Replace the ad-hoc implementation that already exists in login."
Agent: [modifies auth.ts]
Developer: [review]
→ Note: the agent kept the ad-hoc one AND added the new one
→ "Delete the old ad-hoc implementation. Only the
new middleware should remain."
Agent: [fixes]
Developer: [review] → ✅
[... continues with tests and documentation ...]
The difference from "vibe coding"
VIBE CODING:
"Implement rate limiting" → accept → hope it works
DIRECTED EXECUTE:
Defined plan → step-by-step implementation → review each step
→ real-time adjustments → early correction → controlled result
The difference isn't the tool — it's the level of direction.
Phase 4: Validate — Verify Before Declaring Victory
What it is
Validate is the phase where you confirm that what was implemented really works, meets the requirements, and doesn't break anything existing. It's the step that turns "it seems to work" into "it works."
The most common error
Confusing "compiles" with "works." The code can compile, the types can be correct, and yet:
- An edge case isn't covered
- The integration with another module is broken
- The logic is incorrectly implemented but syntactically valid
- A race condition appears only under load
What to validate
1. FUNCTIONALITY
→ Does it do what it should do?
→ Does it handle the edge cases defined in the plan?
→ Does it work with real data, not just the happy path?
2. INTEGRATION
→ Does it work with the rest of the system?
→ Do the existing tests still pass?
→ Are there unexpected side effects?
3. CODE
→ Does it follow the codebase's patterns?
→ Is it maintainable?
→ Does it have the necessary tests?
4. AGAINST THE PLAN
→ Was everything the plan defined implemented?
→ Is the definition of "done" met?
→ Are there deviations from the plan that require justification?
How to use the agent for Validate
The agent can be extremely useful for validation — and most developers underuse this capability.
── EFFECTIVE PROMPTS FOR VALIDATE ──
✅ "Run the existing tests and show me the results."
✅ "Review the code we just implemented and look for:
uncovered edge cases, logic errors, and possible
security problems."
✅ "Compare what was implemented with the original plan.
Is something missing? Are there deviations?"
✅ "Write tests for the edge cases we defined:
rate limit exceeded, authenticated vs non-
authenticated user, counter reset."
✅ "Try to break this implementation. What would happen if
I send 1000 simultaneous requests? If the header
X-Forwarded-For is faked?"
The "definition of done" as a checkpoint
DEFINITION OF DONE (from the Plan):
[✅] Rate limiting works globally and per route
[✅] Tests pass (happy path + rate exceeded)
[✅] Rate limit headers present in the responses
[✅] Ad-hoc implementation in auth.ts unified
[ ] Edge case tests (authenticated vs unauthenticated)
→ MISSING: I need to add this test
Without this checkpoint, I would have declared "done" without noticing
that an edge case defined in my own plan was missing.
Concrete example: Validate
TASK: Add rate limiting
RESEARCH: ✅ | PLAN: ✅ | EXECUTE: ✅
VALIDATE:
1. "Run npm test and show me the results."
→ 47 tests pass, 0 fail ✅
→ The existing tests didn't break ✅
2. "Run the new rate limiting tests."
→ 5/5 pass ✅
→ Happy path: ✅
→ Rate exceeded (429): ✅
→ Retry-After header: ✅
3. "Review the implementation against the plan. Is something missing?"
→ Agent: "The plan mentioned different limits for
authenticated vs unauthenticated. The current
implementation uses the same limit for both."
→ Developer: Good catch. I add that distinction.
4. "Try to break the rate limiting. Are there bypasses?"
→ Agent: "If the proxy doesn't send X-Forwarded-For
correctly, all the requests look like they come
from the same IP."
→ Developer: I configure trust proxy in Express.
5. Check against the original plan:
[✅] Rate limiting global and per route → works
[✅] Tests → pass
[✅] Headers → present
[✅] Unification → completed
[✅] Auth vs unauth → fixed in validation
[✅] Proxy trust → configured in validation
RESULT: Done, with two corrections found in Validate.
Without the Validate phase, those two corrections (auth vs unauth, proxy trust) would have become bugs in production.
The Complete Workflow: Integrated View
┌─────────────────────────────────────────────────────────┐
│ R → P → E → V │
├──────────┬──────────┬──────────┬─────────────────────────┤
│ RESEARCH │ PLAN │ EXECUTE │ VALIDATE │
│ │ │ │ │
│ 10-20% │ 10-15% │ 40-50% │ 20-30% │
│ of the │ of the │ of the │ of the │
│ time │ time │ time │ time │
│ │ │ │ │
│ Build │ Define │ Direct │ Confirm │
│ context │ approach │ implement│ it works │
│ │ │ │ │
│ Agent: │ Agent: │ Agent: │ Agent: │
│ explore │ propose │ code │ test + review │
│ │ │ │ │
│ You: │ You: │ You: │ You: │
│ ask │ decide │ direct │ verify │
│ │ │ │ │
│ Output: │ Output: │ Output: │ Output: │
│ complete │ defined │ directed │ verified │
│ context │ plan │ code │ confidence │
└──────────┴──────────┴──────────┴─────────────────────────┘
Recommended time distribution
For a 2-hour task:
Research: 15-25 min │████░░░░░░░░░░░░░░░░│
Plan: 12-18 min │███░░░░░░░░░░░░░░░░░│
Execute: 50-60 min │█████████░░░░░░░░░░░│
Validate: 25-35 min │█████░░░░░░░░░░░░░░░│
The distribution seems counterintuitive: only 40-50% of the time
is "coding." But that 50-60% of R+P+V is what makes
the 40-50% of Execute effective.
The compound effect
WITHOUT a workflow:
Task 1: 4h (should be 2h — extensive debugging)
Task 2: 5h (same problems as task 1)
Task 3: 4h (repeats error patterns)
Total: 13h
WITH R→P→E→V:
Task 1: 2.5h (research + plan take time the first time)
Task 2: 2h (you already know the codebase better)
Task 3: 1.5h (research is faster, plan more precise)
Total: 6h
The investment in R+P+V pays off quickly because:
→ Research reduces rework
→ Plan reduces incorrect decisions
→ Validate reduces the bugs that reach production
→ Each cycle improves your knowledge of the codebase
Adapting R→P→E→V to the Size of the Task
Small task (30 minutes)
R→P→E→V compresses but doesn't disappear:
R: "Is there something similar in the codebase?" (2 min)
P: "I'm going to do X, modifying Y, testing with Z" (2 min, mental)
E: Directed implementation (15 min)
V: Tests + quick review (10 min)
Medium task (2-4 hours)
Complete R→P→E→V:
R: Codebase exploration + technical context (15-30 min)
P: Written plan with steps, files, edge cases (10-20 min)
E: Step-by-step implementation with reviews (60-120 min)
V: Tests + integration check + plan review (30-60 min)
Large task (days/weeks)
R→P→E→V expands and can have sub-cycles:
R: Deep research, possibly with exploratory prototypes (hours)
P: A formal plan, possibly a document shared with the team (hours)
E: Multiple implementation cycles, each with its own mini-R→P→E→V
V: Complete test suite, peer review, staging (hours/days)
The adaptation rule
The workflow ALWAYS applies.
What changes is the INTENSITY of each phase.
Never:
→ "The task is small, I skip Research"
→ "I already know what to do, I skip Plan"
→ "It works on my machine, I skip Validate"
Iteration: When Validate Fails
R→P→E→V isn't always linear. Sometimes Validate reveals problems that require going back to earlier phases.
R → P → E → V
│
├─ All good → ✅ Done
│
├─ Minor bug → back to Execute (quick fix)
│
├─ Design problem → back to Plan (re-approach)
│
└─ Missing context → back to Research (investigate more)
When to go back to each phase
GO BACK TO EXECUTE when:
→ A minor bug, a clear fix, it doesn't change the approach
GO BACK TO PLAN when:
→ The approach doesn't work as you expected
→ You discover a constraint that changes the design
→ The real complexity is greater than estimated
GO BACK TO RESEARCH when:
→ You were missing critical context
→ You discover a system you didn't know existed
→ The requirements changed
NEVER:
→ Force a solution that doesn't pass Validate
→ "It sort of works" isn't a Validate pass
Practical Exercise
Exercise 1: Apply R→P→E→V to a real task
Choose a task from your current project (or invent a realistic one) and plan how you'd apply R→P→E→V:
TASK: _______________________________________________
RESEARCH (what you'd research):
1. _______________________________________________
2. _______________________________________________
3. _______________________________________________
PLAN (what you'd define):
→ Approach: ________________________________________
→ Steps: ___________________________________________
→ Files: ________________________________________
→ Definition of done: ______________________________
EXECUTE (how you'd direct):
→ One prompt or step by step? Why? ______________
→ What constraints would you give the agent? _______________
VALIDATE (what you'd verify):
→ Tests: ___________________________________________
→ Integration: _____________________________________
→ Plan check: ______________________________________
Exercise 2: Diagnose your last task with AI
Think about the last task you did with a coding agent:
1. Did you do Research before starting?
□ Yes, I explored the codebase □ No, I went straight to coding
2. Did you have a defined Plan?
□ Yes, written □ Mental □ I had no plan
3. Was Execute directed or delegated?
□ Step by step with reviews □ One prompt and I accepted
4. Did you do Validate?
□ Tests + review □ "If it compiles, it works"
Result: How many phases did you skip?
→ 0 phases: Excellent — you already practice R→P→E→V
→ 1 phase: Good — identify which one and reinforce it
→ 2+ phases: Here's your opportunity to improve
Common Mistakes
| Mistake | Consequence | Correction |
|---|---|---|
| Skipping Research | Implementing without context, rework | Always explore first |
| Combining Plan + Execute | You lose the review checkpoint | Separate: plan → review → execute |
| Execute in a single prompt | Too much code, no control | Incremental implementation |
| Validate = "it compiles" | Silent bugs, edge cases | Tests + review + plan check |
| R→P→E→V only for large tasks | Small tasks also fail | Adapt the intensity, don't remove phases |
Summary
R→P→E→V is the workflow that separates productivity from luck:
RESEARCH: Understand before acting
PLAN: Design before coding
EXECUTE: Direct, don't delegate
VALIDATE: Verify before declaring victory
Distribution: 10-20% + 10-15% + 40-50% + 20-30%
The workflow:
→ Always applies (adapt the intensity, don't remove phases)
→ Isn't linear (Validate can take you back)
→ Improves with practice (Research gets faster)
→ Produces predictable results (vs improvisation)
Next capsule: 03 - Workflow variants — PRD→Plan→Todo→Code, Spec-first + TDD, Explore→Plan→Code, and when to use each.
Resources
- Anthropic: Claude Code Best Practices — "Think big, start small" and the recommended workflow
- METR Study: Developer Productivity — Evidence that methodology matters more than the tool
- Agentic Coding: Workflows — Documentation of workflows with coding agents
- Kent Beck: Test && Commit || Revert — The principle of verification before commit, applicable to R→P→E→V