By Vaibhav Verma, Founder & CEO of Glue
The software industry has spent decades building better ways to detect problems in codebases. Static analysis, code coverage tools, dependency scanners, complexity metrics — the detection tooling is genuinely excellent. What we have barely invested in is verification: the systematic confirmation that detected problems were actually resolved after work was done to fix them.
This gap — between detection and verified resolution — is where billions of dollars of engineering investment disappears every year. Teams identify problems, do work, close tickets, and never confirm the problems are gone. The next quarterly health report finds them again. The cycle restarts.
Why Detection Alone Does Not Change Anything
I have talked with engineering leaders at dozens of companies who run regular codebase health assessments. Almost all of them describe the same pattern: the report comes out, it is alarming, tickets are created, sprints happen, and the next report looks nearly identical. The detection was accurate. The work happened. The numbers did not move.
Detection without verification creates a false sense of progress. A team that closes 15 technical debt tickets in a sprint feels like it is making progress. Whether the codebase is actually healthier after those 15 tickets is a separate question — one that most teams never formally ask. According to Jellyfish's 2025 research, engineering teams spend 23–42% of their time on technical debt. If a third of that work is not moving codebase health metrics, the cost is enormous.
The issue is not effort. Engineers are working hard. The issue is that there is no feedback mechanism connecting the work back to the original codebase signal. The engineering feedback loop is open — detection goes in, work comes out, but there is no return path showing whether the output actually addressed the input.
The Four-Stage Model of Closed-Loop Engineering Intelligence
Closed-loop engineering intelligence treats codebase health as a continuous cycle with four stages that must all be present for the system to work.
Stage 1: Detection. The intelligence layer reads the codebase and identifies problems — a file owned by one engineer who is about to leave, a service with 40% test coverage on a critical payment path, a dependency three major versions behind. Detection is the stage most teams already do reasonably well.
Stage 2: Translation. The detected problem is translated into a work item with enough specificity to be verifiable. Not "tech debt in auth service" but "auth service test coverage at 34%, target 70%, specific files: auth.js, session.js, token.js." The translation stage is where most current workflows lose fidelity — the specific codebase signal becomes a vague ticket description.
Stage 3: Resolution. Engineering work is done in response to the work item. This is what sprint planning and Jira are designed to support, and they do it reasonably well. The problem is that this is where the loop ends for most teams.
Stage 4: Verification. After the sprint closes, the intelligence layer re-analyzes the specific codebase sections flagged in Stage 1 and compares the new metrics against the original detection signal. Did test coverage move? Did ownership concentration change? Is the dependency updated? This stage is what makes the loop closed — and it is the stage missing from almost every engineering team's workflow.
What Happens to Work That Is Not Verified
When engineering work is not verified against codebase outcomes, several bad things happen with regularity.
Duplicate work. The same problem gets detected in multiple health reports and addressed in multiple sprints without anyone realizing it is the same problem — because the verification that would confirm resolution never happened. Teams I have spoken with estimate that 10–20% of their technical debt tickets address problems that were supposedly fixed in a previous sprint.
Partial fixes. An engineer addresses one symptom of a detected problem without addressing the root cause. The detection metric improves slightly, not enough to clear the threshold. Without verification, nobody knows whether the work made a meaningful difference.
Misattributed progress. A team's codebase health metrics improve in a quarter, and leadership credits the debt reduction initiative. The improvement is real, but nobody can confirm whether it came from the initiative tickets or from incidental improvements during feature work. This makes it impossible to replicate success.
Building Verification Into Your Engineering Workflow
Implementing closed-loop engineering intelligence does not require replacing your existing toolchain. It requires adding a verification step and connecting it back to the original detection.
The minimum viable version: when a codebase health issue is detected, record the specific metric and its current value alongside the ticket. After the sprint closes, re-measure that metric. This can be done manually with a codebase analysis tool, though it is time-consuming and rarely done consistently.
The more robust version uses a platform that automates the connection between detection, work, and verification. Glue does this by reading your codebase at the start of each sprint to detect risks, connecting those risks to sprint tickets, and re-reading the codebase after the sprint to verify whether the risks were resolved. The output is not just "which tickets closed" but "which codebase problems are actually gone." See this in action in Track Technical Debt From Detection to Verified Resolution.
The Metric That Changes Everything
Once you implement verification, you gain a metric that most engineering teams have never measured: verified resolution rate. Of the problems detected in your codebase health reports, what percentage are actually resolved — meaning the original codebase signal is gone — within the sprint they are ticketed?
Teams that measure this for the first time are consistently surprised by how low it is. Not because engineers are not working — because the gap between "ticket closed" and "problem resolved" is much larger than anyone assumed. The good news is that measuring it creates immediate pressure to close the gap. Teams that see a 40% verified resolution rate start writing better tickets, doing more targeted work, and verifying outcomes — and watch that number climb.
Detection is necessary. It is just not sufficient. The teams building the most reliable, maintainable software are not the ones with the most sophisticated detection tools. They are the ones who have closed the loop — and know, at the end of every sprint, whether the problems they worked on are actually gone.
FAQ
How is closed-loop engineering intelligence different from traditional code analysis?
Traditional code analysis detects problems. Closed-loop engineering intelligence adds translation (connecting detection to specific verifiable work items) and verification (confirming the work actually resolved the detected problem). The loop is: detect, translate, resolve, verify, detect again. Most teams only do the detect step consistently.
What is "verified resolution rate" and why does it matter?
Verified resolution rate is the percentage of detected codebase problems that are confirmed resolved — meaning the original codebase signal has changed — after engineering work is done on them. It differs from ticket closure rate because it measures outcomes in code, not activity on a board. Teams that track this for the first time typically find it significantly lower than expected.
How do I start building a closed-loop engineering intelligence system?
Start by adding explicit, measurable outcome definitions to your technical debt tickets — not just what work will be done, but what codebase metric will change and by how much. Then manually verify those metrics after each sprint. Once the habit is established, a platform like Glue can automate the detection, translation, and verification steps across your entire codebase.