Should QA Play Offense? 5 Perspectives on the QA-to-Dev Shift in the AI Era

1. Who Owns Quality?

Google's model has developers test their own code while testers build tools and platforms. A veteran QA on Hacker News (salawat) opposes this: without dedicated QA, the only enforcement power that can make developers care about quality disappears. Another commenter argues QA should function like a police internal affairs unit, not reporting to the same manager as the product team. The core question: if responsibility belongs to everyone, on whose performance review does quality actually sit?

2. Goalkeeper Joining the Attack

Checks-and-balances evidence relies on redundancy: the FAA requires two pilots on every plane; auditors do not sign off on their own financial statements.

Integration evidence cites Microsoft's 2014 elimination of the SDET role, merging testing into development. A participant later recalled that after a one-year transition, delivery speed did not decline.

A rarely mentioned figure: after the dust settled, former testers still did roughly 70% testing plus 30% development, while developers did the reverse. Roles were merged administratively, not by capability. Microsoft is now hiring pure testing roles again and outsourcing large volumes of testing.

3. The Bill Arrives at Verification

"More monitoring lowers efficiency; less monitoring lowers quality" describes a cost transfer.

DORA 2025 reports 90% of respondents use AI, over 80% say productivity rose, yet AI adoption correlates negatively with delivery stability. GitLab 's survey finds 85% believe the bottleneck has shifted from writing code to reviewing code.

Sonar's survey adds a sharper number: 42% of committed code is AI -generated, while 61% say it "looks right but is unreliable."

Counter-arguments exist:

One says the real bottleneck is deployment frequency; smaller batches alleviate it.

Another says AI makes verification cheaper too, pointing to Hacker News discussions where TDD with AI reduces to two questions: "Can you watch it fail?" and "Is the failure reason correct?"

The most troubling counter-argument is logical: using AI to verify AI is circular reasoning. Code and tests come from the same understanding; expected results are also written by AI; real bugs slip through silently.

4. This Accounting Has Run for Thirty Years

In the 1990s Microsoft's role ratio was 1 developer : 1 tester : 0.5 PM. In 2000 they cut one sequence; in 2014 they merged the rest into development; now they are rehiring pure test roles.

Google's testers went from SET to SETI to Engineering Productivity — three name changes, people still there.

Reddit reminds us: over twenty years ago people claimed automation would replace manual testing; it didn't happen.

Instead of debating "will QA disappear," look at two measurable things:

Three months after transfer, are people writing business code or test/tool code?

On whose performance review do quality metrics sit, and who produces the verification evidence for AI -generated output?

Finally, two concrete questions:

Do your QA and developers report to the same manager? AI writes the code — who ultimately signs off on it?