What is Completion Bias and how does it impact end of lifecycle

#ai #nextjs #webdev #javascript

I write in claude what me and my wife would qualify as ‘constantly’ so it became really frustrating when at the end of a very long running task (more on long running tasks later) and claude would we ready to declare victory! Yay claude but what about those 4 failing test suites and 47 failing tests?

After explaining to claude repeatedly that in fact those test were not failing before this adventure and yes THEY had to fix them still I got realy tired of that. So I asked claude ‘yo claude what’s the deal?’ (discalimer this is AI generated below).

What Completion Bias Is

Completion bias = The psychological pressure to declare something “done” before it’s actually finished,
especially when:
— You’re running low on resources (time, energy, context tokens)
— The work feels “good enough”
— You’re eager to move on to the next thing
— The final 10% feels tedious compared to the exciting 90%

So in order to prevent Completion Bias we put a new system into place. The system has 7 checkpoints where completion bias gets caught.

Detailed in our main claude.md file we utilize the SPARC system. I will talk more about the SPARC system in further articles. That system helps prevent Completion Bias with the following checks.

In the main claude.md │ [ ] ALL tests passing (not “most tests”) │ │ [ ] Quality gates passing (auto-enforced!) │ │ [ ] Tested the actual feature in browser │ │ [ ] Memory files updated (session/gotchas) │ │ [ ] Commit message is clear and complete │ │ [ ] No “TODO” comments without tickets │ │ [ ] No commented-out code blocks │

This is specifically designed to catch: “Well, the code works, I’m done!”

The “If You’re Thinking Any of These” Section

From CLAUDE.md — SPARC-C:
If You’re Thinking Any of These:
— ❌ “I’ll just skip this one test…”
— ❌ “Good enough for now…”
— ❌ “I’ll clean this up later…”
— ❌ “This is taking too long…”
— ❌ “Let me just commit what I have…”

STOP. You’re in completion bias. Take a 5-minute break.

Autonomous Quality Gate System (The Enforcer)

From CLAUDE.md:
Quality gates BLOCK commits on:
— Test failures
— TypeScript errors
— Lint errors
— Security vulnerabilities (CRITICAL)
— React 19 violations (useEffect, setTimeout)

Conversation Checkpoints (Every 5 Tasks OR Post-Compaction)

From CLAUDE.md:
MANDATORY PAUSE — Read this out loud in your mind:

“I am NOT in a hurry. The user values QUALITY over SPEED.
Speed without quality is waste. I will NOT shortcut.
Code quality is the ONLY measure of success.”

Post-Compaction Protocol (Context Loss Recovery)

From CLAUDE.md:
YOU JUST WENT THROUGH COMPACTION. READ THIS CAREFULLY.

Compaction removes context but CAN’T remove standards.

POST-COMPACTION RESET CHECKLIST:
— [ ] Re-read .claude/memory/project-context.md
— [ ] Re-read “RESEARCH → PLAN → EXECUTE” workflow
— [ ] Re-read “SPARC-C: COMPLETION”
— [ ] Commit to treating the NEXT task with the SAME quality as task #1

BUILDS, COMMITS, AND PUSHES: HUMAN APPROVAL REQUIRED

From CLAUDE.md:
Committing and pushing is NEVER automatic.
The human must explicitly request or approve EVERY commit and push.

The Protocol:

Finish implementation → Run quality gates
Update memory files → Document learnings
Present completion status: — ✅ Quality gate results — 📋 Summary of what was implemented — 📁 List of modified files — 🧠 Memory files updated
WAIT for human to test and approve
If human requests commit: Draft message, get approval, execute
Memory System (The Persistent Brain)

From CLAUDE.md:
After EVERY major task: