There’s a narrative floating around that AI agents are replacing quality engineers. I don’t buy it. Not because AI isn’t powerful — it is — but because the thinking that makes QE valuable — the end-user perspective, the holistic system view, risk-based judgement about what actually needs testing — isn’t something AI can generate on its own. It’s needed more now, not less.
We’re Still in the Infancy
AI-powered development is new. We’re treating AI the way we’d treat a new team member — giving it high-level instructions and expecting it to fill in the blanks from experience and domain knowledge. But AI doesn’t have past experience. It doesn’t have domain context. It has patterns, probabilities, and a strong desire to please you.
The result: it rarely pushes back. It doesn’t ask enough questions. It makes assumptions and runs with them. And when you ask it to write tests, it creates a lot of them — giving you a false sense of security while missing the tests that actually matter.
We’re instructing AI the way we’d instruct a human. That doesn’t work. AI needs you to be deterministic, detail-oriented, and descriptive. It needs structure it can follow, not intent it has to guess at.
The Output Problem
It’s true — AI generates code faster than any human can. The volume of output is remarkable. Deliverables get delivered. Pull requests pile up. Code gets committed.
But speed without quality is just technical debt at velocity.
AI-generated code is often not secure, not performant, and not production-grade. It looks right. It compiles. It might even pass the tests it wrote for itself. But it cuts corners humans wouldn’t — because it optimised for completion, not for correctness.
This is exactly why the need for strong quality engineering is increasing, not decreasing.
The Principles AI Can’t Replace
AI can generate a test in seconds. It cannot tell you which test matters. That gap is where core QE thinking lives — and none of it is new. It’s the same thinking that’s always separated good testing from checkbox testing. What’s changed is that it’s now the bottleneck and the differentiator, because AI has commoditised the mechanics:
- The end-user perspective. AI optimises for “does this satisfy the acceptance criteria,” not “does this feel right to the person using it.” Someone still has to ask whether a real user would actually work this way, and whether the flow makes sense end to end — not just whether each step passes in isolation.
- A holistic, system-level view. Agents work within the scope of the task they’re given. They don’t naturally reason about how a change ripples through the rest of the system — the integration points, the downstream services, the failure modes that live between components rather than inside one.
- Risk-based testing. To be fair, a well-prompted model can often guess that checkout matters more than the settings page — that’s pattern-matching on common naming conventions, not judgement. What it can’t know is that the settings page is actually your highest-risk surface because it processes GDPR deletion requests, or that checkout broke production twice last quarter for a reason nobody wrote down anywhere AI could read it. Real risk-based testing is built on incident history, support ticket patterns, and compliance exposure — signals that live in postmortems and people’s heads, not in the codebase. Left to its defaults, AI spreads effort evenly; deciding where to concentrate it, including the counter-intuitive cases, is still ours to make.
- Knowing what to test, how, and where. Functional correctness is one dimension among many. Performance testing is just one example — security, accessibility, resilience under load are others — and AI won’t propose any of them unless you already know your system well enough to ask for them by name.
The day-to-day craft has changed. We may no longer hand-write every test. But the qualities that made someone good at this — seeing the system the way a user experiences it, knowing where the risk actually lives, choosing the right kind of testing for the right problem — are precisely what determine whether an AI-assisted team ships something reliable or ships something fast and broken.
Why I Built the Agent Framework
This is the problem that led me to build a 15-agent, 3-tier system with a 4-tier context management architecture:
Tier 1 — Orchestrators (the brains): They reason about requirements, plan the work, decide which agents handle what. They don’t write code.
Tier 2 — Implementers (the hands): They write the code, generate the tests, produce the deliverables. Fast, but not self-governing.
Tier 3 — Reviewers and Authors (the quality gates): They review every output before it advances. They catch the assumptions, the missing edge cases, the security gaps. Nothing reaches Git without passing through them.
The whole point is to impose the structure that AI lacks on its own. AI is a powerful tool. But a powerful tool without guardrails produces powerful mistakes.
The QE Role Is Changing — Not Shrinking
The SDET position is shifting. Less time writing test code manually. More time:
- Instructing AI agents — defining what to test, how to test it, and what “good” looks like
- Reviewing AI output — catching the assumptions, the hallucinated assertions, the tests that look comprehensive but test nothing meaningful
- Architecting AI workflows — designing the systems and pipelines that make AI-assisted development reliable and repeatable
- Identifying what matters — AI doesn’t know which tests are valuable. It will happily generate 200 tests for a utility function and zero for a critical business workflow. Knowing what to test is a human skill
The people who understand test strategy, risk modelling, and quality architecture are more valuable now than they were before AI. The tools changed. The thinking didn’t.
QE Redefined
We’re not being replaced. We’re becoming AI engineers — architecting agent systems, writing the instructions that govern AI behaviour, designing the quality gates that separate good output from confident garbage.
The job isn’t “write a Cypress test.” The job is “design a system where AI writes the Cypress test correctly, and a reviewer agent catches it when it doesn’t.”
That’s harder. It requires deeper thinking. And it’s exactly the kind of work that makes quality engineering more essential, not less.
This is what I’ve been building toward — a methodology with its own lifecycle. Not a replacement for how we ship software, but a new layer alongside it: the ADLC — The Missing Lifecycle for AI-Assisted Engineering. Bootstrap once with define, architect, instruct. Then calibrate continuously: execute, review, refine, execute again. The output isn’t a feature. It’s a better-calibrated agent system.
We’re not being eaten. The tools changed. The discipline behind them — the end-user view, the risk-based judgement, the knowledge of what to test and why — is more essential than it’s ever been.
That discipline has to come from somewhere. On the pipeline problem AI creates for the people who’d otherwise grow into it: Who Trains the Next Generation of Senior Engineers?