Some engineering work is easy to describe precisely: Write a PDF parser or implement IMAP correctly. Write a compiler against a defined language spec. The work may still be hard, but the target is clear enough that a machine can keep trying, checking, and improving.
Author: Andrian Budantsov, Founder and CEO, Hypersequent
Testing has the same kind of tasks: Test this parser against broken inputs. Check whether an API really follows its contract. Make sure a refactor did not change the output for the same data. When the expected behavior is clear and the team can tell right from wrong, AI agents are already very good at this kind of grind. They generate and run cases, then inspect failures. They revise their approach, and keep going.
Developers now often describe that pattern as a Ralph loop, after the character Ralph Wiggum in The Simpsons. Run the agent and let it change the code or test suite. Then check the result and start again with a fresh session until the job is done. For work with a clear target and fast feedback, this loop is productive.
Manual testing stays relevant because much of software quality does not look like parser work.
Where agent loops already work well
Agent-driven testing is strongest when the team can clearly state what they are trying to prove, and how they will know if it works. If the behavior is clear, the system is stable enough to learn from each attempt, and the feedback comes back quickly, agents can do a lot of useful work.
That covers more testing work than many teams assume. Parser and protocol testing are obvious examples. So are API contract tests, import and export validation, migration checks, and the kinds of data checks where the team mainly wants to know whether the software keeps behaving the way it is supposed to across multiple use cases.
That is why AI-assisted testing feels so convincing in lower-level systems and around system boundaries. The loop has a clear basis for each iteration. Failures are easier to read and progress is easier to measure. With every round, coverage can be tightened up.
Where the loop starts to drift
The trouble starts when the important question is no longer about correctness alone.
A product flow can satisfy its written requirements and still be confusing. A payment failure screen can technically work and still leave the user unsure what to do next. A support assistant can follow policy and still make the user feel trapped. These problems are harder to fit into a tight automated loop because the standard is less formal.
Agents, in principle, can get better at this. There is nothing magical about a human tester opening a product, reading a spec, looking at screenshots or session recordings, and deciding whether the common scenarios are covered. A strong enough system could take in the same material and approximate that judgment, and some teams are already experimenting with parts of this approach.
The workflow is still fragile, though. It is easy to pick the wrong scenarios or to confuse variety with relevance. This means that the loop keeps moving while drifting away from what the team actually cares about.
At that point, a human becomes more than a fallback. The human is the control layer.
What the human control layer actually does
Calling manual testing a control layer is more precise than saying that humans still matter. The job is to decide whether the loop is heading in the right direction, not to click around randomly after the automation finishes.
In practice, that means choosing which user journeys and risks deserve attention and checking whether generated scenarios look like real usage instead of made-up variation. It means looking at outcomes that need judgment rather than a simple pass or fail, and redirecting the loop when the agent is optimizing for the wrong thing.
The contrast is easier to see in two very different assignments. ‘Build automated checks for this IMAP implementation and keep iterating until the protocol tests pass’ is excellent agent work. The problem is structured and the team can tell whether progress is real.
‘Check whether first-time users can recover from a failed identity verification flow on mobile without losing trust in the product’ is different. Parts of that can be automated. An agent can try different device states and generate test ideas. It can inspect screenshots and exercise retries. It will flag inconsistencies. But a person still needs to look at the interaction and decide whether it makes sense. The real question is not only whether the code did what it was told, but whether the product handled a human situation well.
Sometimes the gap is technical. Current agents are not yet reliable enough to take in all the relevant signals and make a stable judgment. Sometimes the gap is intentional. The organization may simply want a person, not a model, to make the final call on elements such as clarity, trust, fairness, safety, or brand risk.
Manual testing changes shape, not value
The old manual-versus-automation framing has become less useful.
The repetitive part of manual testing will keep shrinking where the work can be formalized. Teams should want that. If an agent can spend the night generating parser edge cases or extending regression coverage around a data import flow, there is little value in assigning the same task to a person.
The remaining human work is more consequential. Aspects like direction, coverage relevance, and interpretation matter more than raw execution volume. Manual testing is about assessing whether the system is learning the right lessons.
Strong manual testers are likely to become more valuable over time. A fast loop with the wrong objective produces false confidence faster, and someone has to see that early.
A workable operating model
For the next few years, the most practical model is a supervised loop.
Teams can formalize the parts of the problem that really can be formalized and let agents iterate aggressively on bounded work with clear exit conditions. They can insert human review where scenario choice or outcome meaning becomes ambiguous, then feed those findings back into the next loop as better prompts and constraints.
Over time, some work will move from the human side to the autonomous side. A few years from now, agents will be better at reading product specs and session recordings. They’ll also improve their understanding of accessibility signals and visual flows. The range of testing tasks that can run in a loop without much supervision will expand as a consequence.
Even then, there will still be places where teams want human judgment because the question goes beyond whether the system behaved consistently. It’s about whether the behavior makes sense. That is how much testing is likely to work in the coming years: Agents doing more of the systematic work where the assignment can be described formally and checked repeatedly, with humans staying in the loop where the work is complex or the organization wants explicit human judgment before trusting the result.
Seen that way, manual testing is more than merely the work that test automation cannot handle. It is the control layer that keeps AI-assisted testing attached to product reality. It decides whether the loop should continue or change direction. And the teams that use it well will judge manual testing by whether those human checkpoints improve the quality of the loop.
About the Author
Andrian Budantsov is the CEO of Hypersequent and the creator of QA Sphere. With over two decades in software development, Andrian established a domain registration business before co-founding Readdle in 2007, serving as CTO until 2022. During his tenure, Readdle’s apps like Spark Mail garnered over 200m downloads and numerous awards. He was also CTO for Fluix, Readdle’s B2B division. In 2023, Andrian formed Hypersequent, developing advanced software testing tools with a commitment to quality, team building, and market-driven product development.
Leave a Reply