What you can measure of technical debt
The debt itself can't be measured, its traces can. A file that is complex, changes often and has few tests is expensive to touch. Those are the places where it chafes first.
What we measure
With fixed tools, without AI, on your repository:
- The most complex functions and files
- Hotspots: files that are complex and also change most often
- Size per language, and how much test code there is against the code
- Runtimes and frameworks that no longer get updates, and whether there are lockfiles
- From the git history: how old, how active, and whether the work sits with one person
Then an inspection reads the architecture
An AI model reads the code, read-only, and notes claims about how it is built. Every claim must point to a file and a line, or it doesn't go in your view. We are accountable for the check, not for the cleanup.
What we don't do
We don't convert debt into an amount or a number of days of work. That would be a figure we can't support. You get the findings with their proof and the place where they sit.
We clean up nothing. You decide what to tackle first.