In got stuck in the robustness section. You note that teams report getting better at diagnosing production problems while recovery outcomes are becoming more variable. Both of those can be true at the same time, but unfortunately MTTR has no way to show it because it collapses a sequence of intervals into a single duration.
If you remember the Cloudflare incident (Nov 2025) and go through their postmortem: 5 hours and 38 minutes end to end. Roughly 2 hours went to working out what was happening. The mitigation was reverting a config file, so the interval after diagnosis behaves nothing like the intervals before it. Flattening all the intervals hides which lever you're actually missing.
At Unleash, we ended up naming it "mean time to neutralize" (MTTN), as the span from diagnosis to impact reaching zero, whether or not the underlying bug is fixed yet.
The companion metric is the gap between users stopping hurting and the real fix shipping. I find it fascinating because it's the rare incident duration that improves as it gets wider. Why? Because it means someone wrote the fix without the graph bleeding underneath them.
The maintainability up, change confidence down split is fascinating. Locally clean code inside a system that's getting harder to reason about is exactly how it feels on the ground right now.
The dimension AI breaks hardest is the one nobody scores: whether the author can explain why the code is the way it is. Every other part of a 2020 quality definition can be satisfied by generated code, and often is, because the model has read more idiomatic code than any of us. CloudBees surveyed 200 enterprise technology leaders this year: 61% of the average codebase is now AI-written, 81% report more production issues from it, and 92% say they are confident in it. Tidier code, more incidents, higher confidence. That combination only makes sense if the thing review was actually measuring was never the code, it was whether a human had a defensible model of the change.
The line about the end of the chain becoming a late place to look is the one I would build on, and there is a second dataset landing in the same spot. Research-Driven Engineering Leadership covered a study this week that analysed 9,427 agentic pull requests across 1,391 repositories. 74.1% merged with no developer modification at all, and 19.1% of those from peripheral contributors merged without a single CI check running. So the review step you would rely on to catch a locally plausible change that quietly damages the system is the step most likely to be skipped, precisely on the code that arrived with the least context attached.
One place I would push back gently. Cognitive debt and intent debt get described as hard to see, and they are, but there is at least one cheap proxy already sitting in everyone's data: the ratio of code changed to context written. A PR that alters 400 lines and carries three lines of description with no linked decision is intent debt accruing at a measurable rate. It is crude and it will get gamed. It still beats what most organisations have, which is nothing.
The user needs dimension is the one I have no answer to. I do technical diligence for investors, and I can audit a codebase inside two weeks. I have never once been able to audit whether the software solves the problem it was bought to solve. The asymmetry you name is the whole reason that gap survives.
In the projects I work on with clients in the financial sector, the most common practice for determining whether artificial intelligence has helped or hindered the work of programmers is to measure the number of defects or the failure rate after making a change to the software.
In regulated industries, such as the financial sector, the biggest problem is losing sight of the business rules, or rather, the reason why those rules were designed that way. Banks’ core systems, built with COBOL, were created decades ago and have undergone changes over that time; generating more code with AI on this foundation will increase the size of a system whose rules no one fully understands. Documentation may even increase, but the team’s actual mastery of the business rules remains the same or is even reduced.
The known risk of relying on knowledge stored in the minds of just a few people is shifting; now we’re dependent on AI-driven automated processes that generate code that no one fully understands. I addressed this topic in the episode “Does Your Mainframe Have an Expiration Date?” on *Bancada da Sala das Máquinas*, as well as in my video “COBOL Was Never the Bottleneck,” which is available on YouTube. Unfortunately it is in my native language (Portuguese) https://youtu.be/ne7NKyTSxoU?si=LBR2uHfTbt83wnZP.
In got stuck in the robustness section. You note that teams report getting better at diagnosing production problems while recovery outcomes are becoming more variable. Both of those can be true at the same time, but unfortunately MTTR has no way to show it because it collapses a sequence of intervals into a single duration.
If you remember the Cloudflare incident (Nov 2025) and go through their postmortem: 5 hours and 38 minutes end to end. Roughly 2 hours went to working out what was happening. The mitigation was reverting a config file, so the interval after diagnosis behaves nothing like the intervals before it. Flattening all the intervals hides which lever you're actually missing.
At Unleash, we ended up naming it "mean time to neutralize" (MTTN), as the span from diagnosis to impact reaching zero, whether or not the underlying bug is fixed yet.
The companion metric is the gap between users stopping hurting and the real fix shipping. I find it fascinating because it's the rare incident duration that improves as it gets wider. Why? Because it means someone wrote the fix without the graph bleeding underneath them.
More context about MTTN from our blog: https://www.getunleash.io/blog/mean-time-to-neutralize
The maintainability up, change confidence down split is fascinating. Locally clean code inside a system that's getting harder to reason about is exactly how it feels on the ground right now.
The dimension AI breaks hardest is the one nobody scores: whether the author can explain why the code is the way it is. Every other part of a 2020 quality definition can be satisfied by generated code, and often is, because the model has read more idiomatic code than any of us. CloudBees surveyed 200 enterprise technology leaders this year: 61% of the average codebase is now AI-written, 81% report more production issues from it, and 92% say they are confident in it. Tidier code, more incidents, higher confidence. That combination only makes sense if the thing review was actually measuring was never the code, it was whether a human had a defensible model of the change.
The line about the end of the chain becoming a late place to look is the one I would build on, and there is a second dataset landing in the same spot. Research-Driven Engineering Leadership covered a study this week that analysed 9,427 agentic pull requests across 1,391 repositories. 74.1% merged with no developer modification at all, and 19.1% of those from peripheral contributors merged without a single CI check running. So the review step you would rely on to catch a locally plausible change that quietly damages the system is the step most likely to be skipped, precisely on the code that arrived with the least context attached.
One place I would push back gently. Cognitive debt and intent debt get described as hard to see, and they are, but there is at least one cheap proxy already sitting in everyone's data: the ratio of code changed to context written. A PR that alters 400 lines and carries three lines of description with no linked decision is intent debt accruing at a measurable rate. It is crude and it will get gamed. It still beats what most organisations have, which is nothing.
The user needs dimension is the one I have no answer to. I do technical diligence for investors, and I can audit a codebase inside two weeks. I have never once been able to audit whether the software solves the problem it was bought to solve. The asymmetry you name is the whole reason that gap survives.
In the projects I work on with clients in the financial sector, the most common practice for determining whether artificial intelligence has helped or hindered the work of programmers is to measure the number of defects or the failure rate after making a change to the software.
In regulated industries, such as the financial sector, the biggest problem is losing sight of the business rules, or rather, the reason why those rules were designed that way. Banks’ core systems, built with COBOL, were created decades ago and have undergone changes over that time; generating more code with AI on this foundation will increase the size of a system whose rules no one fully understands. Documentation may even increase, but the team’s actual mastery of the business rules remains the same or is even reduced.
The known risk of relying on knowledge stored in the minds of just a few people is shifting; now we’re dependent on AI-driven automated processes that generate code that no one fully understands. I addressed this topic in the episode “Does Your Mainframe Have an Expiration Date?” on *Bancada da Sala das Máquinas*, as well as in my video “COBOL Was Never the Bottleneck,” which is available on YouTube. Unfortunately it is in my native language (Portuguese) https://youtu.be/ne7NKyTSxoU?si=LBR2uHfTbt83wnZP.