The engineer who treats your test suite like production code βΒ because these days it is.
A reward for spending your Saturdays casually browsing Reddit is usually a killer meme or two, maybe a UFO video that's 100% not AI, trust me bro. Occasionally, though, one of those meme-hunting sessions gets me thinking.
InnocentlyΒ stumbling upon aΒ random QA subreddit, during one of these incredibly rewarding meme-hunting sessions, actually prompted meΒ βΒ notΒ to be confused with the other kind of prompting, you know which one βΒ to finally put some thoughts together about a role that seems to be having an identity crisis at exactly the wrong time.Β
The SDET.Β
Here's the thing: AI agents can write code now. They can write tests, fix bugs, open pull requests, and argue with you about why their pull request is correct. At the same time, we're producing more software than ever, and in June 2026, Cloudflare reported that automated bot traffic had overtaken human traffic on the internet.Β
More software, more bots, and a QA job market getting squeezed at the same time. According to data compiled by Layoffs.fyi1, more than 124,000 tech jobs were reportedly cut globally in the first seven months of 2026 βΒ already ahead of the roughly 122,000 cuts recorded across all of 2025. QA has an extra problem layered on top: companies are asking whether they need as many people whose main job is testing when developers can automate more of it, and AI agents can generate and run tests themselves.Β
So, when I say the SDET role is having an identity crisis, I don't mean everyone's about to be replaced by a robot. I mean companies are asking an uncomfortable question: if AI can write the code, write the tests, and run the tests, what exactly are we paying the SDET to do?Β
That's a much more interesting question than whether SDETs are going away. Machines are increasingly producing software, and machines are increasingly consuming it. So, if producing software isn't the actual bottleneck anymore, what is?Β
I think it's verification.Β
Not quite a developer. Not quite QA.Β
Open three SDET job postings on LinkedIn and you'll notice something odd β one wants five years of Java and a systems-design interview, another wants Playwright and TypeScript full stop, a third puts Kubernetes right next to "test case design" like they're the same skill. Same title, wildly different job.Β
I don't think that's sloppy hiring. I think it's a symptom of something more interesting: we're still figuring out what an SDET actually is.Β
The role lives between development and testing, but that's not a neat 50/50 split βΒ the useful part is the overlap. An SDET needs enough development knowledge to understand how a system is built, enough testing knowledge to understand how it fails, and enough judgment to know which failures are worth worrying about. In 2026, that tends to mean:Β
- Programming fluency βΒ writing production-grade code, not disposable scripts.Β
- Test architectureΒ βΒ automation that survives change instead of becoming a second legacy system.Β
- CI/CD ownership β flaky tests aren't annoying lights; they're technical debt with a countdown timer.Β
- System-level testingΒ βΒ moving between UI, API, integration, contract, white-box and black-box as the problem demands.Β
- Production instincts βΒ quality doesn't stop mattering at deploy; telemetry and real-user behavior matter too.Β
- AI-agent oversight βΒ someone has to notice when the machine wrote a technically valid test for something nobody cares about.Β
- Risk judgment βΒ knowing where the system can hurt you if it breaks, and putting effort there first.Β
That last one is the actual job. Not Playwright, not Selenium, not whichever framework is being declared dead this week. Judgment.Β
If the developer builds the car and the tester drives it looking for problems, the SDET builds the test track, wires up the sensors, automates the whole thing, and figures out which crashes are worth investigating. Increasingly, they're also supervising the robots driving the cars.Β
The test suite is softwareΒ
A test suite isn't a checklist you write once and abandon for three years. It's software βΒ with architecture, dependencies, technical debt, and its own maintenance needs. Which is why bolting an SDET onto the end of Design β Development β QA β Release doesn't fix much. The useful work starts earlier:
- Can I tell you a feature will be miserable to test before we spend six months building it?Β
- Can I influence the architecture so behavior is observable and testable?Β
- Can I decide whether something belongs in a unit, API, integration, or UI test?
- Can I look at a failing build and tell whether the product broke or the test infrastructure broke?Β
A modern SDET's footprint looks less like Build β Test β Pass/Fail β Release, and more like Design β Code β Test β Release β Operate. A design decision can make a feature hard to test. A code change can make the suite unreliable. A production metric can reveal a failure no test ever anticipated. And an AI-generated test can happily pass while checking something that doesn't matter.
If AI can write the tests, why do we need SDETs?Β
I'm not going to tell you that AI is coming for testers. I think the more interesting question is: who decides whether the test is any good?Β
An agent can generate a test from a requirement, write assertions, run thousands of cases, and tell you β with alarming confidence βΒ that everything's working. That doesn't mean it is. A test can pass technically and still miss the point entirely, and that's the part that doesn't automate away.Β
Someone still has to decide what's actually worth testing, what "correct" means, which risks matter, and whether the feedback we're getting can be trusted. Those aren't coding questions. They're judgment questions β and AI makes them more important, not less. If producing ten tests used to take an afternoon and an agent can now produce a hundred in minutes, the problem isn't too few tests anymore. It might be too many tests and not enough understanding.Β
The real reason you need an SDETΒ
I genuinely dislike hearing heavily loaded conversations about AI producing slopware (or whichever term of endearment we want to use), as if all pre-AI developersΒ produced bug-free, one-shot code that was flawless, because it tends to remove ownership from the discussion. Β
In my opinion, AI coding agentsΒ managed to fast forward bad practices just as much as theyΒ unlocked really good ones. The old commonΒ habit of copy-pasting from Stack Overflow got replaced with code generation devoid of context. Thatβs not really an authorship problem, though β you donβt need to have typed every line to own a decision. Thatβs true of any tool a developer has ever used. Itβs an accountability problem. It shows up the moment someone merges code they canβt explain and treats βAI generated itβ as the end of the conversation instead of the start of one. Β
However, both of those things simply confirm that producing software got cheaper. And, as software gets cheaper and easier to produce, the ability to decide whether it deserves to exist becomes the actual bottleneck.Β
The argument isn't that developers can't test, or that QA testers can't code. It's that quality has stopped being a phase of software development and become an engineering problem in its own right.Β
We may be entering a world where the limit isn't how fast we can build software, but how fast we can build confidence in it. That's what an SDET is really there to engineer. Not tests. Not frameworks. Not green pipelines.Β
Confidence.Β
The title's still a little clunky, and the role is still figuring itself out. But if AI keeps making software cheaper and faster to produce, someone still has to answer: "yeah, but does it actually work?"Β
That'sΒ the SDET's job. And I have a feeling we're going to be asking that question a lot more often.Β
1Β Layoffs.fyi - Tech and Startup Layoff Tracker
