QApilot's CoWork

3x Mobile Automation. Same QE Team.

Developer Tools

Artificial Intelligence

Visit WebsiteSee on Product HuntTwitter ⧉LinkedIn ⧉

Charan, the honest-fail and intent-anchoring already won me over (saw your answer to David), so let me push on the part that decides whether this scales: the human approval itself.

A single replan-with-approval is clearly the right call. But a regression suite is hundreds of tests, and a UI change rarely hits just one, a renamed "Checkout" button can ripple across 40 flows. So my real question: when a human approves a replan once, does that decision propagate, does CoWork remember it for the rest of the run and the next one, or does the same change get re-surfaced 40 times? If every approval is a one-off, the human control that makes it trustworthy quietly becomes the bottleneck that kills the 3x. The magic version is one approval teaching the whole suite.

Put simply: does an approved replan become a durable update to the test, or just a per-run decision? That's the line between "AI with a human checkpoint" and "a human clicking approve 200 times."

Congrats on the launch, genuinely strong positioning :)

The thing that kills most AI test-gen tools in practice is maintenance: the agent writes a suite, the UI changes next sprint, and now you're drowning in false failures. Does CoWork self-heal selectors when the DOM shifts, and can it tell a real regression from a benign markup change? That signal-to-noise ratio is what decides whether teams keep the suite or quietly delete it.

mobile QA is so underserved, 3x is a bold claim 👀 which platform u nail first?

This feels especially useful for teams that already have test cases written down, but still end up doing too much manual release checking because automation takes too long to maintain.

The human-approved replanning part is the most important detail to me. For QA, I’d rather have the system pause and ask when something changes than confidently fake its way through a broken flow :)

Curious how CoWork handles UI changes over time. does it learn from approved replans so the same changed label or popup does not need approval every time?

real device testing is the part everyone skips and then regrets. nice to see the human approval step for unexpected states, that's usually where automation quietly lies to you. congrats on the launch.

The human-approved replanning part feels like the important bit. I’ve seen mobile test agents get scary when they quietly guess through OTPs or changed labels. Curious if teams can set different approval rules for smoke tests vs release-blocking flows?

When scale testing mobile applications, how does CoWork handle deep state synchronization or state flakiness across parallel test instances? Is it actively maintaining a synchronized virtual state tree across the instances, or relying on aggressive DOM/view re-verification loops to prevent false negatives?

The replanning loop is what gets me here — most AI test tools fail silently when the UI changes, and you end up with flaky tests nobody trusts. Human-approved replanning before re-execution is the right call.

Curious how CoWork handles cases where the AI's planned steps diverge significantly from the original test intent — does the human reviewer see a diff of the original vs proposed plan, or just the new steps in isolation?

Congrats on the launch 🚀

It’s a great idea. I apologize for my limited understanding. Considering the increasing cost-effectiveness and reliability of code production, why should we rely on agentic testing? I understand that specifications can fail due to changes like button renames, but (at least in our suite), it’s expected that tests will fail, and specifications need to be updated accordingly. Wouldn’t it be more efficient to use deterministic testing combined with a non-deterministic report generator?

The replanning-on-UI-change part is the real claim here - most mobile suites die exactly when a label moves or an unexpected popup shows up, so an agent that recovers is genuinely useful. When CoWork replans around a changed label, does it persist the adapted step back into the BDD/Gherkin definition so the next run is deterministic, or does it re-infer the path every run (which would make pass/fail non-reproducible across CI runs)? And does execution happen on a hosted device farm or on my own connected devices - that matters for builds behind auth or internal-only distribution.

Mobile QA is a strong place for automation because the bottleneck is rarely one test; it is the repeated device, environment, and regression coverage that slows teams down.

The “same QE team, 3x automation” positioning is interesting. I’d be curious how QApilot handles flaky tests and app-state changes, because reliability is usually what determines whether QA teams trust automation or keep falling back to manual checks.

@charan_tej_kammara The “fails honestly instead of faking a pass” part is the strongest detail for me. In QA, a test that silently adapts in the wrong direction can be more dangerous than a broken test. Human-approved replanning around the original test intent feels like the right balance between speed and trust.

Reusing existing BDD test cases instead of asking teams to rewrite everything feels like a smart adoption strategy. Has that been the biggest driver of customer interest so far?

How would this compare to doing UI automation testing with a tool like Selenium or CypressJS

No matter how many tools exist in this market, we need more to solve a mountain of a problem i.e. mobile app testing. Thanks to CoWork for enabling the solution. I wish many more adopt this tool.

Congrats on the launch! 🚀

I like the human-approved replanning approach. Mobile automation often breaks on small UI changes, popups, so having AI adapt while still asking for approval feels like the right balance.

Curious how CoWork handles flaky test behavior across different real devices and OS versions.