AI Generated Code Quality: What to Check Before Merge
Green tests are not a code quality review. AI generated code needs a bar you can fail the same way every time.
AI generated code quality is not a style score. It is whether the change does the job, fails loudly, fits the repo, and can be owned after merge. Agents write faster than reviewers read. The check has to get cheaper, not longer.
Four checks
- Behavior. Tests that fail when the feature is broken, not tests that assert the mock.
- Residue. Named AI slop: swallowed exceptions, leftover comments, dead code, unsafe casts. Automate this.
- Dependencies and secrets. Verify every new package. Do not merge placeholders.
- Intent. A person confirms the patch matches the request and the architecture.
What to automate
Format, lint, types, tests, and a deterministic AI slop scan belong in CI. aislop is one such scan: npx aislop scan then aislop ci with a threshold. See how to check code quality for the sequence.
What not to automate as a blocker
Open-ended LLM review can suggest logic issues. It is not a stable merge rule. Use it as a second reader, not as the only code quality gate. Comparison: deterministic AI code review.
Frequently asked questions
How do I check AI generated code quality?
Prove the requested behavior with tests, run a deterministic scan for repeatable residue, then review intent and architecture. Do not start by reading the entire generated diff.
What hurts AI generated code quality most?
Silent error handling, unsafe type escapes, abandoned helpers, weak tests, and diffs too large to verify. Those pass a formatter and still degrade the repo.
Can a linter measure AI generated code quality?
Only the subset it already knows. Linters were built for human edits. They miss many AI slop shapes unless you add a focused gate.