Coding agents made the writing faster. The question I keep hitting is the one after the diff: does the app still work for a person? Momentic’s answer, in a post bylined to CEO Wei-Wei Wu and dated September 28, 2026, is an agent that bug-bashes the running product instead of handing you another suite to keep alive. The second sentence is “Now you don’t have to touch one ever again.”
The post, “Mo: A Future Without Tests”, says customers kept telling them two things: “I don’t want another script to write and maintain.” and “I’m paying double, both for QA and now a testing tool that we have to use.” Momentic’s framing of the older tools is blunt. Playwright, Selenium, and Cypress still leave an artifact the team owns, and they say fast-moving teams shipping thousands of pull requests a day can’t afford that overhead. That volume is their picture of those teams, not a measurement I checked.
What you hand Mo
The instruction on the post is short. “Give it a URL or a build of your mobile app, and tell it what to test.” You can also attach a PRD, a Linear ticket, or a Confluence doc when the agent needs more context. Then, in their words, “Mo launches hundreds of agents, works through the relevant user flows, explores thousands of permutations and edge cases, and records every interaction.” The thing they say you actually wanted is a bug report: “What was tested, what failed, reproduction steps, and video evidence of each one.”
A FAQ on the same page gets more specific about the swarm. “Hundreds on a single bug bash. Each agent gets its own hosted browser for web, or a simulator or emulator for a mobile build.” Wei-Wei Wu told SiliconANGLE the same day how he’d talk to it: “Bug bash this app I just built. Here’s the URL. Here are some test credentials. Go ham.” SiliconANGLE’s Kyt Dotson piece, published September 28, 2026, also carries the bet in Wu’s words:
What is the next frontier of agentic quality? Our bet is that there’s no tests in the future,
That first sentence is his, comma and all. The next sentence in the interview is separate: “It’s just agents verifying it themselves, based off of your instructions.” The line I want beside both is this one: “As long as you have scripts somewhere in your codebase, someone has to maintain it,”
A report with a second look
A swarm that files everything it dislikes is just a noisy inbox. Momentic’s FAQ describes a gate. “Every finding comes with a recording, repro steps, and Mo’s reasoning. A suspected bug goes to a separate reproducer agent first, and a bug it cannot reproduce stays out of the report.” That’s the part I’d actually test. A finding that cannot be replayed should not land on an engineer as a ticket.
Credentials are addressed in one FAQ sentence, which I am not treating as an audit: “Mo asks for credentials when needed, and they never leave the session.” What it needs, in the same answer, is “A URL or build our hosted browsers, emulators, and simulators can reach, plus a test account.”
The pull request, and the suite you can still keep
Mo can sit on the pull request, not only on a URL you paste. “With the Momentic GitHub App installed, Mo scopes a session to the change, posts the result as a comment, and reports a status check you can require before a merge.” A comment on the pull request also starts a scoped run. That’s a familiar gate. The agent doesn’t merge. A status check can block, and a person still reads the comment.
The no-suite line is not the whole FAQ. Asked “Do I ever have to write or maintain tests?” the answer is “No. There is no test suite. You give Mo an objective and read the report.” Asked whether you can keep the flows Mo tested, the answer is yes, as Momentic tests: “A flow Mo covered becomes plain-English steps in a YAML file in your repo. Your coding agent writes that file over our MCP server, and the CLI runs it in CI.” So the default pitch is a report. The escape hatch is a file in git, written by the coding agent you already have, run by their CLI. I like the hatch more than the slogan. If a flow matters every release, I want it in the repo. If it was a one-time bash, I don’t want to own it.
Wu put the same tension to SiliconANGLE in two beats. First: “The scripts are not the end goal,” The follow-up: “No one goes to work and is like, ‘Hey, I want to write 10,000 Momentic scripts or Playwright scripts or Selenium scripts.’ What they want is no bugs.”
What they count, and what I wouldn’t
The beta paragraph is Momentic’s own tally, not a study I can re-run. “For the past few weeks, engineering teams at Notion, Glide, Superpower and others have been putting Mo through its paces on their own apps. Across the beta: Mo ran 1,100+ bug bashes and caught 3,500 verified bugs.” SiliconANGLE’s report, which does not repeat those two figures, names a slightly different set: Notion, Superpower, Iris, Committee for Children, and Boundless. Glide is on Momentic’s post and not in that SiliconANGLE sentence. I’m not merging the lists into one roster, and I’m not reading “verified” as anything beyond Momentic’s word for bugs that made the report.
Pricing, from the same FAQ: “Sign up and you get $250 in Mo credits on us; after that, Mo runs on the same usage-based credits as the rest of Momentic.” They point at a pricing page for rates. I didn’t pull those rates into this post. “Mo is free to try” is the offer on the announcement, not a promise about what a bash costs on your app.
My takeaway
If coding agents are already opening the pull requests, the next design choice is who proves the build still behaves. Mo’s answer is a swarm with its own browsers, a second agent that has to reproduce a finding, and a comment plus a status check on the pull request. The report is the product. The YAML file is there if you decide a flow should survive the week. I would not quote 3,500 bugs, or “Your team does not have to do anything.” in a design review. I would point Mo at one staging URL I already trust a test account on, require the status check, and see whether the repro steps are something I’d still believe on Monday.
