Make the standard explicit, for humans and agents
A team can't review against a standard it never wrote down. Before you tune any tool, agree on what good looks like: naming conventions, where logic lives, how comments earn their place, what idiomatic means in your stack. Put it where your agents can see it (a conventions doc, a project rules file) and where your reviewers can point to it. Half of AI slop is the agent guessing at a convention because nobody told it one — make the convention legible and a lot of the slop never gets generated.
The other half is the agent taking the most direct path regardless of convention, and that's the half you catch in review. The standard doesn't need to be exhaustive; it needs to name the things your team actually argues about, so that when a flag appears on a diff there's a shared answer to "is this wrong, or just different from how I'd do it?"
Keep PRs small enough that review still works
AI tools make it trivial to produce a 60-file PR, and a 60-file PR is functionally unreviewable — the reviewer skims, trusts, and approves, which means no review happened at all. The discipline that protects quality is the same one that always protected it: small, focused changes. Ask the agent for one concern per branch, and split when it sprawls. Smaller diffs mean a human can actually hold the change in their head, and an automated slop check can flag issues against a surface small enough to act on.
This is also where the slop score earns its keep: a small PR with a clean score is safe to move quickly; a small PR with a poor score is a quick fix; a giant PR is a process problem to solve before quality is even on the table. Scoping is upstream of everything else in this list.
Automate the slop layer, protect the judgment layer
The patterns AI tools produce are mechanical and repetitive, which makes them ideal for automated detection — and a poor use of senior-engineer time. This is the step quality·vibes automates: connect the GitHub repo, and every PR's diff gets read for the slop patterns (verbose comments, duplicated blocks, non-idiomatic usage, inconsistent naming, structural deviations), each flagged in place with an accept/dismiss suggestion. The reviewer triages those in a fast pass and spends the rest of their attention on the questions a tool can't answer: is this correct, is this the right approach, does it fit the system?
The boundary is the important part. quality·vibes suggests; it does not auto-apply fixes or auto-merge, so a human accepts every change and nothing rewrites a branch behind the author's back. And it deliberately stays out of business-logic and design judgment — that's not a limitation to apologize for, it's the division of labor that makes the workflow trustworthy. The tool owns the patterns; the team owns the decisions.
Track the trend, don't police every line
Quality management at the line level is exhausting and doesn't scale; quality management at the trend level does. The quality-trends dashboard turns per-PR slop scores into a direction: is the codebase getting cleaner or noisier as the team leans harder on AI tools? A rising slop trend is a signal to revisit the standard or the prompts; a falling one tells you the workflow is holding. You're managing a system, not refereeing individual diffs.
Pair this with repo monitoring so the check runs continuously rather than only when someone remembers to look. The goal is for quality to be a property of the pipeline — automatic, consistent, visible — instead of a heroic effort by whoever happens to be reviewing today.
how it works
- 01
Write down the standard
Agree on naming, structure, idiom, and comment conventions, and put them where both your agents (rules/conventions file) and your reviewers can reference them. Most slop is an agent guessing a convention nobody stated.
- 02
Scope PRs small
One concern per branch. A 60-file AI-generated PR is unreviewable; a focused diff is something a human can actually hold in their head and a tool can flag against.
- 03
Connect the repo to a slop check
Point quality·vibes at your GitHub repo so every PR's diff is read for AI-slop patterns — verbose comments, duplication, non-idiomatic usage, naming drift, structural deviations — flagged inline with accept/dismiss suggestions.
- 04
Triage the flags fast
Run the slop pass first: accept the obvious cleanups in a click, dismiss the false positives. This clears the mechanical layer before a human spends attention on anything.
- 05
Reserve humans for judgment
Spend the freed-up review time on correctness, edge cases, and design fit — the things no tool decides for you. quality·vibes never auto-merges, so a human stays on every accept.
- 06
Read the slop score per PR
Use the 0–100 score to triage at the queue level: clean scores move fast, poor scores go back to the author, giant PRs get split before review even starts.
- 07
Watch the trend, not the lines
Use the quality-trends dashboard and repo monitoring to see whether slop is rising or falling over time, and adjust the standard or the prompts rather than policing every diff by hand.
frequently asked
Can I just tell my AI tool to write clean code and skip the review step?
You should ask for it — a clear conventions file genuinely reduces slop at generation time. But "write clean code" is weakly constrained: the agent still takes the most direct path, mirrors whatever example is nearest, and drifts between sessions. A review-time check catches what the prompt didn't, consistently, which is why the two work best together rather than as substitutes.
How is this different from running clean·vibes on the repo?
clean·vibes scores a whole repository's cleanliness in one pass — great for an audit or a tidy-up session on an existing codebase. quality·vibes works at the pull-request level: it reads each diff as it comes in and flags slop on the changed lines, so quality is checked continuously as the team ships rather than periodically. They're complementary — repo-level audit vs. per-PR gate.
Won't an automated check just create noise reviewers ignore?
It can, if every flag is mandatory. quality·vibes is built around accept/dismiss precisely so the reviewer stays in control: dismiss the false positives, accept the real ones, and the slop score reflects what's left. The aim is a fast triage pass, not a wall of warnings — and the trend dashboard lets you manage at the level of direction rather than individual flags.
Does it work for any language?
It reads diffs and flags the language-agnostic slop patterns (verbose comments, duplication, naming drift, structural deviation) broadly, with idiomatic-usage checks tuned to common stacks. It's GitHub-only for the MVP. As always, it suggests rather than auto-applies, and it doesn't pass judgment on whether your business logic is correct — that stays with your reviewers.
Last updated June 19, 2026