Your Team Doesn’t Have a Defect Problem
A diagnosis, a countermeasure, and one real case. Two months of system work, and the part no playbook can install.
AI writes a real share of your code now. More code, shipped faster, doesn’t mean fewer defects. They still come back, they still bounce between developers and testers, and now there are more of them moving through a flow nobody can see.
I watched this break in a bank’s engineering team years before AI arrived, which is why I trust the pattern. Here is what I saw, and what works.
Where the defects came from
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.
So I sat with the team, and we analyzed the last 25 defects that had already been corrected. One by one, we uncovered why they were really born. More than half traced to a single place: the analysis handed to developers was wrong before anyone wrote a line of code. The rest came from source-code errors and unit tests that were missing or too weak to catch anything.
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 here is the part most case studies cut, and it is the part that actually matters.
The numbers were never the hard part. Holding them was.
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
Engineering teams don’t have a defect problem. They have a system that lets broken work in upstream, then hides it until it piles up, bounces, and comes back.
That team had no AI in its toolchain. Yours does. 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.
Build the problem-solving first. The quality follows.
If you suspect your defects are bouncing through a flow nobody can see, start with the Delivery Scorecard. Two minutes, ten questions, and you know where to look first. And when AI tooling is part of the picture, I run a half-day working session with leadership teams on exactly this. Reply to this email, and I’ll send you the outline.