In this article
Last updated September 18, 2026
4 min read
Most code review examines one change.
Architecture emerges across many changes.
This gap matters when agents work for longer periods or complete a sequence of repository tasks. Each change can be
locally reasonable, tested, and documented. The combined effect can still weaken the system.
That is structural erosion.
How erosion becomes normal
A feature needs data owned by another module.
The quickest path is a direct import. The change passes.
The next feature finds the new dependency and uses it as precedent. A helper appears to manage the shared behaviour.
Tests protect the helper. Documentation describes the pattern.
No single step looks reckless. The boundary has still moved.
Future agents now see accepted code, tests, and documentation pointing in the same direction. The exception becomes
the repository’s strongest signal.
What long-horizon benchmarks suggest
SlopCodeBench studies iterative repository extension and reports structural erosion in 77% of its runs, growing
verbosity, and no model solving an entire problem end-to-end.
It is a preprint and an artificial benchmark. Its reported rates are not production incident rates.
The benchmark helps isolate a real systems question: can a model keep a repository coherent across a long sequence of
locally evaluated changes?
Teams should not assume a green local evaluator answers that question.
Enforce boundaries mechanically
Write architecture rules in a form tooling can check:
- allowed dependency directions;
- module ownership;
- public interfaces;
- prohibited imports;
- data access boundaries;
- file and layer placement;
- naming or schema rules where they carry meaning.
OpenAI’s harness-engineering account describes custom linters and structural tests used to enforce dependency direction
and other invariants in an agent-first repository. It is a first-party internal account, not proof that every
organisation should copy the same architecture.
The general principle is sound: agents move faster when the repository makes acceptable boundaries explicit and
machine-checkable.
Use a quality ratchet
Measure the current structure and prevent quiet decline.
A quality ratchet can cover:
- dependency tangle;
- dead code;
- risky patterns;
- type strictness;
- complexity;
- test quality;
- documentation drift.
The measure can improve or hold. A decline requires an explicit exception and owner.
This lets teams adopt agents in imperfect systems without making “legacy” a permanent excuse for new erosion.
Review across changes
Diff review asks whether one change is acceptable.
Periodic system review asks:
- Which boundaries are changing most often?
- Which exceptions became repeated patterns?
- Which modules attract duplicate concepts?
- Which quality measures are at the floor?
- Which documentation changed to describe drift instead of challenge it?
- Which agent-generated areas have weak human comprehension?
The answers should update rules, plans, architecture documents, tests, and context packages.
Scope each run
Long-running does not need to mean unbounded.
Set limits:
- maximum changed surface before re-planning;
- modules allowed in the run;
- retry and time budgets;
- conditions that trigger architecture review;
- a stop on new sensitive boundaries;
- required checkpoints and evidence receipts.
The loop can persist while each change remains reviewable.
Preserve exceptions as exceptions
When a boundary must be crossed, record:
- the reason;
- alternatives considered;
- affected modules;
- owner;
- expiry or review trigger;
- cleanup or migration path.
Do not let the exception appear as an unexplained normal pattern to the next agent.
Where paqad-ai fits
paqad-ai is designed to combine module attribution, rule checks, scoped development, specialist review, quality
measures, documentation sync, decisions, and durable evidence.
These controls do not guarantee architectural quality.
They give the workflow ways to detect when local success is pushing the wider system in the wrong direction.
Long-running agents need more than persistence.
They need a repository that can say no across time.
Install paqad-ai: https://github.com/Eliyce/paqad-ai/
Source notes
- SlopCodeBench, preprint.
- OpenAI, Harness engineering, first-party internal account.
- Product mechanism: first-party details from the current Eliyce/paqad-ai repository.