The End of QA
Agents are erasing the line between writing software and testing it. Whether that works depends on one thing: how much of what testing reports is true. On mobile, that answer has to come from a physical device.
In 1989 Francis Fukuyama announced the end of history. He did not mean that events would stop. He meant that a long contest between rival systems had been settled, and that what came next would look more like administration than struggle.
QA has reached the same point. There will be more testing than ever. What's ending is QA as a separate discipline, with its own people, its own tools and its own slot in the schedule after development is "done." That arrangement existed because writing software and testing it took different skills, held by different people. Coding agents have both.
I run a company that tests mobile apps with robots, so I have a stake in this argument and you should weigh it accordingly. But the numbers are not mine. In JetBrains' 2026 survey of more than 15,000 professional developers, respondents said about 47% of the code they produce at work is fully generated by agents, and roughly one in five generate more than 80% of their code that way. Agentic coding is now how the mainstream of the profession works.
There's a catch. A software factory is only as fast as its test results are trustworthy. Feed it false positives and the speed disappears. On mobile, where the final test happens on a physical device, that is the hard problem left to solve.
From SDLC to ADLC
The software development lifecycle was built around human handoffs: product to engineering, engineering to QA, QA to release. Each one existed because no single person could hold all the skills or all the context.
The agentic development lifecycle, the ADLC, removes the handoffs. Inside what people have started calling software factories, agents plan the work, write the code, write the tests, run them, read the failures and fix what broke. The engineer's job moves up a level: set direction, manage the agents, review what they produce. One engineer oversees a swarm.
An agent has no career track. The same model that implements a feature writes its unit tests, its integration tests and its regression suite, in the same session and with the same competence. The skill gap that justified a separate QA function has closed.
Fewer testers, more testing
Demand for human QA will fall, and it will fall a long way. Writing test scripts, maintaining them, running manual passes and triaging the results is the bulk of QA labor today, and agents now do all of it.
By the end of 2027, I expect it to be over for most dedicated QA teams. I am not extrapolating from surveys. More than half of Mobot's clients have already reduced their QA staff, and more than a few have eliminated the function entirely.
Quality matters more than ever. Sonar's 2026 survey of more than 1,100 developers found that 96% do not fully trust AI-generated code to be functionally correct, yet only 48% always check it before committing. Code is being produced faster than anyone can verify it. Verification now sets the speed at which a factory can ship.
So the quality engineer who remains works the way the remaining developer does: at high leverage, directing many agents that do the testing instead of doing it by hand. A team of twenty testers may become two or three people who decide what must be tested, what counts as evidence and when the factory is allowed to release.
Who keeps a seat
QA professionals have a choice to make. Those who define themselves by execution, by writing cases, running passes and filing tickets, are doing work that agents are taking over. Those who move to directing and auditing agentic testing will be worth more than they are now.
The most valuable will be architects. Every software factory has to settle the tension between quality and throughput: how much testing, at which stage, with which tools, and what evidence is enough to release. Those choices used to be buried in team habit. Now they are explicit design decisions, written into the pipeline that agents run. Someone has to make them, and it should be someone who understands how software fails.
Where the agent's reach ends
On the web, an agent can close the loop by itself. It launches a browser, drives the product and sees what a user sees.
Mobile is different. Agents will own unit, integration and system testing here too, and most of today's mobile testing tools and roles will be absorbed along the way. But a mobile app ships to a physical object: a particular handset on a particular OS version, with a camera, radios, sensors, a battery and a sheet of glass. An agent can reason about that device. It cannot touch it.
That leaves one gap in the mobile ADLC: final validation on real devices before release. Everything upstream is software talking to software. The last step is where the software meets the hardware in your customer's hand, and it is where a miss costs the most, because the failure report arrives as a one-star review.
Everything in the shaded band is software testing software. The last mile is the only step that touches hardware, and its defect reports feed straight back to the coding agent.
The pitfall: false positives
There is one way this whole model fails.
A software factory runs on signal. When a test reports a defect, an agent picks it up, investigates, writes a fix and sends the build back through. That loop is where the throughput comes from, and it assumes the defect is real.
If the defect is not real, the loop runs anyway. The agent spends its effort chasing a bug that does not exist and may "fix" code that was working. The human overseer, who was supposed to manage by exception, gets pulled in to referee. Multiply that across hundreds of builds a day and both agents and people are buried in noise. Soon they stop trusting red results, and real defects ship alongside the ignored ones.
A human team could absorb a noisy test suite, because experienced testers learn which failures to wave through. A factory acts on what it is told, at volume. So the measure of any approach to final validation is how many of the defects it reports are real. A high false positive rate takes back the speed the ADLC was built to deliver.
The Last Mile Test
I judge any approach to final validation on three questions. Call it the Last Mile Test.
- Real. Does it exercise the actual device, through the glass, with live hardware, across every app the customer's journey touches?
- Rapid. Does it run at the factory's pace, without waiting on a person?
- Reliable. Are the defects it reports real?
Three approaches are on offer.
People. Manual testing still works, in the sense that a person can do anything a customer can. But a factory that produces builds continuously cannot wait on a human test pass. It is too slow and too expensive at that volume, and it returns too little: a verdict and a few sentences, when the agent upstream needs logs and exact steps to reproduce. People still have a place. At Mobot we keep human testers in the loop for exceptions and judgment calls. They cannot be the engine of a factory.
Device farms. Most teams today run scripted automation, through Appium or Maestro, across hosted devices. It has two problems. The first is flakiness. Bitrise's Mobile Insights report put the likelihood of hitting a flaky test at 26% in 2025, up from 10% in 2022. Flaky scripts are false positives at the source, fed straight into the factory. The second is a functional gap. Scripted automation operates the app through software hooks, not through the glass, and core hardware such as the camera, Bluetooth and NFC is typically simulated, injected or out of reach. The parts of an app most likely to break on a real device are the parts the farm cannot exercise.
Robots. The third answer is to give the agent hands. A robot operates a real device the way a person does, by touching the screen, and it does so on a machine's schedule with a machine's consistency. Nothing is instrumented inside the app and nothing about the hardware is simulated. Because each run is observed from outside the app and captured in screenshots from the device, the defect report carries evidence a coding agent can act on. And with no brittle scripts and no simulated hardware in the path, the two largest sources of false positives are gone. Across our testing fleet, repeat runs of the same test on the same build and device returned the same result over 98% of the time.
Consider a test that is already routine for the marketing teams at large retailers. A promotion runs on TikTok. A customer taps it, leaves TikTok, lands in the app store if the brand's app is not installed, installs it, and arrives through a deep link that has to carry the offer all the way into the cart. If the link drops the promotion anywhere along that path, the customer abandons the cart and the campaign spend is wasted.
That journey crosses several apps and the operating system itself. A scripted suite built around one app under test has no good way to follow it. A robot does what the customer does. As agents ship features and campaigns faster, flows like this will become the norm.
This is what Mobot does. The logic holds without me: if agents own everything upstream, the final check has to be as automated as they are and as real as the customer's phone. It also has to tell the truth. Only one of the three approaches passes all three parts of the test.
| Approach | Real | Rapid | Reliable |
|---|---|---|---|
| People | Yes | No | Varies by tester |
| Device farms | Partly | Yes | No |
| Robots | Yes | Yes | Yes |
The last tester
The end of QA is not the end of quality. It is the point where quality stops being a department and becomes a property of the factory.
Fukuyama's end of history came with a figure he called the last man. QA's version is the last tester: not the final person to hold the job, but the one who stops executing tests and starts governing them.
Next in this series
This is the first chapter in a series on how to architect agentic testing. Consider it the warning shot. The chapters that follow are the blueprint:
- The reference architecture. What the mobile testing stack looks like when agents own it, layer by layer, and what happens to the Appium and Maestro tier.
- The last mile, measured. People, device farms and robots compared on cost, speed, hardware coverage and false positives.
- Defect reports for machine readers. What a report has to contain when its first reader is a coding agent and not a person.
- The quality architect. The roles, team shape and metrics for governing quality against throughput in a software factory.
Subscribe to this newsletter on LinkedIn to get each chapter as it publishes. For the full chapters, with the data and frameworks behind them, sign up at mobot.io.
Charles Sword is the CEO of Mobot, which tests mobile apps on real devices using robots.
Sources
- How Much Code Do Developers Really Let Agents Write?, JetBrains Research, August 2026
- The AI trust gap: Why code verification matters, Sonar, State of Code Developer Survey 2026
- Why flaky tests are increasing, and what you can do about it, SD Times, citing the Bitrise Mobile Insights report