AI Slop Is a Systems Failure: Measure the Review Debt

A purple pile of review debt presses against a clean delivery channel.
In this article
  1. Slop is not a style problem
  2. Long-horizon research makes the mechanism visible
  3. Measure review debt
  4. Install a quality floor
  5. Reduce output before adding review
  6. Keep comprehension in the system
  7. paqad-ai’s role
  8. Source notes

Last updated September 18, 2026

4 min read

“Slop” became Merriam-Webster’s 2025 Word of the Year with a new meaning: low-quality AI content produced in quantity.

Applied to software, the useful target is the output condition, not the person who used the tool.

AI slop is code, tests, documentation, and activity produced faster than the team can connect them to intent, evidence,
structure, and ownership.

The code can look professional.

Slop is not a style problem

A team can remove verbose comments and improve naming while the real failure remains.

Software slop appears when:

  • the product goal is undecided;
  • a new component duplicates an existing responsibility;
  • tests repeat the implementation’s assumption;
  • several locally green changes erode architecture;
  • package recommendations lack provenance;
  • documentation describes old behaviour;
  • model judgement is reported as proof;
  • reviewers receive volume without a decision map;
  • nobody can explain why the change is safe.

Better prose does not fix these conditions.

Long-horizon research makes the mechanism visible

SlopCodeBench evaluates iterative repository extension across long horizons. The authors report that no model solved a
full problem end-to-end in their benchmark, structural erosion rose in 77% of runs, and outputs became more
verbose.

It is a preprint using artificial tasks. Its percentages should not be written as a prediction for production
repositories.

The mechanism is still valuable: local success can accumulate into system decline.

One shortcut becomes context. The next agent reuses it. Tests and documentation stabilise the new shape. The repository
teaches future runs that the exception is normal.

Measure review debt

Review debt is the verification, correction, and understanding work created faster than the team can close it.

Track:

  • pull requests waiting for qualified review;
  • average reviewer time per accepted change;
  • requirements without evidence;
  • unrequested changed behaviour;
  • repeated correction turns;
  • findings deferred without an owner;
  • stale documents after code changes;
  • structural measures below the current floor;
  • areas with unclear human ownership;
  • changes the team cannot explain confidently.

These measures are more informative than generated lines or agent count.

Install a quality floor

The team does not need to make a legacy repository perfect before using agents.

It does need a floor that cannot quietly fall.

Choose project-relevant measures:

  • dependency direction;
  • risky patterns;
  • dead code;
  • type strictness;
  • complexity;
  • coverage;
  • mutation detection;
  • documentation freshness.

Allow improvement or stability. Require an explicit exception, reason, owner, and review trigger for decline.

Reduce output before adding review

When review debt grows, adding more reviewing agents can create more reports and the same human queue.

Reduce unnecessary output:

  • route small work to small workflows;
  • prevent out-of-scope refactors;
  • search for reuse before creation;
  • stop on uncertainty instead of patching;
  • keep context task-specific;
  • require a product promise for changed behaviour;
  • cap retries, diff size, and review volume.

The cleanest review finding is the change the system did not create.

Keep comprehension in the system

Anthropic’s narrow study of 52 mostly junior developers found lower later mastery in the AI-assisted group, with the
largest gap in debugging. The study is preliminary and should not be generalised to every team.

It supports a practical control: review for understanding as well as correctness.

Ask the owner to explain boundaries, failure modes, and the reason for the design. Rotate ownership of agent-generated
areas. Treat unexplained code as a risk signal.

paqad-ai’s role

paqad-ai is designed to constrain the whole delivery path: intent, planning, specification, scope, independent review,
checks, documentation, decisions, and evidence.

No workflow can guarantee the absence of slop.

It can stop the team from treating output volume as quality and give reviewers a structured way to find debt before it
compounds.

AI slop is not solved by asking the model to “be more careful.”

It is solved by engineering the system around generation.

Install paqad-ai: https://github.com/Eliyce/paqad-ai/

Source notes

Recognise this in your own team?

See how a change travels from request to live in one enforced process, then tell us about your team.