How to Check Code Quality Without Drowning in Findings

Most teams already have a code quality check. Tests run. A linter comments. Someone approves the pull request. That stack was built for a human writing a few files. It does not hold when an agent can add a hundred lines that compile, pass the existing tests, and still leave residue behind.

Checking code quality is then a workflow problem, not a tool-shopping problem. You need facts that fail the same way every time, plus a place for judgment. The code quality tools guide covers which product does which job. This page is the sequence to run on a change.

1. Write the bar before you generate

A quality check has nothing to compare against if the change has no contract. Before the agent edits, name the behavior, the files it may touch, and the tests that would prove it. If that sentence is missing, review will argue about taste.

Keep the patch small enough that a reviewer can hold the contract in their head. Agents expand scope when the prompt is a vibe. A quality gate cannot recover intent the prompt never stated.

2. Run the mechanical checks first

Format, lint, types, and tests are the floor. They are not optional because the model sounded confident. If the project already has a toolchain, run it on the changed files before anyone reads the diff.

Then add the residue those tools ignore. Empty catches, as any, leftover TODOs, unused helpers, hallucinated imports, and oversized files often pass ESLint and the test suite. That is the gap a deterministic scanner is for.

On this stack that scanner is aislop:

npx aislop scan --changes

You get a 0–100 score and named findings. Same code in, same score out. Details are in the scoring docs.

3. Fail CI on facts, not on vibes

A code quality check that only runs on a laptop is a suggestion. Put the gate in CI so the merge is blocked when the score drops below the team's threshold, or when an error-severity diagnostic is present.

Roll the threshold in. Baseline the current score, fix or suppress the noisy rules, then raise ci.failBelow. Do not turn on a 90 gate against a 40 codebase and call the tool broken.

Keep probabilistic review advisory until you have evidence. A model that comments on every PR is not a quality check; it is another queue. The AI-written code review checklist is the human layer after the gate.

4. Spend people on what the scanner cannot see

After tests and the deterministic gate, the remaining diff should be smaller. That is where reviewers earn their time: does this match the product intent, does it fit the architecture, did the agent invent a dependency, did it weaken a test to stay green.

If the remaining diff is still huge, the quality check failed earlier. Shrink the prompt and the patch; do not ask a human to absorb a generated rewrite.

What a passing check actually means

A green pipeline means the change did not trip the rules you encoded. It does not mean the feature is right. Keep that distinction visible so the team does not treat a 90 score as an architecture review.

If you need a starting command: npx aislop scan. If you need the hosted gate on every PR, that is scanaislop. The check is the same engine either way.