Using GPT as a Code Auditor (Not a Code Generator)
Source: Dev.to
Why “GPT code reviews” usually feel unsatisfying
You’ve probably done this:
“Here’s my code. Can you review it?”
The feedback is often reasonable:
- refactoring ideas
- edge cases
- style improvements
But one thing is missing: a decision.
Was the implementation acceptable — or not?
A minimal experiment
I built a deliberately small project to explore this.
- FastAPI
- JWT
- One endpoint
- Multi‑tenant data access
And I froze exactly one engineering decision:
tenant_id must come from the JWT payload — nowhere else.
No configuration flags. Either the code enforces this decision, or it fails.
Why this is an audit problem, not a design debate
When tenant_id can come from query params, headers, body, or JWT:
- cross‑tenant access becomes hard to conclusively rule out
- security relies on convention rather than enforcement
- reviews turn into discussions instead of judgments
Auditing means being able to say: given these frozen requirements, this implementation passes or fails.
Turning GPT into an auditor
GPT isn’t used here to be creative or clever. Its role is strictly constrained:
- Compare implementation against frozen requirements
- Identify violations or ambiguities
- Produce a reproducible verdict
- Explain why
Once the decision surface is frozen, GPT stops suggesting and starts judging.
What’s in the repository
The repository is intentionally minimal:
- frozen requirements (
requirements.md) - minimal implementation
- tests that demonstrate failure cases
- a structured audit trail
- a final verdict
This is not a framework or a tutorial.
Repository
You can find the full example here:
👉
If you read only one file, start with requirements.md.
Final thought
Most code‑review pain doesn’t come from bad code.
GPT becomes useful for auditing only after those decisions are made explicit.