AI coding tools have made it possible for teams to produce features much faster than before. Testing, however, has not automatically kept pace. In a post on DEV Community written in Vietnamese, developer Dang Nguyen describes how he closed that gap on a Flutter project: he had Claude and the Maestro testing framework build and run a regression suite for the app, much of it overnight and on weekends while he slept. His story is short and candid, and it raises useful questions for any team shipping AI-assisted code.
The problem: QA becomes the bottleneck
Nguyen first encountered Maestro at a previous job at a Vietnamese e-wallet company, where a team lead showed him how to write end-to-end tests for mobile apps. He liked it immediately: easy setup, easy element inspection and test flows far simpler than the tools QA was using at the time. In that role, though, he rarely touched tests. Developers built features and passed them to QA.
Later he moved to an outsourcing company where, in his words, almost everything was done with AI: requirements, task breakdowns, schedules and implementation. He switched from React Native to Flutter for a new project and found that the programming language mattered less than knowing how to prompt well. Code was being produced at high speed. The part of the process that could not keep up was testing. Every time a new feature or release phase was ready, the QA team had to run a full regression pass to make sure the fast-moving changes had not broken something elsewhere.
The idea: let agents write the automation too
Nguyen's solution was to turn the same AI tooling toward testing. If an automated suite could handle regression, QA could focus on new features instead of rechecking old ones.
Maestro made this practical. It is an open-source UI testing framework for Android, iOS and web apps that describes user journeys as readable YAML flows. It ships with a command-line tool and a built-in Model Context Protocol server, started with the maestro mcp command, which lets AI coding agents such as Claude Code list devices, inspect what is on screen, write flows and run them. Maestro's own documentation describes the loop: the agent explores the app on an emulator or simulator, saves working steps as a flow, and the same flow can later run on its own with maestro test, including in CI.
Nguyen pointed his agents at the test cases the QA team had already written. For each case, the agent explored the Flutter source code to understand the relevant screens, wrote a Maestro flow for that scenario, and added missing test identifiers to widgets wherever the flow needed something stable to target. The goal he set was simple: keep going until every test case in the file had a working flow.
What it took
He is honest that it was not quick. It took about a month, using spare token allowance on weekends to let the agents explore and test. Along the way the agents built what he calls a UI_MAP for each feature, essentially a map of screens and elements that later runs could reuse. Once that was done, the team gained a reusable regression skill: after building a feature, developers run the suite, see what fails and fix it. He also had the agents check performance during test runs by reading logs and monitoring output.
His conclusion is deliberately provocative. Since the regression suite verifies behavior, he says he no longer worries much about how the AI-generated code looks, as long as features work and performance is acceptable. He does draw a line at security and environment configuration, which he says still need human review because a machine cannot easily guarantee them.
Why this matters
The underlying idea is sound and increasingly common: if AI speeds up code production, verification has to be automated too, or quality assurance becomes the limiting factor. End-to-end tests that exercise real user journeys are a good fit because they check behavior regardless of who wrote the code. Using agents to translate existing manual test cases into automated flows also addresses one of the biggest reasons teams never build UI automation in the first place: the upfront effort.
The trade-offs to consider
It is worth being more cautious than the original post on a few points.
First, passing tests are not the same as good code. A regression suite only checks what it covers. Maintainability, readability and hidden complexity still affect how quickly a team can change the product later, and code nobody understands becomes expensive when something breaks outside the tested paths.
Second, AI-written tests need review. An agent that writes both the flow and the test identifiers could produce tests that pass for the wrong reasons, or that assert too little. Someone should confirm that each flow really checks what the original test case intended.
Third, security reaches further than secrets and environment files. Authentication, authorization, data handling and dependency choices all deserve human attention, and functional UI tests will rarely catch problems there.
Finally, cost and time are real. A month of agent runs and tokens is a meaningful investment, and UI suites need ongoing maintenance as screens change.
Practical takeaways for teams
If AI is accelerating your development, plan for automated verification at the same time, not after QA is overloaded.
Start from the manual test cases your QA team already has; they are an excellent specification for agents.
Add stable test identifiers to widgets and screens; they make UI automation far more reliable, whether written by people or agents.
Keep generated flows in the repository and run them in CI so they become part of the normal workflow rather than a side project.
Review a sample of AI-written tests regularly to make sure they assert meaningful behavior.
Keep humans responsible for code review in sensitive areas such as security, payments and data privacy.
Nguyen admits the idea is not new and shares it so other app and web developers can try it. At Softgene Tech we agree with the core message: test automation is one of the most valuable places to point AI agents, as long as the team stays in charge of what good looks like.
Source: Dang Nguyen, DEV Community (original post in Vietnamese), original article linked below.
