Originally published at chudi.dev
I shipped broken code three times in one week. The AI said "should work." I believed it.
That experience led me to build a complete system for AI-assisted development—one where evidence replaces confidence, context persists across sessions, and quality gates make cutting corners impossible.
This guide covers everything I've learned building with Claude Code.
What You'll Learn
This guide is organized into four core areas:
Part 1: Quality Control That Actually Works
The biggest mistake in AI-assisted development is accepting confidence as evidence.
When Claude says "should work," that's not verification—it's a guess. The two-gate system I built makes guessing impossible by blocking all implementation tools until quality checks pass.
For the complete breakdown of gates, phrase blocking, and the 4 pillars of quality, read: I Built a Quality Control System for AI Code Generation
The Core Principle
Gate 0: Meta-Orchestration
- Validates context budget (under 75%)
- Loads quality gates and phrase blocking
- Initializes the skill system
Gate 1: Auto-Skill Activation
- Analyzes your query intent
- Matches against 30+ defined skills
- Activates top 5 relevant skills
Only after both gates pass can you write code. Like buttoning a shirt from the first hole—skip it, and everything else is wrong.
Evidence Over Confidence
These phrases get blocked:
| Red Flag | Problem |
|---|---|
| "Should work" | No verification |
| "Probably fine" | Uncertainty masked as completion |
| "I'm confident" | Feeling, not fact |
| "Looks good" | Visual assessment, not testing |
Replace with evidence:
Build completed: exit code 0, 9.51s
Tests passing: 47/47
Bundle size: 287KB
For the complete verification system including the 84% compliance protocol, see the full quality control guide.
Part 2: Context Management
"We already discussed this."
I said it. Claude didn't remember. Thirty minutes of context—file locations, decisions, progress—gone after compaction.
The dev docs workflow solves this permanently.
For the complete dev docs workflow including automation hooks, read: How to Prevent Claude from Forgetting Your Task
The Three Dev Doc Files
Every non-trivial task gets a directory:
~/dev/active/[task-name]/
├── [task-name]-plan.md # Approved blueprint
├── [task-name]-context.md # Living state
└── [task-name]-tasks.md # Checklist
plan.md: The implementation plan, approved before coding. Doesn't change during work.
context.md: Current progress, key findings, blockers. Updated frequently.
tasks.md: Granular work items with status. Check items as you complete them.
The Magic Moment
[Context compacted]
You: "continue"
Claude: [Reads dev docs automatically, knows exactly where you are]
No re-explaining. No lost progress. Just continuation.
When to use dev docs:
- Any task taking more than 30 minutes
- Multi-session work
- Complex features with multiple files
- Anything you'd hate to re-explain
For the complete workflow including 16 automation hooks, see the context management guide.
Part 3: Token Optimization
Most Claude configurations load everything upfront. Every skill, every rule, every example—thousands of tokens consumed before you've asked a question.
Progressive disclosure flips this.
For the complete progressive disclosure implementation, read: How to Reduce AI Token Usage by 60%
The 3-Tier System
| Tier | Content | Tokens | When Loaded |
|---|---|---|---|
| 1 | Metadata | ~200 | Immediately |
| 2 | Schema | ~400 | First tool use |
| 3 | Full | ~1200 | On demand |
Tier 1: Skill name, triggers, dependencies. Just enough to route the query.
Tier 2: Input/output types, constraints, tools available.
Tier 3: Complete handler logic, examples, edge cases.
The meta-orchestration skill alone: 278 lines at Tier 1, 816 with one reference, 3,302 fully loaded. That's 60% savings on every session that doesn't need the full content.
For implementation details and your own skill definitions, see the token optimization guide.
Part 4: Foundational Concepts
Before building complex AI workflows, you need to understand the underlying patterns.
RAG: Retrieval-Augmented Generation
RAG gives LLMs access to external knowledge at inference time. Instead of relying on training data (which could be outdated), RAG pulls in relevant documents before generating.
For the complete RAG explanation with code examples, read: What is RAG? Retrieval-Augmented Generation Explained
The pattern:
- Query Processing → 2. Retrieval → 3. Augmentation → 4. Generation
Every time you feed context to Claude before asking questions, you're using RAG. The dev docs workflow is essentially manual RAG—retrieving your context files before generation.
Evidence-Based Verification
"Should work" is the most dangerous phrase in AI development. It indicates confidence without evidence.
For the psychology of verification and the 84% compliance protocol, read: Why 'Should Work' Is the Most Dangerous Phrase
The forced evaluation protocol:
- EVALUATE: Score each skill YES/NO with reasoning
- ACTIVATE: Invoke every YES skill
- IMPLEMENT: Only then proceed
Research shows 84% compliance with forced evaluation vs 20% with passive suggestions. The commitment mechanism creates follow-through.
Getting Started
Minimum Viable Setup
- Create a CLAUDE.md in your project root with basic gate enforcement
- Set up a dev/ directory for task documentation
- Add "continue" handling to resume after compaction
Full Setup
- Install the dev docs commands (slash commands or aliases)
- Configure hooks for automatic skill activation
- Set up build checking on Stop events
- Create workspace structure for multi-repo projects
The full system takes a few hours to configure. But it saves that time on every long task thereafter.
Related Guides
Claude Code Fundamentals
- Quality Control System - Two-gate enforcement, phrase blocking
- Context Management - Dev docs, automation hooks
- Token Optimization - Progressive disclosure, 60% savings
Foundational Concepts
- What is RAG? - Retrieval-augmented generation explained
- Evidence-Based Verification - Why "should work" fails
The Bottom Line
Claude Code isn't just a code generator. With the right systems, it becomes a quality-controlled collaborator.
The goal isn't trusting AI less. It's trusting evidence more—and building systems that make "should work" impossible to accept.
Start with dev docs. Add the gate system. Implement progressive disclosure. Each piece builds on the last.
The AI was always capable. We just needed guardrails that made evidence the only path forward.
Top comments (2)
I get 404 on all links.
Update: All the links should be working now! I appreciate the feedback.