When to hire a QA engineer (and when an agent is enough)
A decision framework for when to hire a QA engineer versus when an AI agent covers the job. The honest signals — by team size, PMF, and risk — for hiring now, waiting, or never hiring at all.
When to hire a QA engineer (and when an agent is enough)
Most people ask "when should I hire a QA engineer" as a budget question — at what headcount or revenue does a QA salary become affordable. That's the wrong question, and it leads to two equally expensive mistakes: hiring one two years too early because a board member said you should, or refusing to hire one three years too late while your best engineer quietly becomes a full-time firefighter.
The right question is: what part of the QA job do you actually have a shortage of right now? Because "QA engineer" isn't one job, and the pieces of it come due at completely different times. Some of them an agent covers for a hundred dollars a month. Some of them a human has to own, and no tool is going to change that. If you can tell which piece you're short on, the hiring decision answers itself.
I sell an AI QA product, so read me as an interested party — the honest version of my pitch, though, is not "never hire QA." It's "hire QA for the thing you actually can't automate, and stop paying a salary for the thing you can." Here's the framework I'd give a founder who asked me over coffee.
Why the "at what size do I hire QA" framing fails
The headcount rule of thumb — "hire your first QA around 15–20 engineers" — is a fossil from a world where testing meant a person clicking through flows and another person maintaining Selenium scripts. In that world, QA labor scaled with product surface area, so you hired when the surface got big enough. Fair enough, for 2015.
It fails now because the execution half of QA has gotten cheap in a way the judgment half hasn't. Running the regression pass, filing the bug with repro steps, re-running it on every deploy, noticing the console error nobody asked about — that used to be a person's week, and now an agent does a real chunk of it. I wrote the honest line-by-line of exactly which parts get covered in what an AI QA engineer actually replaces; the summary is that the labor of testing is largely automatable and the responsibility for quality is not. So a headcount trigger that treats QA as one indivisible hire will always be wrong. You'll over-hire (paying six figures for execution you could've automated) or under-hire (automating execution while the judgment gap silently widens).
So throw out "at what size." Ask instead: which of these three shortages is the one that hurts?
The three jobs hiding inside "QA engineer"
You can't decide when to hire until you know what you'd be hiring for. The title covers at least three roles that barely overlap day to day, and the U.S. Bureau of Labor Statistics lumps them under one occupation code even though they're different jobs.
The manual tester runs flows by hand, follows checklists, files bugs, and does the exploratory poking that finds the weird stuff. The job is attention and repetition. The automation engineer writes and maintains scripted E2E suites so the repetitive checks run without a human — and the hidden cost there was never writing the test, it was maintaining it as the product changed. The SDET builds the testing infrastructure itself: CI gates, ephemeral environments, test-data systems, the platform other engineers test against. The job is systems.
An agent aims squarely at the first two and barely touches the third. That single fact reorganizes the whole hiring question. If your shortage is manual-tester execution or automation-maintenance, you may not need a hire at all — that's the case for an agent, and it's a strong one. If your shortage is SDET systems work, or the judgment that sits above all three roles, a tool won't fill it and you should hire. Most "should I hire QA" agonizing is really a failure to notice which of these three is actually short.
The signals that mean "hire now"
Forget the size threshold. Here are the concrete signals that you genuinely need a human in the QA seat — not more execution, but the thing execution can't provide.
Your best engineer has become the QA team by accident. The clearest signal, and the most commonly missed, because it doesn't show up as a line item. If one of your strong engineers now spends a meaningful slice of every week manually verifying releases, triaging what broke, and deciding what's shippable, you already have a QA hire — you're just paying senior-engineer rates for it and getting a demoralized senior engineer in return. The cost isn't the person's time; it's the features they're not building and the flight risk you're carrying. When quality work has silently eaten a real fraction of your most expensive person, hire.
Someone has to own the test strategy, not just run the tests. There's a difference between "run these eight flows before every deploy" and "decide which eight flows matter for a feature that didn't exist last week." The second is judgment, and it compounds: as the product grows, the question of what's worth testing and how much becomes a real job. An agent executes a test plan beautifully; it does not author the strategy behind it. When authoring the strategy is itself more than a few hours a week, that's a person.
You need a versioned, auditable suite for compliance. If you're heading into SOC 2, HIPAA, a security review, or an enterprise procurement that wants to see your testing posture, "we describe flows to an agent and read the sessions" is a real testing practice but it isn't the code-reviewed, version-controlled artifact an auditor expects to point at. Someone has to own that suite as an asset. That's automation-engineer or SDET work, and it's a hire (or a managed service — more below).
Your testing infrastructure is now its own product. Forty engineers across a dozen services, each needing isolated environments, seeded data, and CI gates that don't flake — that's a platform, and platforms need an owner. No agent builds your CI; it runs inside the CI someone built. When the infrastructure around testing has become a full-time systems problem, hire the SDET. This is the one an AI QA tool most cleanly does not replace.
Severity calls are getting made by whoever's loudest. "Is this a launch blocker or a known issue we ship anyway" is a business judgment about users, revenue, and risk. If those calls are currently made ad hoc in Slack by whoever cares most that day, you have a judgment vacuum, and a good QA lead fills it. That's not a tooling gap.
Notice what these have in common: every one is about ownership and judgment, not throughput. That's the tell. When the shortage is "nobody owns this decision," hire a person. Tools don't own decisions.
The signals that mean "an agent is enough for now"
The mirror image. These are the situations where hiring is the expensive mistake, because what you're short on is execution, and execution is the part that automates.
You have no QA at all and the alternative is nothing. The most common case for a seed-stage team, and the easiest call in this entire post. If the real choice is "an agent runs your core flows before each deploy" versus "you find out it's broken from a customer," the agent isn't competing with a human — it's competing with nothing, and it wins going away. You get a tester's execution at software prices, and the judgment gap is filled by the founder or lead who was making those calls anyway. That's literally the position the phrase "the AI QA engineer you didn't have to hire" is describing.
Your UI changes every week and a scripted suite would rot faster than you could maintain it. Pre-PMF, the product is a moving target. A human writing Playwright would spend most of their time repairing selectors that sheared off in the last redesign — I've argued the strong form of this in the case against writing your own Playwright tests. An agent that works from intent instead of pinned selectors doesn't carry that maintenance tax. Hiring an automation engineer to babysit a suite through weekly redesigns is paying a salary to fight entropy you could just… not create.
The bugs you're shipping are execution misses, not strategy misses. Be honest about what's actually getting past you. If the escapes are "the signup form accepted an empty email," "checkout 500'd on a double-click," "the dashboard threw a console error on load" — those are coverage-and-repetition failures, exactly what an agent catches, and exactly what scripts miss because nobody wrote that assertion. If instead your escapes are "we tested the wrong thing entirely because nobody understood the feature," that's a judgment miss and a tool won't fix it. Diagnose which kind you're shipping before you diagnose the headcount.
You'd be hiring to signal maturity, not to fill a shortage. "Real companies have QA" is not a reason. If you can't name the specific job the person would own that isn't already covered, you're hiring a title, and you'll end up with a smart person underutilized into either boredom or a made-up mandate. Wait until the shortage is real and nameable.
Staged by where you actually are
The framework changes shape depending on your stage, so here's the honest version for each.
Pre-product-market-fit (roughly 2–8 engineers). Almost never hire QA here. The product is changing too fast for a maintained suite to hold its value, and you don't yet know which flows matter because you don't yet know which features survive. What you need is a habit: an agent running your two or three highest-stakes flows before each deploy so you stop shipping obvious breakage, plus a written checklist for the one flow that would be catastrophic to break. Cost is roughly a hundred dollars a month and an afternoon of setup, which is the whole point — the full QA-cost breakdown shows why every human option at this stage is mispriced for you. Hiring QA pre-PMF is optimizing a system you're about to rewrite.
Post-PMF, still small (roughly 8–25 engineers). The gray zone, and where most bad hires happen. You have real users, real revenue, and real regression risk, but not yet a testing-platform problem. The move here is usually not a full QA hire — it's an agent for the broad execution surface plus one clear owner of test strategy, and that owner is very often an existing engineer or lead given an explicit mandate, not a new headcount. If you do hire, hire for judgment (a QA lead who sets strategy and owns severity), not for hands (a manual tester whose job an agent does). The mistake at this stage is reading a vendor's "replaces a QA engineer" copy literally and either laying off judgment to save on execution, or hiring execution you didn't need.
Scaling (roughly 25–75 engineers). Now the SDET signal starts firing. Multiple teams, multiple services, CI that needs to stay green across all of it — that's systems work with an owner. Hire the SDET or platform-QA person for the infrastructure, and keep the agent as an execution layer inside it: fast coverage of new flows, in-CI regression checks, running alongside whatever scripted suites the critical paths warrant. This is a "both," not an "either." Anyone selling you "fire your QA department, our agent does it all" at this stage is selling a fantasy, and your best engineers know it.
Compliance or enterprise-sales pressure, at any size. This one jumps the queue. The moment an auditor or an enterprise buyer wants to see a versioned, owned test suite, you need someone accountable for it — a hire or a managed service that produces committed code. An agent's session reports are real evidence of testing, but they aren't the artifact these processes are built to inspect. Don't discover this two weeks before the security review.
The two mistakes, named
Every wrong QA-hiring decision I've watched is one of these.
Hiring execution and calling it judgment. You feel the pain of shipping bugs, you hire a manual tester or a junior automation engineer, and for a quarter it helps because a fresh pair of hands is running things. Then you've institutionalized a salary for work an agent does at a thousandth of the cost, and the actual judgment gap — nobody owning strategy or severity — is still open, now with a headcount masking it. You solved the cheap problem and left the expensive one.
Refusing to hire judgment because "the agent's got it." The inverse, and the one my own industry encourages. You lean on an agent for execution — correctly — and then use that as a reason to avoid ever hiring the QA lead you now genuinely need to own strategy, severity, and the compliance suite. The agent is a real execution layer with no judgment layer of its own; pretending it has one is how you end up with excellent coverage of the wrong things. When the signals in the "hire now" section fire, hire, and let the agent keep doing the execution it was already doing.
The framework is symmetric on purpose: automate the execution, hire the judgment, and never confuse the two in either direction.
What the "not yet" path actually looks like
If you land on "an agent is enough for now" — which most teams under twenty engineers honestly should — the path isn't "buy a tool and hope." It's a deliberate practice you can stand up in an afternoon and hand off without owning any code. Describe your highest-stakes flows as reusable Test Scenarios, run them before every deploy, and read the session each produces — screenshots, network, console, a reasoned verdict. When you eventually do hire a QA lead, you hand them a running practice and a history of what's been tested, not a blank page. The agent doesn't compete with that future hire; it makes their first month about strategy instead of catch-up.
And when you're weighing specific tools for that path, weigh them honestly against how much you want to own. Some, like Autonoma, integrate deep into your repo and generate a maintained suite; Monito's bet is the opposite — describe and run, nothing to wire. Either can be the "not yet a hire" answer; which fits depends on whether you want a platform or a prompt.
Pressure-test your own answer on your real app
The fastest way to know which side of the line you're on is to watch an agent run your actual flows and see how much of your current QA pain it absorbs — and how much it leaves for a human. Point this at your staging URL in a Test Scenario and read the session closely:
That last line is the whole framework compressed into an instruction: the agent surfaces, you decide. A full run is typically 8–13 credits — $0.08 to $0.13 — and your first run is free. Run it, then ask the question that actually settles the hire: of everything it found, how much would I have needed a person to catch — and of everything it couldn't decide, how much do I still need someone to own? The size of that second pile is your answer. Small, and you're not hiring yet. Large, and you know exactly the job you're hiring for — which means you'll hire the right person instead of a title.