Something shifted in engineering job postings over the last two years, and if you spend any time in the hiring market, you have probably noticed it. The Software Development Engineer in Test — SDET — went from a position most people associated with Google and Amazon to a role that engineering leaders across every sector are now actively hiring, debating, and in some cases, restructuring their entire QA function around. 

Three things changed at roughly the same time, and each one is significant on its own:

If you want to understand what an SDET is and how the role fits into a modern team, the SDET Guide covers that ground. And if the operational question — how the role actually works inside a CI/CD pipeline — is what you are after, the SDETs and DevOps post is worth reading first. But if you want to understand why the market moved, and why the timing is not a coincidence, this is our take.

To understand the testing crisis, you have to start with what DevOps actually delivered in measurable operational terms. DORA research, which Google Cloud has been tracking consistently for over a decade, documents a deployment frequency gap between elite engineering teams and low performers that is not incremental but categorical:

What DevOps exposed, fairly brutally, is that testing infrastructure had not moved at anywhere near the same pace. Manual regression cycles built for quarterly releases were being stretched to cover weekly deploys and then daily ones — and the strain showed up in exactly the metric DORA uses to measure quality at velocity: change failure rate, the percentage of deployments that cause a production incident. 

The four DORA metrics measure delivery outcomes: deployment frequency, lead time, change failure rate, and recovery speed.. What does it need? The engineering mechanism that keeps quality stable while velocity increases. This narrow thing is the gap.

Engineering teams tried the obvious workarounds. None of them scale past a certain team size, deployment frequency, or product complexity threshold:

This is the section most trend pieces on SDET leave out, which is exactly why it deserves careful examination. The story up to this point — DevOps velocity outpacing manual QA capacity — was already a documented, solvable problem. AI-assisted code generation turned a manageable structural challenge into something considerably more urgent.

GitHub Copilot, Cursor, and their successors are not replacing developers. They are multiplying output. And the quality and testability of that output varies in ways that are not immediately obvious at the PR review stage — AI-generated code produces confident-looking logic with subtle edge-case errors that unit tests miss and manual testers rarely find before they reach production.

The SDET answer to this problem is NOT to test more slowly or more carefully. It is to own the test architecture — the framework that determines what gets tested, at what layer, and against what coverage targets — so that when AI doubles code volume, a well-structured test pyramid scales with it rather than buckles under it. T

The SDET role was not designed with LLM-assisted test generation in mind. But the skills of engineering instinct, framework ownership, pipeline thinking are exactly the skills that make AI-generated code testable at scale.

The velocity and volume arguments are largely technical. This one is financial, and it tends to land differently in conversations with CTOs and engineering managers — because it shows up on the budget in ways that are hard to dismiss once someone has actually run the numbers.

CISQ estimates the annual cost of poor software quality in the US at $2.41 trillion. Most of that is not spectacular production failures. It is quiet, compounding regression debt that nobody measures because nobody built the infrastructure to make it measurable.

A defect caught at integration testing costs approximately 10× more to fix than one caught in development — and up to 30× more after release. Manual QA concentrated at the end of the sprint is, structurally, the most expensive defect detection model available:

Source: NIST

SDET-led test automation does not eliminate testing cost. It shifts where cost is spent: from expensive late-stage defect detection to cheap early-stage defect prevention, and from human-time-intensive regression to pipeline-automated regression. The 90-day milestone for a properly structured SDET engagement is a regression suite running in under 30 minutes on every commit, with a documented defect escape rate trend line. That is a measurable return within a quarter — and it compounds as the suite matures.

The three forces in this post are not independent of each other. A team running at DevOps velocity, shipping AI-assisted code, with a manual QA function is not experiencing one of these pressures — they are experiencing all three simultaneously, and the compound effect is considerably worse than any single factor would suggest:

SDET sits at the intersection of these forces. The contribution is structural rather than marginal, which is why describing it as 'better testing' consistently undersells it:

Microsoft and Amazon were building embedded SDET pods into development squads in the early 2000s. What is genuinely new is that the three conditions that make the role essential have now arrived simultaneously for every growth-stage software company, not just a handful of elite organisations with the engineering culture and budget to pioneer new models. DevOps tooling is accessible at any scale. AI coding assistants are mainstream. And the talent cost of manual QA at scale is visible on engineering budgets in a way it was not five years ago. The role is not getting more popular because it is fashionable. It is getting more popular because the problem it was built to solve has stopped being an edge case.

Three questions worth putting to your current QA model honestly, before deciding this is a trend worth watching rather than a signal worth acting on:

Why is SDET becoming more popular now?
Three forces converged simultaneously: DevOps raised deployment frequency to a point where manual regression cannot keep up, AI coding tools multiplied code volume without a proportional increase in test coverage, and the economics of manual QA at growth stage became visible on engineering budgets. Each force alone would drive interest in SDET. Together, they make the role structurally necessary for any team trying to ship fast without accumulating quality debt.

Is SDET the same as a QA engineer?
No. A QA engineer executes tests against a completed build, typically at the end of the sprint. An SDET builds and owns the test automation infrastructure — the test pyramid, quality gates, and CI/CD integration — that makes it structurally difficult for defects to reach production. SDETs embed in development squads, review pull requests for testability, and own the pipeline's signal integrity. The difference is structural ownership versus reactive execution.

How do I know if my team needs an SDET?
Three signals: your regression suite takes longer than a sprint cycle to run, your test flake rate is above 5% and nobody has a remediation plan, or your defect escape rate is trending upward while your deployment frequency is also increasing. Any one of these indicates the pipeline is moving faster than quality is keeping up. A QA maturity assessment identifies where the gap sits and what an SDET engagement would need to address first.