What it measures

Technical debt is the gap between how a codebase is built today and how it would need to be built to change safely and quickly. It shows up as the implementation shortcut, the deferred refactor, the outdated dependency, and the test that was never written, each carrying interest that gets paid every time someone touches that code. It is not a single number. It is a property of specific files, services, and subsystems that raises the cost of every future change passing through them.

There are two useful distinctions. Deliberate debt is a shortcut taken knowingly to hit a date, with intent to repay. Accidental debt is decay that accumulates as requirements drift away from the original design. Both show up the same way: work in those areas takes longer, breaks more, and depends on the few people who still understand the code.

How to measure it

There is no direct sensor for technical debt, so you triangulate from signals already in your history. From git, look for files with high churn and many distinct authors over time, repeated edits to the same lines, and hotspots where bug-fix commits cluster. A file that is changed constantly and always alongside a fix is paying interest. Pair this with complexity measured from the source tree so you separate code that is merely active from code that is both active and hard to change.

From the deploy pipeline and review data, watch the cost of change rather than the code itself. Rising lead time and change failure rate concentrated in specific services, longer review cycles on certain paths, and reverts that recur in the same module all point to debt being serviced. Dependency age, missing test coverage on high-churn files, and the ratio of fix commits to feature commits per area round out the picture.

The practical move is to rank by area, not to produce a global score. A heatmap of churn times complexity times defect density, scoped to files and services, tells you where repayment buys the most. A single org-wide debt index hides exactly the locality that makes the metric actionable.

What it does not tell you

Technical debt signals tell you where change is expensive, not whether that expense matters. A gnarly, high-churn module is only a problem if it sits on the path of work you actually intend to do. Debt in a stable, rarely touched corner can be left alone for years, and a high score there is noise. Churn, complexity, and defect clustering measure friction in the code. They do not measure whether the team is paying down the debt that blocks the current strategy or grinding on debt that no roadmap depends on.

The signals are also blind to cause and intent. High churn in a file can mean rot, or it can mean a healthy area under active, deliberate development. A clean, low-complexity service can carry severe hidden debt in an aging dependency or an unscalable data model that no static signal catches until it fails. Treating the number as the truth invites the classic failure: a quarter spent refactoring code that looked bad on a dashboard while the debt actually slowing the roadmap goes untouched.

This is the line between activity and direction. Counting debt is a volume question. Knowing which debt to pay is a strategy question. Execution Intelligence reads what is being built and why, so the debt that matters is the debt sitting between the team and the initiative it is trying to ship, not whichever files happen to score worst.

How InteliG uses it

InteliG computes these signals directly from real git and deployment history, with no manual instrumentation, tagging, or developer effort. It identifies the files and services where churn, complexity, and defects concentrate, then resolves who is repeatedly working that code and how often those changes turn into incidents or reverts.

The reasoning engine, Cognis, connects each pocket of debt to the initiative the surrounding work belongs to, the contributors carrying it, and the cost of the time spent there. That turns a list of messy files into a leadership decision: this debt sits on the path of an active initiative and is slowing it, this debt is in code nobody is touching this quarter and can wait. The verdict is about which debt is worth paying given where the org is actually trying to go.

Related terms

Code Churn — How often code is rewritten shortly after it is first committed
Change Failure Rate — Share of deploys that cause a failure or need remediation
Execution Intelligence — Reading what an engineering org is actually building and why, from real history