Why cutting QA right now is backwards
Insights from the field: a conversation with Lucas Smit, AI Forward SDET
Over the past few months, I’ve been hearing the same patterns across the QA market: layoffs, impossible reqs, and a growing belief that “we don’t need testers anymore.”
Then an automation engineer said something that reframed all of it:
“The amount of PRs on my team is at least three times more than it was six months ago. Creating software became cheaper and fast, so the validation bottleneck became more important.”
Before AI, building software was the bottleneck. Now it’s validation. And most of what’s broken in the QA hiring market traces back to leadership not adjusting to that shift. Then an automation engineer I spoke with put it in a way I couldn’t unsee:
Why merging Dev and QA breaks under AI pressure
A trend I’ve seen: companies cutting QA and pushing testing onto developers.
So I asked Lucas about it, and he was direct:
“If companies are cutting QA headcount, I think they’re making a mistake. Developers don’t have the mindset that QAs do for testing. They don’t think in terms of states: it’s a completely different way of thinking.”
AI is accelerating code output. Developers are shipping more, faster, and not thinking through every edge case. Someone has to.
That workload isn’t shrinking. It’s multiplying.
My two-cents: If you’re sizing QA teams based on pre-2024 ratios, you’re already behind. The companies that adjust will ship faster and break less. The ones that don’t will pay for it in production.
Playwright isn’t the filter you think it is
The most common candidate complaint I hear as of late:
“I’m getting rejected because I don’t have Playwright, even though I have Selenium or Cypress.”
Lucas’s take:
“Automation knowledge is tool-agnostic. If you have Cypress or Selenium, you can easily move into Playwright.”
He moved across three frameworks in ~2 years. That’s normal.
What many recruiters miss: Playwright is often easier than older tools. It handles waits, retries, and timing issues out of the box.
A strong Selenium engineer doesn’t need months: they need weeks.
Screen for fundamentals. Not tools.
A recruiter’s cheat sheet for automation candidates
If you’re non-technical, start here:
“How would you structure a test automation suite from scratch?”
Then listen and dig:
1. Flaky tests
- 🚩 “I add waitFor(5000)”
- ✅ Wait for API completion, DOM state, proper async handling
2. Parallel execution
- Look for: sharding
3. Shared state
- Look for: fixtures (especially in Playwright)
You don’t need to be extremely technical: nail down questions with the engineering team and just listen to how the candidate thinks.
If they nail 2–3 of these, they’re worth advancing.
If you’re a manual tester, you have two doors
Manual testers have been hit hardest and most advice I’ve seen out there isn’t helpful.
Lucas framed it simply:
Door 1: Learn automation (now)
Automation is no longer a differentiator, it’s the baseline.
The upside: you already have the QA mindset.
Door 2: Learn to build AI agents (without coding)
You can start creating useful internal tools.
“If you can write clear instructions in a markdown file, that’s what you need to build an agent.”
Example: build an agent that runs exploratory or monkey testing inside tools like Claude Code or Copilot.
That work, structuring context, defining behavior, building usable outputs, is a new skillset.
A third path: testing AI itself
If you go deeper on AI, you land somewhere even more interesting:
- LLM evaluation
- prompt validation
- hallucination and bias testing
- red-teaming
Lucas mentioned a case where someone landed an LLM Evaluation role without traditional QA experience.
These roles are quickly becoming some of the most in-demand, and least saturated in the market.
What hiring managers should fix in their reqs
Right now, many job descriptions ask for:
- full automation frameworks
- AI agent development
- LLM evaluation
- CI/CD ownership
- performance + security testing
…all in one role.
“You’re not going to find a candidate like that.”
Instead:
- Separate must-haves vs nice-to-haves
- Decide if the role is automation OR AI-focused (they’re different)
- Hire for the actual bottleneck
The bottom line
From where I’m standing, AI didn’t shrink QA. It expanded it.
Software is being created faster than ever and someone still has to validate it.
That role is now more important, not less.
- Candidates: fundamentals + automation + a POV on AI is the new baseline
- Recruiters: stop filtering on tools, screen for thinking
- Hiring managers: the bottleneck moved. Build around it
The teams that recognize this early will move faster, with fewer mistakes.
The rest will spend the next two years cleaning up preventable ones.
Thanks to Lucas Smit for sharing his perspective.
If you’re seeing similar patterns or different ones drop them in the Inside Peak community. I would love to hear other perspectives!
– Jaclyn