10 min read
I want to start with the kind part.
The people in your quality organization are not the problem.
They are not obsolete. They are not lazy. They are not standing in the way because they lack character. Most of them are doing exactly what rational people do inside the structure you gave them. They built careers around protecting customers, catching defects, and creating confidence before a release. For a long time, that was a sensible design.
Be respectful about that.
Then tell the truth anyway.
If you are rolling out AI across engineering in 2026 and you still maintain a separate quality organization as a gate between code and production, you are not preserving rigor. You are preserving an old emotional model of safety.
That is a different thing.
And if you are the CEO, the board, or the CTO still defending it, that distinction matters more than you think.
This Is Like Building an Arithmetic Department Next to Excel
I am trying to be precise here because this argument gets people defensive fast.
A separate quality organization made sense in a world where test creation was expensive, test maintenance was slow, execution was scarce, environments were brittle, and the only way to get confidence was to hand the build to another group of humans and wait.
That world is gone.
Not entirely. Not in every edge case. Not in every regulated workflow. But as the default operating assumption for software delivery? Gone.
AI agents are useful because they can work against executable truth. Tests. Contracts. fixtures. Synthetic data. CI pipelines. Observability signals. Deployment checks. They make progress because the system can tell them when they are wrong.
That is why the separate quality organization now looks so strange.
You bought Excel and kept a separate arithmetic department.
You gave every engineer a calculator and kept a room full of people whose job is to confirm that two plus two still equals four before the spreadsheet can ship.
That is not a quality strategy. That is an institutional memory of fear.
Agents Need Feedback Loops, Not Ceremonial Gates
Here is the part too many executive teams still miss.
Agents do not thrive because they are magical. They thrive because they get immediate feedback.
They write code. They run tests. They inspect failures. They change the implementation. They run the tests again. Over and over. Tight loop. Fast learning. Clear signal.
That loop is the whole game.
Now look at what a separate quality organization does in most enterprises.
Engineering writes code. Then it waits. Then another group picks it up. Then that group interprets intent, executes manual or semi-manual checks, files bugs, creates a queue, hands it back, and the cycle repeats days later.
You have taken the one thing agents and modern engineering both need most — immediate feedback at the point of change — and replaced it with an interdepartmental handoff.
Then you wonder why adoption feels slow.
Then you say AI is not ready.
No. Your operating model is not ready.
Quality that lives in another org chart teaches your engineers something destructive: quality is somebody else’s job.
That was already bad before AI. In an agentic world, it is fatal.
Because if your engineers do not own the tests, the evals, the release safety, the contracts, the observability, and the confidence model, then your agents do not own them either. The agents are trapped inside a partial system waiting for a human border crossing.
That is not how high-leverage software organizations work now.
What You Are Actually Defending
When a leadership team tells me they still need a separate quality organization, I ask a simple question.
What exactly is the ROI?
Not the folklore. Not the outage from 2018 that still gets mentioned in meetings. Not the vague statement that “our product is too complex.” Not the hand-wavy claim that “automated testing does not catch everything.”
Everything does not need to be caught by one mechanism. That has never been the standard.
Show me the numbers.
What percentage of escaped defects are caught by the separate organization instead of by engineering-owned automated tests, contract tests, integration tests, production telemetry, or customer-reported issues? What is the cost per defect found? What is the cycle-time penalty? What would happen if the same talent were embedded into platform engineering, developer enablement, test architecture, reliability engineering, and eval design instead of sitting in a downstream gate?
Most leaders do not have those answers.
Because most of them are not defending a measured system. They are defending a familiar one.
That does not make them stupid. It makes them human.
The separate quality org feels safe because it is visible. There is a team. A leader. A queue. A sign-off. A box on the org chart that says someone, somewhere, is “responsible for quality.”
But that feeling of safety is often purchased by delaying truth.
Defects found three days later are not a quality advantage over defects found three minutes later.
They are a more expensive way to learn.
Your Quality Team Should Still Exist. The Separate Quality Organization Should Not.
This is where people hear something I did not say.
I am not telling you to walk in on Monday and fire everyone with QA in their title.
That would be lazy thinking.
I am telling you that the work of quality has moved upstream, inward, and into the engineering system itself.
Your strongest quality people should be designing test strategy, not clicking through regression scripts someone wrote five years ago.
They should be building reusable test harnesses, shaping acceptance criteria, improving observability, hardening deployment guardrails, defining eval frameworks for agents, partnering on customer-journey validation, and teaching engineers how to think about risk.
That is serious work. More serious than what many separate QA organizations are doing today.
But it does not need a separate kingdom.
It needs integrated ownership.
If quality is everyone’s job, then the org design has to reflect that. Engineering owns build quality. Product owns requirement clarity. Design owns usability quality. Security owns security controls. Reliability owns operational safety. And the former QA specialists become force multipliers inside that system instead of a gate sitting outside it.
Quality remains mandatory.
The separate quality organization does not.
If Your CTO Is Still Saying AI Is Not Ready, Ask What They Have Been Doing Since 2024
I know that sentence lands hard. Good. It should.
In late 2024, “we are still evaluating” was a defensible sentence.
In mid-2025, it was becoming a warning sign.
In March 2026, if your senior technology leaders are still broadly telling you AI is not ready for engineering, I need them to be painfully specific.
Not vibes. Evidence.
Show me the codebases where agentic workflows fail. Show me the test gaps. Show me the change failure rates. Show me the domains where deterministic checks are genuinely insufficient. Show me the regulated constraints that require a human control. Show me the places where the current model outperforms an engineering-owned quality system with strong automation.
If you cannot show that, then “AI is not ready” is not a technical conclusion.
It is cover for inaction.
And if you are a CEO hearing that line for the twentieth time, you need to stop treating it as prudent caution.
It may be prudence. It may also be a leader protecting an operating model they understand because they do not yet understand the new one.
That distinction is your job to test.
This Is a CEO Conversation
If you are the CEO, do not let this get trapped in a tooling committee.
This is not a question about whether you buy one coding assistant or another. It is not a question about whether you pilot three vendors before Q4.
It is a question about whether your engineering system still assumes that quality is verified after the fact by a separate group instead of continuously produced by the system itself.
That is an operating model question. Which means it is your question.
You do not need to humiliate anyone. You do not need performative layoffs. You do not need to announce that QA is dead and everyone should clap.
You do need to ask your leaders a set of very uncomfortable questions.
Why is quality outside engineering?
Why are agents expected to work in a system where the truth signal lives in another department?
What percentage of your confidence is generated before merge versus after handoff?
How many days of cycle time exist purely because quality is organized as a downstream gate?
If you built this organization from scratch today, would you design it this way on purpose?
That last question matters most.
Because nobody would.
Nobody starting an AI-native engineering organization in 2026 would intentionally create a separate quality bureaucracy that sits between engineers, agents, and production truth.
They would build tests into the workflow. Guardrails into the platform. Quality expertise into the teams. Continuous validation into CI. Production telemetry into decision-making. Fast loops. Clear ownership.
They would not build what you have.
This Is Also a Board Conversation
If you are on the board, this may sound operational. It is not. It is strategic.
The organizations that absorb AI well will not just code faster. They will collapse feedback loops faster. They will turn quality from a department into a property of the system. They will move from inspection to instrumentation.
That compounds.
The organizations that do not make that shift will keep paying for delay, handoffs, duplicate work, bug whack-a-mole, and management theater dressed up as control.
If your technology leadership team is still defending a separate quality organization as sacred in 2026, you should not panic. Eighteen months of agents is not enough time to expect perfect answers.
It is enough time to expect movement.
It is enough time to expect working pilots.
It is enough time to expect engineering-owned test strategy, embedded quality expertise, measurable reduction in downstream gates, and leaders who can explain the future in operational detail instead of abstract hesitation.
And if you are not seeing that, then yes, you should start asking whether you have a leadership capability problem.
Not because the people are bad.
Because the market does not care how emotionally attached your leadership team is to the old org chart.
The Emotional Attachment Problem
This is the sentence underneath all of it.
You keep the separate quality organization because you do not really know what is going on yet.
Again — I mean that kindly.
When leaders do not understand a new system deeply, they cling to visible artifacts from the old one. The report. The committee. The stage gate. The department that can absorb blame when something goes wrong.
A separate quality org does all of that.
It gives you an object to point at and say, “they make sure releases are safe.”
But if you need that object because you do not trust engineering to own quality, do not trust your platform to enforce standards, do not trust your tests, do not trust your telemetry, and do not trust your agents, then the problem is not that AI is immature.
The problem is that your leadership model still does not understand where confidence comes from now.
Confidence used to come from inspection.
Now it comes from instrumentation.
Confidence used to come from handoff.
Now it comes from fast, repeated, automated proof.
Confidence used to come from another team saying yes.
Now it comes from the system showing its work.
If your leaders do not understand that, they will keep defending structures that feel safe while making you slower, more expensive, and less capable.
What to Do This Quarter
Do not start with a reorg announcement. Start with reality.
Map the path from code change to production confidence. Every test. Every handoff. Every manual check. Every wait state. Measure how much of that confidence is created inside engineering and how much is created by downstream inspection.
Then move one product area to an engineering-owned quality model. Embed your strongest quality people into the team. Give them authority over test architecture, eval design, release criteria, and telemetry. Put agents in the loop. Measure cycle time, escaped defects, and recovery speed.
Run that comparison for ninety days.
If the old model wins, keep it.
I do not think it will.
Then start dismantling the gate, not the people.
That distinction is the whole thing.
The Uncomfortable Part
If you are the CEO and your technology leader still wants to run a separate quality organization as a matter of principle, you do not need to fire them tomorrow.
You do need to challenge whether they are actually equipped to lead an AI-native engineering transformation.
If you are on the board and management still frames this as a cautious wait-and-see question, you do not need to demand a public scalp.
You do need to ask whether the people in charge understand the operating model they are supposed to be building.
Because by now, this is not really about tools.
It is about whether your leaders can let go of a system that made them feel in control.
That is the real test.
And if they cannot pass it, eventually you will need different leadership.
Not because the old leaders are evil.
Because the future does not care how attached they are to the past.
Quality still matters.
That is exactly why the separate quality organization does not.
