Your coding agent passed every test. It may still have made the next change harder.
I kept seeing the same failure mode while using frontier coding agents heavily. Individual tasks succeeded. Tests passed. Each iteration looked reasonable. But after enough iterations, the codebase became progressively harder to work with.
The agents were strong at the task directly in front of them. What was missing was an independent structural feedback loop answering a different question before implementation: what complexity already surrounds this change, and what will this decision interact with?
Tests answer one question. There is a second one.
This is the sharpest way I can put it:
- Tests answer: did the change work?
- Something else has to ask: what complexity is this change interacting with?
A typical agent loop is task → inspect local context → implement → test → fix → ship → next task. Every step can succeed while the repository quietly accumulates coupling, branching, duplicated behavior, larger modules, and more transitive exposure. Each individual change looks reasonable. The accumulation is the problem.
To be clear: tests remain essential, and LLM review has its uses. But asking another model whether the first model added too much complexity is still model judgment. I wanted something outside the model — local, deterministic, read-only — that could inspect the repository before another change was made.
A concrete example: rounding was never just rounding
I built a synthetic demo repo (AcmeSaaS: auth, billing, notifications, API, workers — 83 files, Python + TypeScript) and ran exactly this workflow. The task: "change currency rounding." Sounds like a one-line edit.
cxcap audit . --intent "change currency rounding" returned 3 likely touchpoints and a reasoning surface of 15 files across 5 components. But the surprising file was core/money.py — a 42-line shared helper that is itself the repo's #2 hotspot.
cxcap audit . --focus core/money.py showed the payoff: that one file, holding 2.6% of repo complexity, is imported by 23 outside files and reaches 19 further files transitively — 42 files exposed, spanning auth, billing, notifications, API, and workers. Rounding is never just rounding when one helper formats every price, receipt, refund, and digest in the system.
All numbers above are verbatim output from real cxcap audit runs (v1.0.2). Nothing is estimated.
This matches what external evidence reports
GitClear reports, across a dataset of 623 million code changes over the AI-adoption period, increases including block duplication (+81%), within-commit copy/paste (+41%), and error-masking constructs (+47%), alongside refactoring line moves (−70%) and long-term legacy maintenance (−74%). (Their report, their numbers — correlation with AI adoption is theirs to interpret, not mine to overclaim.)
DORA's findings point the same direction from a different angle: AI amplifies underlying organizational capability, developers report productivity benefits, creation gets faster — and some of that saved creation time gets reallocated into auditing and verification, with delivery instability potentially rising alongside adoption. Faster generation increases the importance of feedback systems. That is the slot this tool tries to fill.
Why this also matters economically (carefully stated)
Here is the claim I will make, and the one I won't.
I won't claim any percentage savings on anyone's AI bill. That hasn't been proven.
What I will say is a mechanism, not a promise: a more complicated repository can require an agent to inspect more files, ingest more context, make more tool calls, reason across more relationships, and retry failed approaches. Agent platforms meter usage by tokens, model, context, and workload — so unnecessary structural complexity can become recurring AI-workload overhead, not just future developer time. Technical debt can now have a token bill.
The softer formulation I keep coming back to: the output of today's agent becomes the context of tomorrow's agent. Every unnecessary abstraction added today is something future agents may have to rediscover.
What I built: a pre-change complexity map
CXCAP (cargo install cxcap, open source, MIT) is a local, read-only CLI. No index, config file, daemon, model, or cloud account. Three commands cover the workflow:
# Where do complexity, hotspots, and cycles live?
cxcap audit .
# I know the task but not the files — where do I start?
cxcap audit . --intent "add session expiry"
# I know the target — who depends on it, how far can it reach?
cxcap audit . --focus src/auth
The verdict (LOW / MODERATE / HIGH / SEVERE) summarizes how strongly measured complexity should constrain the next change — it is explicitly not a quality grade. A mature, well-engineered system can legitimately be SEVERE. N/A means the repo is dominated by languages the tool doesn't score. Add --json and agents can consume the full report as structured evidence.
Honest limitations, stated up front: static analysis is incomplete by construction — runtime imports, reflection, registries, dependency injection, and plugin systems can be invisible (the tool flags [dynamic-lookup] uncertainty itself). --intent is discovery, not omniscience. It doesn't grade quality or predict effort.
One calibration point, quoted verbatim from the repo's README: historical --intent validation on 31 completed changes across 7 repositories scored Recall@10 0.70 and MRR 0.47 on that fixed benchmark. A starting point for trust, not a proof of generality.
The challenge
I don't want a positive review. Run it on the repository you've built most heavily with AI and give it your next real task:
cargo install cxcap
cxcap audit . --intent "<your next task>"
If it tells you nothing useful, tell me — that's the failure I want. If it finds something you hadn't considered, show me that too.
Top comments (0)