Your code, tests and documentation may no longer agree.
The agents writing your code can’t tell which one to trust.
When a document contradicts the code, an agent believes the document. An out-of-date one is worse than no document at all. We find those contradictions, tie each to the evidence behind it, and rank what to fix first.
- Read-only access
- Your code is never retained
- Privacy-first
Three departments. Three sets of books.
Accounting, the warehouse and sales each keep records that are neat, internally consistent and confidently maintained — and have quietly stopped agreeing with one another. Nobody lied. And yet no decision can be made on any of it, because nobody knows which version is true.
This is what has happened inside a great deal of software over the past two years.
What the code actually does today, read module by module.
What the suite still asserts — and what it quietly stopped covering.
What the specs promise your team, your client and your agents.
A developer treats the documentation as a hint and the code as the truth. An agent treats the documentation as the truth. When a developer gets it wrong, someone catches it in review - when an agent gets it wrong, the mistake is already in the codebase.
The repository carries a reviewed specification saying a refused charge returns one of three outcomes. A fourth was added in code eight months ago, and the specification was never updated. The agent builds the retry logic from the specification — the fourth outcome falls through every branch it wrote, and the tests it wrote from the same specification pass.
It rarely arrives described as a technical problem.
It usually arrives described as a people problem, or a planning problem.
Output is up, but delivery is no more predictable than before. Estimates miss more often, not less.
Small, routine changes cause surprising breakage somewhere unrelated.
New developers take longer to become productive than two years ago — despite there being more documentation than ever.
Two or three senior people are the only ones who really know how things work, and the queue behind them keeps growing.
Those seniors spend most of the week checking other people’s work, while a growing share of changes ships unread.
If a client, a regulator or a buyer asked “what condition is this system in?”, producing an honest answer would take weeks.
None of these is a measurement. They are the shapes this usually arrives in — if several are familiar, there is something to go and look at.
An out-of-date document is worse than no document at all.
Not our opinion. Measured across models, harnesses and real pull requests.
How often an agent reached the best available answer, by the instruction it was given:
- Instruction matches the code
- 100%
- No instruction at all
- 33%
- Instruction is out of date
- 0%
A stale document did not merely fail to help. It performed worse than handing the agent nothing.
Coherence debt in repository-scale tasks, 2026 — 3,385 decisions, 7 models, 5 harnesses. Preprint.
Of every mismatch found in agent-written pull requests, the most common single kind:
The pull request description claims a change that the diff does not actually contain.
Message-code inconsistency in agent-authored PRs, 2026 — 23,247 pull requests, 5 agents.
How often a coding agent notices a broken test — a test that still passes but no longer checks anything, against one that plainly fails:
The silent one is caught barely half as often. It is also the one no build failure will ever point at.
TEBench, 2026 — 314 project-level tasks.
We check whether your repository still agrees with itself.
We assess the supplied repository and the engineering evidence around it — the product, the checks that are supposed to prove it works, and the documentation that describes it — comparing each against the others.
We only read what is in the repository. Where a finding depends on something we cannot see there — a service it calls, a library it relies on — the report says so and asks you to confirm it, rather than stating it as fact. Specifications committed to the repository are assessed like any other documentation.
How a finding is made.
The same pipeline runs on every repository, and the report shows its working at each step.
- Repository scan
- Per-question evidence
- Dimension score (0–1)
- Weighted category average
- Overall grade
A signal is something we noticed; a fact is something we checked and can point at. Only facts reach your report.
Every finding specifies which check produced it, which files were read, and any paths that could not be reached.
A check that could not run says so on the page, rather than passing quietly and inflating the score.
A decision-grade report, not a list of findings.
Everything below is the paid assessment.
The condition of the system in plain language, readable by someone who does not write code.
Ranked by severity, each tied to the check that produced it, the scope it read, and how much of that evidence a tool measured rather than a model read.
This run’s findings and scores, kept as a fixed point, so a later assessment has something to compare against.
This isn't a pitch. It's a preview of what you'll actually get.
Findings from a sample report, as the report writes them.
Security
No hardcoded secrets or credentials in source; Azure AD config uses public client IDs only
- Medium severity
No automated security scanning tools (Dependabot, Snyk, Renovate, Trivy, Grype) are configured in the project
Unpatched dependencies are the leading cause of production breaches. Without automated scanning, critical CVEs can sit in your dependency tree for months before anyone notices.
- Medium severity
Security headers (X-Frame-Options, Content-Security-Policy, HSTS, X-Content-Type-Options) are not configured in Nginx
Browsers rely on these headers to enforce same-origin policies, block clickjacking, and prevent MIME-type sniffing. Without them, even well-written app code is exposed to a class of attacks that cost nothing to execute.
Maintainability
TypeScript strict mode enabled, eliminating implicit any and null-safety gaps
- Critical severity
No semantic version tags present in git repository; package.json defines version 1.3.0 but no corresponding git tags exist.
Without version tags there is no reliable way to roll back to a known-good state, generate changelogs automatically, or tell consumers exactly what changed between releases. Hotfixes become guesswork.
The bill for the productivity gain arrives later.
The gain from AI coding tools was immediate and visible. The cost is slower, quieter, and arrives later — and for many teams it is arriving right about now.
The best time to check your system's condition is before someone else has to ask.
What people ask before they say yes.
Both look at one change at a time. A change can be individually correct and still push the system further out of alignment — that is exactly how this problem accumulates. Nobody is currently looking at whether the whole thing still hangs together, because it is not any one person’s job.
That is worth checking rather than assuming. One of the most common findings is a test suite that is green because it is testing a copy of the same mistaken assumption the product contains. Passing tests prove consistency. They do not prove correctness.
For one class of defect, no — and it is the class that matters most here. Coding agents work by running the suite and fixing what fails, so a test that passes while no longer checking anything never enters their loop. Measured on 314 project-level tasks, agents caught stale-but-passing tests barely half as often as tests that plainly fail (TEBench, 2026 — the numbers are in section 02). You also get the prioritisation, and the fact that it comes from outside the team that built the system.
Every finding names the check that produced it and what that check actually read — which files, how many lines, and what it could not reach. Facts, signals, and assumptions are separated and labelled, and a check that could not run says so rather than passing quietly. You can go and verify any of it — that is the point of the format.
We asked ourselves the same question — and the evidence says no. The issue isn't how well the model reasons or how large its context window is. A fact still works correctly even if it's placed 128,000 characters away from where it's used. But a fact that's missing or wrong will break the work, no matter how much context or token budget you give it. Making the context window bigger doesn't fix that. Better models get better at reasoning — but they can't invent facts that your repository never actually gave them.
It is a specific, measurable part of it, and it now has a name outside marketing. Academic work published in 2026 — “Coherence debt in repository-scale tasks”, cited in section 02 — named and measured it: facts about a system that an agent can reach neither from its context nor from the model’s memory. Ordinary technical debt slows people down. This particular kind misleads machines that are writing your code.
Specifications, yes, when they are committed to the repository: a spec checked in beside the code is documentation, and it is compared against the code like any other document. Tickets and pull-request descriptions are not, because they live in a tracker rather than in the repository — and we would rather say so than imply otherwise. Ticket-to-code and PR-description-to-diff are the next modules on the roadmap; they are the largest remaining gap and we know it.
Then this is a legacy assessment rather than an AI one, and it works the same way. Drift between code, tests and documentation predates AI by decades. AI-assisted development has simply made it accumulate faster.
The team that finds the problem can also fix it.
25+ years in complex software engineering, project recovery, legacy modernisation, AI, and enterprise delivery — a category of problem WaveAccess has seen many times. Remediation, when you want it, is delivered by the same team.
Find out what your repository is telling everyone else.
Read-only access, no pipeline changes, and no persistent copy of your code. Pricing on request.
Create an account and run the demo on one repository — your most critical, most AI-heavy, or most worrying. The demo is a short automated run: fewer than 20 of the audit's questions, and no human review. The full assessment comes with a subscription.