I sat with the team and we took the last 25 defects, one by one, to find where each one was really born. More than half never reached a line of code before they were broken. The analysis handed to the developers was already wrong.
This was a bank's engineering team, years before AI was in anyone's toolchain.
What the flow was doing to them
Developers worked hard, and the system around them produced defects faster than they could clear them. In a single month, they logged more than they could fix.
The deeper pattern was uglier. The same code was being patched by several people in turn, each correction degrading it further. Analyses kept changing mid-build, drifting from the original client’s request. When a developer received a faulty analysis, there was no way to stop it. They built from it anyway, and it came back as a defect. Each fix created the next defect.
The developers were doing their job. The work reaching them was broken, and nobody could see where it broke.
Why “add more QA” doesn’t work
The standard response to a team drowning in defects is to add testers, tighten the gate at the end, run a bug bash, buy a defect-tracking tool.
This approach fails because it treats defects as something to catch at the developer’s desk. They were born upstream, in the analysis, before code existed. Add testers at the end, and you end up inspecting more rework. A new tool full of tickets nobody reads is the same blindness with a license fee. You cannot test quality back into work that arrived broken.
Rebuild the intake, not the team
The point was not to teach developers to code more carefully. The team rebuilt what reached the developers, and where quality got checked. They moved the control point from the end of the work to the start.
Most defects traced back to a faulty analysis, so no analysis entered development on its own anymore. The analyst and the developer sat down together and turned it into a test plan before a line of code was written. That became a fixed step in the flow, not a favor asked when someone had time.
When an analysis came in wrong or unclear, it stopped being quietly worked around. It went into a red bin, in the open, and back to whoever wrote it. Sending bad work back became normal and visible instead of awkward. And because analyses kept changing after work began, any change now triggered a fresh review before the work moved on.
One more thing kept the defects coming. The analysts who wrote the specs kept getting pulled onto new projects, so when a developer needed to check something, the one person who could answer had moved on. The developer guessed instead, and the guess came back as a defect. The dev team made it a standing rule to escalate to the project manager and keep the analyst on until the work shipped. The person who owned the spec stayed reachable.
None of this was a new tool or a reorg. It was a handful of standing rituals at the front of the line, all of it tracked on one visual board the team stood in front of each morning, reading a single number: how many new defects had come in the day before. They stopped catching defects at the end and started refusing them at the start.
Two months later
Two months later, the team had cut its defects by 91%. Right-first-time fixes went from fewer than one in ten to nearly all of them. They did it without new people, new tools, or a single line of AI, on legacy banking software written and maintained by hand.
The numbers moved fast. The first root-cause analysis started within a week. But the number is not what matters most. It is what I saw on the wall on the second month.
By the second month, something shifted that I did not install. Developers started walking to the board during the day, unprompted. They moved their own work. Handwritten problem-solving sheets appeared on the wall, some half-finished, that nobody had asked them to post. When managers visited, the developers walked them through the metrics and the open problems themselves. They were not doing that to impress anyone. It was because the board was theirs now.
That ownership is the part no framework installs. You can copy the board and the intake rule in an afternoon. You cannot copy the two months it takes a team to learn to solve and own its own work, and that is the only thing that keeps the number down after I leave.
The pattern
More than half of those 25 defects were already wrong before a developer saw them. Nobody was checking the analysis before it went into development.
Every line of that code was written by hand. Now imagine the same analysts sending the same broken specs to a team with AI coding tools. AI tools accelerate whatever your system already does. If your system lets bad analysis through, AI helps you turn it into code faster. More volume means more rework, and more defects moving through the same blind flow. The slip arrives before anyone sees it coming.
Seeing the defects was not the fix. What fixed it was the team digging into its own defects, finding the cause, and building the countermeasure itself. The intake gate was this team’s answer to its own cause. Yours will be different, and only a team that can solve its own problems will find it. AI will not do that for you.
The 91% is the quick part. The one that lasts is a team that runs its own board and solves its own problems. That took the full two months.
If you want to check your own team, take the last 25 defects and find out where each one started. You may be surprised how many never reached the code.