Non Right First Time (NRFT) refers to work already done that requires rework, correction, or remediation after the initial attempt. It is a quality problem.
Defects are a typical form of NRFT in software development. I see them like receipts because it is like paying twice for something you already knew. When that happens in engineering teams, we typically point to insufficient testing, insufficient review, or a lack of experienced devs.
For me, NRFT occurrences and costs are still hidden within engineering teams. They rarely show up on dashboards. They are difficult to measure. Typically, teams rework about a quarter of their code before shipping.
I believe AI in software development is making NRFT cheaper to create and easier to miss at the same time. Change failure rate looks fine because in most of the cases, engineers catch AI’s errors before production. But they still burn many hours on rework, even if they avoid the failure. The waste now happens in review queues and rewrites, since those rework hours never touch production, so no delivery metric records them.
In addition, the NRFT compounds across the queue. Every bounce-back costs more than a rewrite. It re-enters the workflow and waits in line again, behind everything else that arrived while it was being fixed. That’s one reason your lead time creeps up, even when everyone is busy.
Diagnosis: Four conditions that guarantee rework
In tech, when work comes back wrong, we add tests, reviewers, or, if required, we hire seniors. But every time we tightened inspection, the rework just changed shape. The reason is that inspection treats symptoms.
Here are the four systemic reasons I observe:
Work arrives ambiguous: a development task arrives with vague acceptance criteria. For example, we may have undefined edge cases or unstated assumptions. So the engineer fills the gaps with their best reasonable guess, which is wrong. The reviewer finds out a week later. So the defect you see in review is often a translation problem that happened upstream, two handoffs earlier.
Feedback arrives too late: a rework exists as soon as you discover the mistake. The repair might be expensive, but you also incur compounding costs between the mistake and its discovery date. Unfortunately, when a reviewer takes two days to respond, the engineer has already moved on mentally. By the time the comments arrive, reconstructing the context costs more than the fix. So the longer the delay, the higher the bounce rate. The delay is a property of the system.
Batches are too big: honestly, nobody truly reviews a 900-line pull request. You skim it. Big batches also amplify the previous cause. Indeed, the larger the change, the longer the review queue, so the slower the feedback.
AI inverted the ratio between generating and checking: AI output is generous and mostly free, but the verification still runs at human speed. That imbalance guarantees NRFT. You can generate five implementations faster than you can review one. Errors pile up in the gap.
I am not saying that some engineers are lazy and hence approve bad code. In my opinion, regarding NRFT, they’re approving code that disguises its wrongness.
Those four causes together lead to the pattern I see in teams with a stalled lead time: ambiguous work in, slow feedback loops around it, oversized batches flowing through, and an AI engine amplifying the volume.
Countermeasure: Keep Work Visible and Small
The fix is one rule with three consequences: work enters the flow clear, moves in small pieces, and stops the moment something is wrong.
Work enters clear: a development task doesn’t enter the flow unless it has explicit acceptance criteria. Edge cases are properly listed, and the dev team has had the right discussions with the requirements owner. Recall that when an engineer fills gaps with guesses, the defect is created before the first line of code. So the gate is to keep ambiguous work outside the system.
Work moves in small pieces: cap the size of what flows through review. The principle: small enough that a reviewer actually reads all of it in one sitting. Small pieces are cheap to fix. Smallness is also what makes AI output survivable. A 100-line piece has better chances of being verified instead of skimmed.
Work stops when something is wrong: the moment a defect appears, anywhere, by anyone, the item it belongs to stops moving. It gets fixed immediately while the context is fresh, with all dependencies on sight. It can also be returned to the person who created the ambiguity while they still remember. That stop has only one objective: learn and avoid the same mistake going forward.
The whole point is the distance between the mistake and its discovery. Every mechanism above exists to collapse that distance to minutes.
Clear entries mean fewer wrong first attempts. Small pieces mean mistakes surface fast. Stopping means you fix mistakes where they were made. The team that applied this rebuilt the conditions the code flowed through.
These three are a system to build.
Problem-solving keeps them alive. For that purpose, it has to be the team’s reflex for every bounce-back. When work comes back wrong, the collective question is always “why,” so which condition failed us.
Real Case: Twenty Percent Right First Time
Thirty developers had a defect backlog that refused to shrink despite weeks of correction sprints.
So together with the tech lead, we followed the full lifecycle of ten consecutive defect corrections to see whether the fix held the first time or came back.
Eight out of ten came back, so the team corrected the issue right the first time only 20% of the time. They spent 80% of their bug-fixing capacity fixing their own fixes.
Diving into the ten’s lifecycle told us why:
The analysis was only partly implemented. The person doing the correction implemented what they understood of the diagnosis. Those devs were genuinely trying to close their tickets. But when the root cause touches something outside your comfort zone, you fix the part you can reach and hope it covers the rest.
Unit tests were minimized. Developers wanted to get to the code and treated the tests as the tax. Rushed tests, written after the fact, verify almost nothing. So the fix was “done” before anyone knew whether it worked.
Nobody identified the root cause before correcting. Several fixes addressed symptoms. If you don’t know why the bug exists, your correction is a guess with a ticket number. Guesses bounce.
One defect took six re-tests. Each re-test was run on incorrect data. Nobody had sat with the business to understand what the real cases looked like, so the team validated its fixes against invented ones.
Requirements were misinterpreted. Same root, different branch: nobody had gone through the requirement with the people who wrote it. The team was working from its own reading of the document. Plausible reading, wrong one.
In those five, a pattern emerges. One is about competence. The other four are about the same missing ingredient: conversation. With the system, the tests, the business, the requirements. The team was working alone against bugs that lived in shared understanding.
We applied the countermeasure exactly as described above, plus one thing this team needed: before touching any defect, identify and write down the root cause, then sit with the business to confirm the data and expected behavior before correcting. No fix started without that. The first reaction was “we don’t have time for this.” Within two weeks, they had time. The re-testing loops disappeared.
Three months later, NRFT was at zero. Defects dropped from 92 to 8 per month. All that happened with the same thirty people and no additional tooling.
Now, let me be clear and honest here. Defects are still a problem. Eight per month is still painful. Eliminating those means working on the defect root causes, design, architecture, etc.
The same pattern is spreading. Teams whose change failure rate looks fine while their developers burn half a day correcting model output. You’ve now seen how one team stopped paying twice. It’s time to look for yours.