Quality, Governance, and Anti-Patterns

Technical patterns make individuals fast. Governance makes an organization safe while it gets fast. Teams that only invest in the first ship bugs at a scale they have never seen before.

The verification stack

Think of quality controls as layers, each catching what the previous one missed.

Layer	Mechanism	Catches
1. Instructions	CLAUDE.md rules, skills	Most violations, before they are written
2. Per-edit hooks	Format, lint, typecheck	Syntax, style, type errors
3. Per-turn hooks	Tests on Stop	Behavioral regressions
4. Agent review	Reviewer and security subagents, /security-review	Logic, design, and security flaws
5. Pre-commit	Secret scanning, policy checks	Leaked credentials, policy violations
6. CI	Full tests, SCA, AI PR review, IaC scanning	Integration issues, dependency risk
7. Human review	CODEOWNERS, branch protection	Judgment calls, high-risk paths

Layers 1 through 4 run inside the developer loop and make the agent correct itself. Layers 5 through 7 are gates that apply to everyone, regardless of who wrote the code.

Policy as configuration

Where possible, turn policy into files rather than documents nobody reads.

• Managed settings let an organization enforce permissions, deny rules, and approved MCP servers centrally. Individual developers cannot override them.
• Committed project settings define the team's allowlist, hooks, and shared MCP servers.
• CODEOWNERS routes high-risk paths to qualified reviewers.
• Branch protection requires passing checks and approvals before merge.

A written policy that says "engineers must run security review" is a hope. A required CI check is a control.

Code ownership is unchanged

The engineer who opens a pull request owns that code, whoever typed it. This principle prevents a dangerous drift where reviewers assume "the AI checked it" and authors assume "the reviewer will catch it." State it explicitly in your engineering handbook.

Auditability

For regulated environments, you need to answer who changed what, when, and with which tools.

• Git history already records authorship and review. Keep it clean with small commits.
• Use consistent commit trailers or PR labels to mark AI-assisted changes if your auditors want that signal.
• Enterprise plans provide usage analytics and administrative controls. Route Claude Code through your organization's account rather than personal subscriptions.
• Keep MCP server and plugin inventories with owners, the same as any third-party software.

Compliance and data handling

Before rollout, answer with your security and legal teams:

• Which data classifications may appear in a session? Production PII usually should not.
• Which repositories are in scope? Some regulated codebases may need separate controls.
• What retention and training terms apply under your commercial agreement? Commercial plans have different data terms from consumer plans; confirm them in writing.
• Do you need zero data retention or a specific cloud region? Claude is available through major cloud providers for organizations with residency requirements.

For SOC 2 and ISO 27001, AI coding tools are typically treated like other third-party development tools: vendor assessment, access control, change management through existing review gates, and documented policy.

The anti-patterns

These are the failures I see most often, with the fix for each.

1. Vibe-coding production. Accepting code without reading it. Fine for a throwaway prototype, unacceptable for anything that handles real users or data. Fix: the five-step loop from Chapter 8.
2. No plan on non-trivial work. Fix: plan mode for anything over an hour.
3. Trusting confident output. Fix: require evidence, meaning a test, a command output, or a reproduction.
4. Correcting in place. Repeated corrections poison context. Fix: rewind.
5. Context bloat. One session all day across unrelated tasks. Fix: /clear between tasks and plan files across days.
6. Mega-skills. One skill doing five jobs. Fix: split by job.
7. Raw CLI on sensitive systems. Fix: scoped MCP servers and read-only roles.
8. Empty or stale CLAUDE.md. Fix: the lesson-learned loop from Chapter 4.
9. Installing unread plugins and skills. Fix: review like any dependency, pin versions.
10. Skipping permissions on a real machine. Fix: allowlists, and containers for autonomous runs.
11. Weak tests as the target. Agents optimize for whatever check you give them. Fix: review tests before implementation and verify they can fail.
12. Counting output instead of outcomes. Lines of code and test counts are not quality. Fix: measure escaped defects, cycle time, and review findings.

Measuring whether it works

Track a few metrics before and after adoption:

• Lead time from first commit to production
• Change failure rate and escaped defects
• Security findings per release, by severity
• Review time per pull request
• Developer-reported time on toil

If lead time drops while change failure rate rises, the verification stack is too thin. If both improve, you are doing it right.

Key takeaways

• Layer controls from instructions and hooks through CI and human review.
• Turn policy into managed settings, committed config, CODEOWNERS, and branch protection.
• The engineer who opens the pull request owns the code, whoever typed it.
• Record a baseline first, then watch lead time and change failure rate together.