Spec-as-What-Good-Looks-Like Verification
Check your definition of good into the repo so AI code review can automatically validate work against it.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 90%
When AI writes most of the code and many disciplines check in changes, human review becomes the bottleneck. Fiona Fung's approach: whenever you can articulate what good looks like, turn it into a spec, check it into the repo, keep it in sync with the code, and let Claude code review validate against it. Models are very good at validating against an explicit framework, so codifying standards automates the routine layer of review and reserves humans for areas needing deep subject-matter expertise.
Origin
Fiona Fung frames this as the evolution of test-driven development, where writing the test/spec first used to be a tax and is now automated by the model.
Core principles
- 01Claude is very good at validating against an explicit framework, so give it one
- 02A written statement of 'what good looks like' belongs in the repo, not in someone's head
- 03Specs must be kept up to date with the code frequently or they drift into noise
- 04Reserve scarce human review for the areas that need deep subject-matter expertise
How to run it
- 1
Articulate what good looks like
Write down the standard — a content-design scale, an architecture rule, an experience spec — in explicit, checkable terms.
- 2
Check the spec into the repo
Commit the spec alongside the code so it is versioned and available to automated review.
Pro tip Update the spec whenever the code it governs changes so the two stay aligned.
Watch out A stale spec silently stops catching regressions and erodes trust in the automated check.
- 3
Let AI review validate against it
Configure Claude code review to check every change against the committed framework, flagging where the code no longer matches the stated intent.
- 4
Route expertise-heavy areas to humans
For changes needing deep subject-matter expertise, keep a proper human reviewer in the loop rather than relying on the automated check alone.
In the wild
The team updated their content design to have an explicit scale, checked that spec into the repo, and had Claude code review make sure changes still matched what they set out to do.
→ Routine review is automated against a living standard, removing a major human-review bottleneck that did not even exist as a capability a year earlier.
Common mistakes
Keeping quality standards implicit
If 'good' lives only in reviewers' heads, AI cannot validate against it and human review stays the bottleneck as throughput scales.
Letting the spec drift from the code
An out-of-date spec no longer reflects reality, so automated checks pass bad code or flag good code and teams stop trusting the review.
Is it for you?
Best for
Teams with high AI-assisted commit volume across multiple disciplines who need to scale code review without proportional human reviewers
Not ideal for
Highly novel or research work where 'what good looks like' cannot yet be articulated as a checkable spec
From the transcript
“Claude is very good when you give it a framework to validate against those frameworks.”
“check those into the repo and then make sure the spec also keeps up to date with the code like frequently.”
“any time you have like a statement of what good looks like, get that into the repo and then Claude code review can make sure…”
From the episode
What happens after coding is solved?
Fiona Fung (Manager of the Claude Code and Cowork Teams)