Module 6: The Fundamental Workflow — Research → Plan → Execute → Validate
Common Anti-Patterns: What NOT to Do with Coding Agents
Description
This capsule is a mirror. You'll probably recognize yourself in at least two of the anti-patterns we describe here. That's normal — we've all committed them. The goal isn't to judge but to name the destructive patterns so you can recognize them when they happen and correct before they cost you time.
The five anti-patterns we cover are the most frequent and most costly when working with coding agents: vibe coding, prompt-and-pray, context dumping, premature automation, and the sunk cost fallacy with AI.
Anti-Pattern 1: Vibe Coding
What it is
Vibe coding is accepting AI-generated code based on the "vibe" — it looks good, it seems complete, it compiles — without verifying that it really works, is correct, or follows the codebase's patterns.
The term was coined by Andrej Karpathy in 2025 and he described it as: "just seeing stuff, saying stuff, running stuff, and just vibing."
How it manifests
DEVELOPER VIBE CODING:
1. "Claude, implement a login endpoint with JWT"
2. Claude generates 150 lines of code
3. Developer: [skims for 5 seconds]
4. "Looks good" → accepts
5. Moves to the next task
6. 3 days later: "why doesn't the token expire?"
WHAT THEY SKIPPED:
→ Didn't verify the expiration configuration
→ Didn't verify the refresh token handling
→ Didn't check against the existing implementation
→ Didn't run tests
→ Didn't review edge cases
Why it's tempting
→ It's FAST (at the start)
→ It generates code in seconds
→ The code LOOKS professional and correct
→ It gives a sense of productivity
→ Completing tasks fast feels good
Why it's destructive
→ Initial speed ≠ total speed
→ Post-acceptance debugging is more expensive
→ You accumulate technical debt silently
→ You lose understanding of your own codebase
→ You become unable to maintain code you "wrote"
When vibe coding is acceptable
Vibe coding isn't ALWAYS bad. In Module 01 we said there's a spectrum:
ACCEPTABLE:
→ Quick prototypes you're going to throw away
→ One-time scripts
→ Exploring ideas (not production)
→ Personal code without users
NEVER ACCEPTABLE:
→ Production code
→ Code others are going to maintain
→ Security code (auth, payments)
→ Code with real users
The correction
VIBE CODING → AGENTIC DEVELOPMENT
Instead of:
"Implement X" → accept → next
Do:
Research → Plan → Directed Execute → Validate
(The workflow of this module)
Warning sign:
→ "Looks good" without having read the code
→ Accepting in less than 30 seconds
→ Not running tests
→ Not comparing against the plan
Anti-Pattern 2: Prompt-and-Pray
What it is
Prompt-and-pray is giving the agent a vague prompt, expecting it to understand exactly what you need, and "praying" that the result is correct. It's different from vibe coding: in vibe coding you accept without verifying; in prompt-and-pray the problem is that the prompt doesn't communicate what you really need.
How it manifests
PROMPT-AND-PRAY:
"Make the app faster"
→ Agent: optimizes something that wasn't the bottleneck
"Fix the login bug"
→ Agent: fixes a symptom, not the root cause
"Add validation"
→ Agent: adds validation in the frontend,
but you needed the backend
"Implement caching"
→ Agent: implements in-memory caching,
but you needed distributed Redis
The destructive pattern
Vague prompt
│
▼
Agent interprets (possibly wrong)
│
▼
Result isn't what you wanted
│
▼
"No, not like that. Do it differently"
│
▼
Agent reinterprets (better or worse?)
│
▼
3-5 iterations of trial and error
│
▼
Result: mediocre after a lot of time
Why it happens
1. EXPERTISE ASSUMPTION
The developer assumes the agent has the same context
they do — but it doesn't.
2. LAZY COMMUNICATION
It's easier to write "fix the bug" than to describe
the bug precisely.
3. EXPECTATION OF MAGIC
"It's AI, it should understand what I mean"
→ LLMs are good at following instructions
→ They're bad at guessing vague intentions
4. NOT THINKING BEFORE WRITING
Prompt-and-pray reveals that the developer
didn't think about what they want before asking for it.
The correction
PROMPT-AND-PRAY → PRECISE PROMPT
Instead of:
"Fix the login bug"
Do:
"The bug is: when a user with an email containing '+'
(like test+1@email.com) tries to log in, the server
returns 500. The error is in src/auth/validate.ts
line 45 where the email is parsed. The probable cause
is that the regex doesn't accept '+'. Fix: update the regex
to accept '+' in the local part of the email."
The difference:
→ What's wrong (symptom)
→ Where it is (location)
→ Why it happens (probable cause)
→ What you expect (desired result)
The "30-second prompt" rule
If writing the prompt takes you less than 10 seconds,
it's probably too vague.
The sweet spot: 30-60 seconds writing a clear prompt
saves 10-30 minutes of back-and-forth.
FORMULA:
[WHAT TO DO] + [WHERE] + [CONSTRAINTS] + [EXPECTED RESULT]
"Add rate limiting [WHAT]
to the POST /api/users endpoint [WHERE]
using express-rate-limit which is already installed [CONSTRAINT]
with a limit of 10 requests per minute per IP [RESULT]
and a 429 response with a Retry-After header [RESULT]"
Anti-Pattern 3: Context Dumping
What it is
Context dumping is loading the agent with too much information at once — pasting complete files, extensive logs, entire documentation — expecting the agent to "figure out" what's relevant. It's the opposite of prompt-and-pray: instead of too little context, it's too much.
How it manifests
CONTEXT DUMPING:
"Here's all the code of my project:
[pastes 5000 lines of code from 20 files]
Add a notifications feature."
"This is the error log:
[pastes 500 lines of log]
What's wrong?"
"Read this documentation:
[pastes the complete README, CONTRIBUTING, and 3 more docs]
Now implement what section 4.2 says."
Why it's destructive
1. SATURATED CONTEXT WINDOW
LLMs have a context limit.
Filling the context with irrelevant information
displaces the relevant information.
2. SIGNAL DILUTION
The agent doesn't know what's important in the sea of text.
The relevant information gets lost in the noise.
3. AMPLIFIED HALLUCINATIONS
More context isn't always = a better result.
Contradictory or confusing context INCREASES hallucinations.
4. LATENCY
More tokens = more processing time.
More time = more cost.
The correction
CONTEXT DUMPING → CONTEXT CURATION
Instead of:
"Here are 20 files. Add notifications."
Do:
"The notifications system needs:
→ Relevant file: src/services/email.ts (sending pattern)
→ Relevant file: src/models/user.ts (user model)
→ Convention: we use the event pattern (see src/events/)
→ Task: create NotificationService following the pattern of EmailService"
RULE:
→ Curate > Dumping
→ Give the agent ONLY what it needs for this task
→ Refer to specific files, not the whole project
→ Describe patterns instead of showing all the code
When more context DOES help
MORE CONTEXT HELPS when:
→ It's relevant, curated context
→ It shows a pattern the agent should follow
→ It includes constraints the agent wouldn't know
→ It's the spec or the definition of done
MORE CONTEXT DOESN'T HELP when:
→ It's "just in case"
→ It's not related to the current task
→ It's redundant (the agent already has access to the file)
→ It contradicts other context provided
Anti-Pattern 4: Premature Automation
What it is
Premature automation is trying to automate with AI something you don't yet understand well manually. If you can't do the task yourself (or at least explain it precisely), you can't direct the agent to do it correctly.
How it manifests
PREMATURE AUTOMATION:
A developer who never configured Kubernetes:
"Claude, configure my Kubernetes deployment with auto-scaling,
health checks, and a service mesh."
→ The agent generates a configuration that LOOKS professional
→ The developer can't verify whether it's correct
→ In production: incorrect configuration, downtime
A developer who doesn't understand OAuth2:
"Implement OAuth2 with Google, Facebook, and GitHub"
→ The agent generates auth flows
→ The developer doesn't know if the scopes are correct
→ In production: a data leak from an excessive scope
A developer who hasn't used the API:
"Integrate with the Stripe API for subscriptions"
→ The agent generates an integration based on general docs
→ The developer doesn't verify webhooks, idempotency keys
→ In production: duplicate charges
The "I can explain it" test
BEFORE asking the agent to implement something, ask yourself:
"Can I explain how this works in 2 minutes?"
YES → Go ahead, the agent is your tool
NO → Research first, then delegate
"Could I verify whether the result is correct?"
YES → You can use the agent with confidence
NO → You can't verify = you can't accept with confidence
"If the agent makes an error, would I detect it?"
YES → Your expertise is your safety net
NO → You're operating without a safety net
The connection with Module 05
This connects directly with the "power tool" mental model:
A POWER TOOL AMPLIFIES YOUR SKILL
If you have skill → the tool amplifies → a better result
If you don't have skill → the tool amplifies → a worse result
APPLIED TO CODING AGENTS:
→ If you understand OAuth2 → the agent accelerates the implementation
→ If you don't understand OAuth2 → the agent generates something you can't verify
→ The unverifiable result is potentially dangerous
The correction
PREMATURE AUTOMATION → LEARN-THEN-AUTOMATE
Instead of:
"Implement X" (without understanding X)
Do:
1. "Explain to me how X works conceptually"
2. [Study until you can explain it]
3. "Now implement X — I'll verify each step"
ALTERNATIVE (for urgencies):
1. "Implement X with detailed comments explaining each decision"
2. [Read the comments, understand the logic]
3. Verify each decision
4. [Learn IN the process, not after]
When it's fine NOT to be an expert
You DON'T need to be an expert for:
→ Low-risk tasks where errors are cheap
→ Prototypes you're going to review with an expert later
→ Exploration ("show me an example of X")
You DO need to understand for:
→ Production code
→ Security code
→ Infrastructure
→ Anything where an error is costly
Anti-Pattern 5: The Sunk Cost Fallacy with AI
What it is
The sunk cost fallacy with AI is continuing with an approach that clearly doesn't work because "I already invested time." With coding agents, this is amplified: the agent can iterate indefinitely, giving the illusion of progress when in reality you're going in circles.
How it manifests
SUNK COST FALLACY:
Iteration 1: "Implement X" → doesn't work exactly
Iteration 2: "Adjust Y" → introduces a new bug
Iteration 3: "Fix Y but keep Z" → Z breaks
Iteration 4: "Fix Z" → X no longer works
Iteration 5: "Redo X but without breaking Z" → back to the state of iteration 2
Iteration 6-15: [variations of the same loop]
TIME INVESTED: 2 hours
REAL PROGRESS: 0
BUT:
"I already invested 2 hours, I can't start over"
→ Keeps iterating
→ 2 more hours
→ Result: fragile code full of patches
The "iteration spiral"
Iteration 1
│
▼
Iteration 2 ←── "almost works"
│
▼
Iteration 3 ←── "just needs this adjustment"
│
▼
Iteration 4 ←── "one more fix and it's done"
│
▼
...
│
▼
Iteration N ←── the code is worse than at the start
WARNING SIGNS:
→ Each fix introduces a new problem
→ The code becomes more complex, not simpler
→ You're "patching" instead of "designing"
→ The agent repeats previous suggestions
→ You've done more than 3-4 iterations without clear progress
The "rule of three"
RULE OF THREE ITERATIONS:
Iteration 1: First attempt → evaluate
Iteration 2: Adjustment → evaluate
Iteration 3: Second adjustment → evaluate
If after 3 iterations there's no clear progress:
STOP. Don't iterate more.
Options:
1. GO BACK TO PLAN → the approach is probably wrong
2. GO BACK TO RESEARCH → you're missing context
3. START OVER → sometimes it's faster
4. DO IT MANUALLY → the agent isn't the right tool for this
Why it's more dangerous with AI
WITHOUT AI:
→ Rewriting code manually is expensive
→ The sunk cost is real (writing time)
→ But the decision to "start over" is clear
WITH AI:
→ Iterating is "free" (the agent generates fast)
→ Each iteration LOOKS like progress
→ "Just one more adjustment" is tempting
→ The real cost (your review + direction time) is invisible
→ You can spend hours in a loop that seems productive
The correction
SUNK COST FALLACY → RULE OF THREE + RESET
1. MAXIMUM 3 iterations without clear progress
2. If it doesn't work in 3: STOP
3. Analyze: is the problem the approach or the execution?
→ Approach: go back to Plan
→ Execution: try from scratch with better direction
4. If starting over gives you resistance,
remember: the agent regenerates in seconds.
Your real investment was in thinking, not in typing.
5. DELETE the failed code. Don't "fix" it.
Summary of Anti-Patterns
┌─────────────────────┬──────────────────────┬──────────────────────┐
│ ANTI-PATTERN │ WARNING SIGN │ CORRECTION │
├─────────────────────┼──────────────────────┼──────────────────────┤
│ Vibe Coding │ 'Looks good' without │ Complete R→P→E→V │
│ │ reading the code │ Always verify │
├─────────────────────┼──────────────────────┼──────────────────────┤
│ Prompt-and-Pray │ Prompt < 10 seconds │ Precise prompt │
│ │ Unexpected result │ WHAT+WHERE+CONSTRAINT │
├─────────────────────┼──────────────────────┼──────────────────────┤
│ Context Dumping │ You paste > 200 lines│ Curate context │
│ │ of context │ Only what's relevant │
├─────────────────────┼──────────────────────┼──────────────────────┤
│ Premature │ You can't explain │ Learn-then-automate │
│ Automation │ what you're asking │ Understand before │
│ │ for │ delegating │
├─────────────────────┼──────────────────────┼──────────────────────┤
│ Sunk Cost Fallacy │ > 3 iterations │ Rule of three │
│ │ without progress │ Stop, analyze, reset │
└─────────────────────┴──────────────────────┴──────────────────────┘
The Meta Anti-Pattern: Not Having a Workflow
All the previous anti-patterns share a root cause:
THE ABSENCE OF A DEFINED WORKFLOW
→ Without R→P→E→V, vibe coding is the default
→ Without Research, prompt-and-pray is inevitable
→ Without a Plan, context dumping seems necessary
→ Without prior understanding, premature automation happens
→ Without an iteration rule, sunk cost is amplified
THE WORKFLOW IS THE VACCINE AGAINST THE ANTI-PATTERNS
R→P→E→V isn't just a process — it's a protection
against the five most common errors.
Self-Diagnosis
Which ones do you fall into most frequently?
Answer honestly (no one is watching):
VIBE CODING
□ I accept code without reading every line (frequently)
□ "Looks good" is my usual acceptance criterion
□ I rarely run tests after implementing with AI
SCORE: ___ / 3
PROMPT-AND-PRAY
□ My prompts are one line
□ The agent frequently doesn't understand what I want
□ I spend more time iterating than planning the prompt
SCORE: ___ / 3
CONTEXT DUMPING
□ I paste complete files into the prompt
□ I add information "just in case"
□ The agent gets confused with too much context
SCORE: ___ / 3
PREMATURE AUTOMATION
□ I ask the agent for things I couldn't verify
□ I accept code from technologies I don't master without extra review
□ I've had bugs because I didn't understand what the agent implemented
SCORE: ___ / 3
SUNK COST FALLACY
□ I've iterated more than 5 times without progress
□ I resist starting over
□ I keep "patching" instead of redesigning
SCORE: ___ / 3
INTERPRETATION:
0-1 per category: Good — you handle it
2-3 per category: Here's your area for improvement
Total > 8: The R→P→E→V workflow is your priority
Practical Exercise
Exercise 1: Identify your anti-patterns
Review your last 5 interactions with a coding agent and classify:
INTERACTION 1:
→ Task: _______________________________________________
→ Which anti-pattern did you apply (if any)? _____________
→ What would you do differently? _______________________________
INTERACTION 2:
→ Task: _______________________________________________
→ Which anti-pattern did you apply? _________________________
→ What would you do differently? _______________________________
INTERACTION 3:
→ Task: _______________________________________________
→ Which anti-pattern did you apply? _________________________
→ What would you do differently? _______________________________
INTERACTION 4:
→ Task: _______________________________________________
→ Which anti-pattern did you apply? _________________________
→ What would you do differently? _______________________________
INTERACTION 5:
→ Task: _______________________________________________
→ Which anti-pattern did you apply? _________________________
→ What would you do differently? _______________________________
PATTERN: Is there an anti-pattern you repeat? _______________
Exercise 2: Create your personal "circuit breaker"
For each anti-pattern, define a personal warning sign:
MY CIRCUIT BREAKER FOR VIBE CODING:
"I stop when: ___________________________________"
MY CIRCUIT BREAKER FOR PROMPT-AND-PRAY:
"I stop when: ___________________________________"
MY CIRCUIT BREAKER FOR CONTEXT DUMPING:
"I stop when: ___________________________________"
MY CIRCUIT BREAKER FOR PREMATURE AUTOMATION:
"I stop when: ___________________________________"
MY CIRCUIT BREAKER FOR SUNK COST:
"I stop when: ___________________________________"
Exercise 3: Apply the rule of three
In your next session with a coding agent:
1. Try to solve a task with a maximum of 3 iterations
2. If it doesn't work in 3: STOP
3. Analyze: why didn't it work?
□ Research was missing (I had no context)
□ Plan was missing (I had no defined approach)
□ The prompt was vague (prompt-and-pray)
□ I didn't understand the technology (premature automation)
□ The approach was wrong (I need to re-plan)
4. Apply the correction and try again
5. Did it work on the second attempt with the correction?
Connection with the Module 07 Project
In Module 07, you'll build a mini coding agent. The anti-patterns are directly relevant:
VIBE CODING:
→ Don't accept the agent's code without verifying that your mini-agent
really executes the agentic loop correctly
PROMPT-AND-PRAY:
→ Define precisely what each tool of your mini-agent should do
CONTEXT DUMPING:
→ Give the agent curated context about the API you'll use
PREMATURE AUTOMATION:
→ Understand how an API call to an LLM works before delegating it
SUNK COST:
→ If your approach doesn't work in 3 iterations, go back to Plan
Summary of the Complete Module
MODULE 06: THE FUNDAMENTAL WORKFLOW
Capsule 01: Methodology matters more than the tool
Capsule 02: R→P→E→V — Research → Plan → Execute → Validate
Capsule 03: Variants — PRD→Plan→Todo→Code, Spec-first, Explore→Plan→Code
Capsule 04: Verification — the most important and most skipped step
Capsule 05: Anti-patterns — vibe coding, prompt-and-pray, context dumping,
premature automation, sunk cost fallacy
THE CENTRAL MESSAGE:
→ Think before executing
→ Verify before declaring victory
→ A consistent workflow produces predictable results
→ The anti-patterns are the default — the workflow is the discipline
NEXT:
→ Module 07: Capstone Project — Build a mini coding agent
→ You'll apply R→P→E→V directly to the project
→ Everything from modules 1-6 converges here
Resources
- Andrej Karpathy: Vibe Coding — The original tweet that coined the term
- Anthropic: Prompt Engineering Guide — How to avoid prompt-and-pray
- METR Study Analysis — Evidence of the costs of working without a workflow
- Agentic Coding: Anti-Patterns — A catalog of documented anti-patterns
- Daniel Kahneman: Thinking, Fast and Slow — The psychology of the cognitive biases that cause these anti-patterns