The worst bugs aren’t the ones that break. They’re the ones that work.
A page that “works” but is built wrong becomes the template for the next page. Copy-paste. Now two pages are wrong. Then four. Then you’re rewriting the app. This is exactly how structural patterns survive code review: no single file looks wrong, but the duplication is everywhere.
I’ve seen this pattern destroy projects:
I found exactly this on my own site. My CLAUDE.md had a rule: “Use gap-* for spacing in flex/grid, never space-y-* or space-x-*.” Clear, documented, reviewed. I ran a policy scanner against the codebase and found 70 violations of that single rule across 85 files. The wrong pattern had been copied from template to template for weeks. Nobody caught it because each page looked fine in isolation.
The fix wasn’t a find-and-replace either. space-y-* works on any block parent, but gap-* only works on flex/grid parents. Blind substitution would have broken layouts. Every fix required checking the parent element first. That’s 70 violations across 18 files of context-dependent remediation, all because the wrong pattern spread before anyone audited for it.
The fix isn’t better code review. It’s auditing structure before it spreads.
What “working but wrong” looks like
- Page uses raw SQL when a service method exists
- Page calculates metrics on-the-fly when rollup tables exist
- Page inlines styles that should be components
- Page implements logic that’s duplicated in three other places
- Page bypasses the approved data path because it was faster
None of these break the page. All of them break the codebase over time.
The audit mindset
Before asking “does it work?”, ask:
- Should this become the standard? If someone copies this page as a template, is that good?
- Is this how we do things now? Or is this how we used to do things?
- Would I approve this in a PR? Not “does it function” but “is this the right approach”
The decision matrix
After auditing, each page gets one verdict:
| Verdict | Meaning |
|---|---|
| Keep | It’s solid. No action needed. |
| Cleanup | Minor issues. Less than 30 minutes. |
| Refactor | Extract components or patterns. 1-4 hours. |
| Rebuild | Structurally wrong. Replace, don’t patch. |
Be blunt. If the structure is wrong, say “rebuild.” Don’t soften it to “refactor” because rebuilding sounds scary.
Pattern issues beat page issues
If you find the same problem on three pages, you don’t have three page problems. You have one pattern problem.
Fix the pattern. Extract the primitive. Then update all consumers.
Never fix the same thing three times in three different ways.
Where the verdicts go matters as much as the verdicts. A pattern problem written into a planning document is a pattern problem you will rediscover, which is why I now file findings as issue trees instead of specs.
The rule
If you wouldn’t approve it in a PR, don’t let it stay in production.
Working code that’s built wrong is technical debt with interest. Audit it before you spread it.
Related:
- From 733 False Positives to 9 Safe Deletes: the cleanup loop for what the audit finds
- Don’t Assume AI Fixes Things Properly: why verification matters
- You Are Invisible to Machines: the same principle applied to identity — structural problems you can’t see until you audit
- AI Change Control: The Pre-Commit Hook Framework: The machine enforcement that catches drift before it spreads