Claude Code vs ChatGPT
The Loop — Plan, Implement, Self-audit, Ship
Now Claude Code is installed and talking to your code. Great. The next question is bigger and more important than it sounds: how do you work with it well? Most people pick it up like ChatGPT — type a request, hope for good code, paste it in, move on. That works for about a week, then things get weird.
What separates shipping-grade Claude Code use from demo-grade use isn't the AI underneath. It's the loop you run around it. That's this chapter.
You'll understand The Loop as the mental model that separates Claude Code from ChatGPT — and you'll know which of its four steps you personally skip most often. That self-diagnosis is what Chapters 3–9 are built around.
The secret isn't the AI, it's the Loop
is four steps: Plan → Implement → Self-audit → Ship. Every feature you build with Claude Code goes through all four. Skipping a step isn't a time-saver — it's where bugs and regressions come from.
Each step uses a different Claude Code — a building block of the system. You haven't met most of them yet. You will, one per chapter, starting next.
For now, the goal is to see the loop as a whole, recognise the failure mode behind each step, and be honest about which one you currently skip.
Click each quadrant below. The card expands and shows you three things: what the step actually produces, what most people do instead (the shortcut), and the specific cost of skipping it. The "what most people do" lines are the most useful — you'll almost certainly recognise yourself in at least two of them.
Each step of the Loop leans on one of five Claude Code primitives. You've seen one already — , the contract at the root of your repo. You haven't met the other four yet: , , , and .
Below is an interactive decision tree. Click each preset on the left to see which tool solves that need. Try at least three presets — the pattern you'll notice is that each tool has exactly one job. Chapters 3 through 7 cover them one at a time.
I want Claude to ___
CLAUDE.md
A markdown file at the repo root. Claude reads it before every session as the contract — rules, invariants, forbidden patterns.
Global rules enforced on every change: style tokens, banned imports, required helpers, architectural invariants.
Session-specific context or feature-only rules. Those belong in memory or a targeted skill.
## Hard rules - Never import from @legacy/* - Use cn() from @/lib/cn - Run /feature-check before every PR
Skills
Reusable packages with frontmatter (description, allowed-tools) and a markdown body. Auto-invoked when the description matches intent.
A task you repeat three or more times. Anything you want Claude to invoke automatically OR via /skill.
One-shot exploratory work. A plain prompt is fine for that.
--- description: audit the current branch for secrets, RLS holes, open CORS allowed-tools: Read, Grep, Bash --- # Security audit Scan the diff since main for…
Commands
Markdown files that become /command invocations. Each is a frozen workflow — the exact steps you want repeated.
Frameworks you enforce over and over: evaluation checklists, review templates, structured analyses.
Everything. If every interaction is a slash command, you lose flexibility. Reserve for the frameworks that matter.
# /ship <feature> 1. Run /feature-check <feature> 2. Run /theme-check diff 3. Run /security-audit 4. Summarise blockers and go/no-go.
Hooks
Shell commands wired to lifecycle events in settings.json. PreToolUse can BLOCK an action. PostToolUse can react (format, log, notify).
Enforcement, not requests. Block writes to migrations/. Auto-format after Edit. Refuse commits with secrets.
Anything that can be a skill. Hooks are hard walls — reserve them for rules Claude should not be able to talk its way around.
"PreToolUse": [{
"matcher": "Write",
"hooks": [{
"type": "command",
"command": "./scripts/secret-scan.sh"
}]
}]Memory
A MEMORY.md index plus project_<feature>.md files. Claude reads them to recover context without re-asking you on every new session.
Cross-session facts: architectural decisions, gotchas, roadmap, the WHY behind non-obvious code.
Anything already derivable from the code. Git log, grep, and the repo itself are the source of truth; memory is for what they can't tell you.
# project_billing.md ## Status: in progress (D3/5) ## Why: legal requires an audit trail ## Invariants: never delete, soft-close only ## Key files: src/billing/*.ts
The road ahead
You've now seen both the mental model (a four-step loop) and the toolkit (five primitives, one per job). Chapters 3–7 walk you through each tool with the same pattern: what it is, when to reach for it, a starter template you paste into your repo, a hands-on exercise to verify it worked.
Chapter 8 is the capstone — you build a real small app (a Notes web app with AI summarisation) using every primitive you learned. Chapter 9 is the ship-safely checklist. Chapter 10 is optional advanced material for later.
For now, check off the four exercises below as you work through them. Then hit → or the Next button to start Chapter 3 — where you write your first real configuration file for Claude Code.