Technical Debt Measurement Across Multi-Repo Codebases

Technical debt isn't new. Ward Cunningham coined the term back in 1992, and the metaphor still holds up: you take a shortcut today, and you pay interest on it every day after, in slower delivery, more bugs, and code nobody wants to touch. What's changed is the interest rate. Research cited by Zenhub's 2025 blog, drawing on Stripe data, puts developer time spent on debt and maintenance at roughly a third of the workday. A third of every engineer's time going toward code that already exists, not code that ships something new.

None of this shows up as one dramatic failure. Nobody's pager goes off because of technical debt. Instead, "find all usages" times out on a repo with half a million lines. Onboarding a new hire takes a full quarter because nobody documented which services call which functions. Someone wants to delete a deprecated method and burns two days just figuring out if it's safe to touch.

Here's the part most teams get wrong: they keep buying tools built for a world where one repo is the whole world, and that assumption is exactly what breaks once you're running dozens of them. A per-repo scanner can flag that utils.py has a code smell. It can't tell you the same fifty lines of business logic got copy-pasted into fourteen other repos across three teams, because it was never shown those repos in the first place. Dependency graphs now span services, teams, sometimes entire hosting platforms. There's rarely one dashboard where "total debt" gets read off as a single number, and pretending otherwise is how debt tracking programs quietly die.

Code search makes this worse, not better, because it's siloed by platform. GitHub's search only covers GitHub repos. GitLab's search only covers GitLab projects. Organizations running a mixed environment, or mid-migration between the two, hit a wall no native tool fills. Measuring debt across many repos takes a different set of building blocks: metrics defined the same way everywhere, visibility that crosses repo boundaries, and tooling built to surface patterns at scale instead of one repo at a time.

The four debt types AI coding assistants introduce, and why standard metrics miss them

AI coding assistants didn't invent technical debt. They're pouring gasoline on it. GitClear's AI Copilot Quality Research looked at 211 million changed lines across repos from Google, Microsoft, Meta, and other large enterprises, and the trend lines aren't subtle. Refactoring, as a share of all commits, dropped from 25% in 2021 to 9.5% in 2024. Copy-pasted code climbed from 8.3% to 12.3% over the same stretch. Code churn, meaning code rewritten shortly after it was written, sat at a 3.3% baseline in 2021 and climbed past 7% by 2025. Churn is a decent stand-in for "we didn't get it right the first time," and right now it's trending the wrong way, fast.

None of this comes from sloppy prompting. Large language models generate code inside a narrow context window and have no memory of the architecture sitting around it. They optimize for answering the prompt in front of them, not for fitting cleanly into a system with 200 other repos. That's debt nobody actually chose to take on. It just showed up quietly in the diff, which is exactly why it's harder to catch than the debt an engineer knowingly takes on to hit a deadline.

Stack Overflow's 2025 Developer Survey found 84% of developers globally are using or planning to use AI coding tools. Top-quartile teams already generate 40 to 60% of their code with AI assistance. At that level of adoption, duplication and churn don't stay contained to one repo. They get injected everywhere, all at once, across the whole org.

A 2026 multivocal literature review out of Drexel University, covering 104 sources, found large language models don't just amplify the debt types everyone already knew about (code debt, design debt, documentation debt). They introduce new debt categories beyond the familiar ones, including governance debt and long-term maintenance costs that accumulate faster than teams anticipate.

Classic metrics like debt ratio, remediation index, and maintainability grade (the kind SonarQube popularized) were calibrated on human-written code, and they still work fine on it. The trouble is they systematically under-report the patterns now dominating AI-generated commits, because those patterns don't resemble the mistakes a tired engineer makes at 6pm on a Friday. An empirical study titled "Debt Behind the AI Boom" dug into 302,579 verified AI-generated commits across 6,299 GitHub repos and tagged 484,366 distinct issues introduced by five widely used coding assistants. Four debt types kept showing up, and each one needs its own detection method, not one shared dashboard.

Maintainability debt is the biggest by a wide margin, at 89.3% of all AI-introduced issues. This is the stuff that doesn't crash anything but makes the next person's life miserable: bare-except blocks that swallow errors without a trace, open() calls missing an encoding argument, calls to deprecated functions, variables declared and never touched again.

Correctness debt is smaller in volume but scarier in effect. The dataset turned up 28,931 functional bugs, and the biggest single pattern was undefined variables, appearing 23,856 times. One commit from the Devin agent to the firecrawl repo passed cache=cache where cache was never defined, throwing a NameError straight into production. That's not a style nitpick. That's a crash.

Security debt shows up in 40 to 45% of AI-generated code, mapping to something on the OWASP Top 10. In Java specifically, the failure rate climbs past 70%, which is worth sitting with if a shop heavy in that language leans on Copilot or a similar tool.

Architectural debt is duplication piling up across repos instead of logic getting consolidated somewhere everyone can reuse it. That's the GitClear duplication data from above, just wearing a different name.

There's a fifth wrinkle worth naming: self-admitted technical debt buried in test code. A University of Manitoba study manually combed through 50,000 comments pulled from a pool of 1.6 million test-code comments across 1,000 open-source Java projects, and found 615 such comments spread across 14 categories, six of which only show up in test code. Neither static tools nor current LLMs catch these reliably, and nobody's built the tool that does yet.

The core metrics that actually capture debt across a multi-repo environment

Most of the metrics teams reach for don't survive contact with a second repo. A handful do, and those are the ones worth building a program around.

Technical Debt Ratio measures remediation cost as a share of total development cost, and it's comparable across repos as long as everyone calculates it the same way, which is the part organizations usually botch. Code churn, the percentage of lines rewritten soon after being written, is the clearest early-warning sign of AI-generated debt available, per the GitClear numbers above. Defect density (bugs per unit of code) ties debt hotspots to actual production incidents instead of leaving them as an abstract score sitting in a report nobody reads. Cycle time and CI/CD failure rate sit further downstream, but they prove debt is actually slowing delivery, not just sitting there in theory. Cross-repo duplication rate is the one metric standard per-repo tools flatly cannot produce on their own, because producing it needs a search layer spanning every repo at once.

There's a newer one worth watching: the AI vs. Human Turnover Ratio. If AI-generated code churns at more than 1.5 times the rate of human-written code, that's a threshold indicating the AI-generated share may be too high. A churn rate under 12% at the 30-day mark reads as healthy for AI-assisted code. Above 25%, and that's a red flag worth an actual meeting, not a quick message on a messaging app.

None of these metrics matter much if they're not calculated the same way everywhere. If repo A measures debt ratio one way and repo B measures it another, the two numbers can't be added, averaged, or compared. Full stop. Picking the right metrics isn't the hard part of a multi-repo environment. Getting everyone to define them identically is, and that's the step most orgs skip because it's the boring one.

Left alone, severe debt has been associated with development velocity reductions of 75 to 90%. That's not a typo, and it's exactly why catching debt early, consistently, across every repo, beats trying to fix it once it's already unpayable.

What each major measurement tool can and cannot see across many repos

SonarQube / SonarCloud runs static analysis across languages and repos, catching bugs, security vulnerabilities, and code smells, and tracking maintainability and test coverage over time. More than 7 million developers use it, and it was named a Leader in the inaugural 2026 Gartner Magic Quadrant for Technical Debt Management Tools. Paid plans start around $500 a year for small teams. It's strong on maintainability and security debt, with quality gates wired directly into CI/CD. The gap: it scans each repo on its own. It won't tell you the same duplicated function is quietly living in twelve different services, because nobody ever asked it to look across them.

Teamscale covers Java, Python, C++, and ABAP, with regulatory compliance built in for standards like ISO 26262 and NIST, and it integrates with GitHub, Jira, and Polarion. The Enterprise Plan runs €115 per contributor per month, available as SaaS or on-premises. It's built for organizations juggling ten or more repos, and its dashboards rank which refactors will actually save the most maintenance time instead of just flagging problems and walking away. The on-premises option matters for teams whose data privacy rules rule out cloud-only tools entirely.

CodeScene looks at behavioral patterns, how teams actually work with the code, alongside the usual structural metrics. Its CodeHealth score flags code actively getting worse over time, not just code that's already bad, and it surfaces "knowledge silos," modules only one developer actually understands, a real risk once an org clears a couple dozen repos. Priority heatmaps rank refactors by business impact instead of raw line count. Pricing details are available directly from CodeScene.

CodeClimate handles automated code review, maintainability ratings by component, and pull request integration that catches new debt before it merges, tracking trends over time and estimating the hit to team velocity. It fits naturally into CI/CD workflows built to stop new debt at the door.

NDepend specializes in dependency structure analysis and visualization, and it's a strong fit for.NET-heavy codebases specifically. It generates interactive web reports and supports pass/fail quality gates. Pricing is structured as a per-developer seat fee; current figures are available on NDepend's site. It suits legacy.NET debt cleanup or compliance audits well, but it's language-specific, so it's not the answer for a polyglot enterprise running Python, Go, and Java side by side.

CAST focuses on architecture analysis for large systems, surfacing structural debt at the system level rather than the file or function level. It's the right tool when the real question is how services are coupled together, not where the code smells are hiding.

Across every tool on this list, one question goes unanswered natively: show every place a deprecated pattern appears across all 200 repos in the organization. Answering that needs a separate layer sitting above the analyzers, one built specifically for search.

Why debt measurement at scale depends on a code search layer, not just static analysis

Teams tend to buy the quality analyzer first, because it produces the most demonstrable output on day one: a dashboard full of red and green. What they discover later is that an analyzer can only act on code it's been shown. It has no way to find duplication in a repo it was never pointed at, no matter how sharp its rule set is.

Cross-repo search turns out to be the prerequisite for most of the debt signals that actually matter. Finding every callsite of a deprecated API before removing it. Spotting the same business logic duplicated across a dozen microservices. Tracking down every version of a vulnerable dependency pattern across the whole estate. Figuring out which services break the moment a shared library changes underneath them. None of that is possible without a way to search every repo at once, rather than one at a time.

A purpose-built cross-repo search layer adds a few specific things: literal, regex, and symbol queries running across the entire codebase instead of one repo, symbol navigation that resolves definitions and references even when they cross repo boundaries, and results that feed the analyzers a full picture instead of a partial one.

For organizations where sensitive code can't leave company infrastructure, the search layer has to run inside that environment. Cloud-only search tools are disqualified immediately here, no matter how good the feature list looks on paper.

At the lighter end, open-source, single-purpose options don't require standing up a full code intelligence platform. Hound sits in the gap between "grep in one repo" and a heavyweight deployment, with minimal operational overhead. Livegrep, built by Nelson Elhage and used internally at companies like Stripe, is designed for fast, memory-resident search across large codebases. Both do one job well, and neither asks for a procurement meeting to do it.

How MCP and AI coding agents change what "measuring debt" means operationally

The Model Context Protocol, or MCP, is an open standard Anthropic introduced in November 2024 and later donated to the Linux Foundation's Agentic AI Foundation in December 2025. It defines a common way for AI applications to talk to external data sources and tools over JSON-RPC 2.0, which sounds dry until you see what it replaces.

Before MCP, hooking an AI assistant up to GitHub, Jira, a database, and a codebase meant building a custom integration for every pairing, a number that grows by multiplication with every new tool added. MCP turns that into a problem that grows by simple addition instead, a much smaller number once an org has more than a handful of tools in play.

By early 2026, MCP had spread across essentially every major AI coding platform: Claude Code, Cursor, GitHub Copilot in VS Code, Codex, Windsurf, Zed, Continue.dev, Cline, and Goose. OpenAI adopted it officially in March 2025.

Here's why that matters for debt measurement specifically. An AI agent connected via MCP to a cross-repo code search layer can find deprecated patterns, surface duplication, or summarize how services are coupled, the kind of question that used to mean pulling a senior engineer off real work for a day. But the agent is only as good as what it can reach. An agent that only sees files on one developer's laptop cannot answer a cross-repo question, no matter how good the underlying model is. The search layer is what makes the agent useful at this scale, not the model.

Claude Code takes an agentic search approach: it walks directories, reads files, runs grep-like queries, and follows references on its own. That helps with some of the staleness problems that come with pre-built indexes, but it's still bound by what it can physically reach. In a multi-repo enterprise environment, reachability means a deployed search index sitting behind the agent, not just the ability to walk a filesystem.

Putting it together: a practical approach to continuous debt measurement across many repos

Measuring debt across a multi-repo environment isn't one tool bolted onto another. It's three layers stacked on top of each other, and skipping the bottom one means the top two are just guessing with better production values.

The foundation is cross-repo search: the ability to run a query, literal, regex, or symbol-based, across every repo in the org at once, and get an answer in seconds instead of a support ticket. Without this layer, nothing above it has real data to work with. Full stop.

On top of that sits the analysis layer, the SonarQubes, Teamscales, and CodeScenes of the world, applying consistent metrics (debt ratio, churn, defect density, duplication rate) using definitions that hold steady from repo to repo. This is where debt gets scored, not just spotted.

The top layer is where AI agents, connected through MCP, turn all of that into something an engineer can actually ask: which deprecated patterns still have live callers, where duplication is costing the most in maintenance time, which services break first if a shared dependency changes.

Debt measurement across many repos was never really a tooling problem waiting on a smarter dashboard. It's a visibility problem first, and everything else, the metrics, the agents, the dashboards, only works once that visibility actually exists.