QApilot's CoWork - 3x Mobile Automation. Same QE Team.
by•
CoWork turns existing test cases into executable mobile automation with AI planning, human-approved replanning, and real-device execution on iOS, Android, and Flutter.
Every QA team knows what they want to test. "Log in, add an item to the cart, check the order confirmation." Saying it takes ten seconds. Then the team spends six months turning that sentence into something a machine will run: step definitions, selectors, automation glue, flaky scripts that break on every UI change.
The intent was never the hard part. The execution layer was the tax.
CoWork takes your existing natural-language or BDD test cases, converts them into structured BDD/Gherkin context, builds an execution plan, and runs the test on a real mobile device.
When the app behaves differently, like a changed label, unexpected popup, or interrupted flow, CoWork replans and asks for human approval before moving ahead. When it needs input, like an OTP, it pauses instead of guessing. If it can’t proceed, it fails honestly instead of faking a pass.
Who it’s for: QA leaders, SDETs, mobile engineering teams, and product teams with existing test cases but low execution coverage before releases.
Common use cases: Regression testing, Release readiness, checkout/login flows, OTP-heavy journeys, app flows that break often, and teams trying to reduce manual execution without rewriting everything from scratch.
What makes CoWork different is the balance: AI execution where it can move fast, human control where judgment matters.
@charan_tej_kammara The "fails honestly instead of faking a pass" line is underrated. Most automation lies to you when the UI shifts under it, and a test that drifts and silently passes is worse than no test. When CoWork hits a screen that no longer matches the plan, does the human-approved replanning re-anchor to the intent of the step or to the old UI path? That distinction is what separates flaky from durable.
@david_marko - Exactly. We anchor to the intent of the step, not the old UI path.
The old path is useful context, but it shouldn’t become the source of truth. If the screen changes but the intent is still clear, CoWork replans against the current app state. If the new path could change what the test is actually validating, it asks for approval instead of silently continuing.
That’s the line we care about most: adapt to harmless UI change, but don’t let the test drift into validating something else.
Report
@charan_tej_kammara The honest-fail behavior is a smart choice. In mobile QA, a blocked test is annoying, but a fake pass is much worse because it creates confidence right when the team should slow down.
Curious how CoWork handles apps with heavy feature flags or UI states that change by user type?
@habibferdous - Thanks, Habib. Completely agree, a fake pass is far more dangerous than a blocked test.
For feature flags and user-type based UI states, we treat them as part of the execution context rather than noise. CoWork runs against the app state it sees, uses the given test intent and user context to decide the next step, and replans only within that boundary.
If the UI variant still supports the same journey, it can continue. If the flag or user state changes the intended behavior, it asks or fails honestly instead of forcing the test through.
I'm one of the makers behind CoWork, and I'm really excited to finally share what we've been building!
CoWork helps AI and humans work together to make test automation more reliable instead of chasing full automation. We'd really appreciate your support on Product Hunt today, and I'd love to hear what you think. Thanks for checking us out!
Hey all ,
Excited for the launch today I am part of the team that built cowork . Would love to hear your thoughts on this .
I would be on the threads all day reading and replying to your thoughts .
Hey folks! I’m one of the makers behind CoWork.
CoWork came out of a simple frustration: test cases are everywhere, AI is powerful but not always reliable, and humans end up double-checking everything anyway. So we thought - why not design a system where AI and humans actually CoWork (properly)?
Here’s what we built:
1. Ingest test cases from wherever you maintain them (yes, the messy reality)
2. Use AI to generate and execute, but intelligently decide when humans should step in
3. Minimize verification effort instead of pretending it doesn’t exist
We didn’t want to go all-in on rigid rules or blindly trust LLMs - CoWork is our attempt at a hybrid system that picks the right strategy at the right time.
If this sparks curiosity (or skepticism), come talk to us.
What feels useful? What feels unnecessary? Where would you not trust this yet?
Tell us where this would break in your world, and we’ll happily show you how we’re thinking about it.
Let’s CoWork on making this actually useful, not just “AI-sounding.”
We built CoWork - an AI agent that drives real mobile apps step by step, planning each action, reading the screen, and adapting when things go off-script.
We kept hitting the same wall: mobile automation breaks the moment a layout shifts. So we wanted something that actually sees and reasons about the screen instead of leaning on brittle scripts.
We'd love your feedback and support. Drop your thoughts/questions in the comments below and one of us will reply!
Report
@vidushee_geetam The idea makes sense technically, but I’m interested in the operational impact.
If a team already has a mature manual regression process, what changes after six months of using CoWork? Is the biggest improvement shorter release cycles, higher regression coverage, fewer flaky tests, or simply less engineering time spent maintaining automation?
I’d be interested to know which metric your existing customers see improve first because that’s ultimately what teams will justify the investment with.
@josh_bennett1 Thanks Josh. Agree. The biggest value for our existing customers is shorter and more confident release cycles. Testing teams have always played catchup with development and now, more than ever, with increasing speed of development, testing has become the bottleneck leading to delay in release readiness. This is the exact problem our existing customers had before QApilot. What CoWork and QApilot on a broader level aims to do is to reduce this release anxiety and help teams to achieve release confidence faster. High Coverage, Less Time Spent, etc., are happy by-products but faster release readiness is the north star.
@mcarmonas That's an interesting question. I’d say it’s intentionally a mix. CoWork behaves humanlike in how it understands intent, reads app context, and adapts when the flow changes. But it executes with the discipline of an automation system.
So it’s not just a blind executioner, and it’s not trying to “pretend” to be human either. When it’s confident, it moves. When it needs judgment or input, it asks.
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.
@pradeepsoundararajan - Thank you, Pradeep. Means a lot coming from you.
Completely agree. Mobile testing is not just a tooling problem, it is a context and execution problem. With CoWork, the goal is to reduce the execution tax while keeping human judgment where it matters.
Report
The selector breakage problem is real.... we've seen entire automation suites go down after a single navigation update.
Curious how CoWork handles dynamic test data mid-execution. if a flow requires an OTP or an auth password during the run, can that be injected in real time or does everything need to be pre-configured before the session starts?
@harini_mukesh There are a couple of we handle test data on CoWork, depending on the type of the test data. The user can choose to plug in the test data as part of the natural language test context that is given to CoWork. CoWork will make use of it as needed.
Otherwise, if CoWork comes across an input field like an OTP during its journey, it prompts the user to enter the input, and once the user does that, it continues to autonomously execute the rest of the steps. So, yes. Depending upon the test data and user preference, it can be injected in real-time or pre-configured.
Report
@charan_tej_kammara The biggest challenge with mobile automation has never been writing the first version. It’s what happens after the app changes for the tenth or twentieth release.
You mention CoWork can replan execution when screens, labels or flows change, while still asking for human approval before changing intent. How much of that actually happens automatically in production? For teams using this every sprint, what percentage of failures end up needing manual intervention versus successfully recovering on their own?
That number would tell me more than any feature list because maintenance is usually where automation becomes expensive.
@moh_codokiai - Fair question, and I agree this is the number that matters.
CoWork doesn’t try to auto-recover everything. UI changes like labels, waits, layouts, or expected popups can often be handled. If the next step could change test intent, it asks for approval. If it needs input like an OTP, it pauses. If the app is broken, it fails honestly.
We’re tracking auto-recovery, approval replans, input pauses, and hard failures separately. I don’t want to quote a broad percentage yet because it varies by app and flow, but that’s exactly the benchmark we plan to publish as usage grows.
Replies
QApilot's CoWork
Hey everyone, Charan from QApilot here.
Every QA team knows what they want to test. "Log in, add an item to the cart, check the order confirmation." Saying it takes ten seconds. Then the team spends six months turning that sentence into something a machine will run: step definitions, selectors, automation glue, flaky scripts that break on every UI change.
The intent was never the hard part. The execution layer was the tax.
CoWork takes your existing natural-language or BDD test cases, converts them into structured BDD/Gherkin context, builds an execution plan, and runs the test on a real mobile device.
When the app behaves differently, like a changed label, unexpected popup, or interrupted flow, CoWork replans and asks for human approval before moving ahead. When it needs input, like an OTP, it pauses instead of guessing. If it can’t proceed, it fails honestly instead of faking a pass.
Who it’s for: QA leaders, SDETs, mobile engineering teams, and product teams with existing test cases but low execution coverage before releases.
Common use cases: Regression testing, Release readiness, checkout/login flows, OTP-heavy journeys, app flows that break often, and teams trying to reduce manual execution without rewriting everything from scratch.
What makes CoWork different is the balance: AI execution where it can move fast, human control where judgment matters.
If you run mobile tests, I’d genuinely love your take. Try it here: https://qapilot.io/product/cowork
Thanks for being here for the launch. I’ll be in the thread all day reading every comment.
-- Charan Tej, Product Guy @QApilot's CoWork
@charan_tej_kammara The "fails honestly instead of faking a pass" line is underrated. Most automation lies to you when the UI shifts under it, and a test that drifts and silently passes is worse than no test. When CoWork hits a screen that no longer matches the plan, does the human-approved replanning re-anchor to the intent of the step or to the old UI path? That distinction is what separates flaky from durable.
QApilot's CoWork
@charan_tej_kammara The honest-fail behavior is a smart choice. In mobile QA, a blocked test is annoying, but a fake pass is much worse because it creates confidence right when the team should slow down.
Curious how CoWork handles apps with heavy feature flags or UI states that change by user type?
QApilot's CoWork
@habibferdous - Thanks, Habib. Completely agree, a fake pass is far more dangerous than a blocked test.
For feature flags and user-type based UI states, we treat them as part of the execution context rather than noise. CoWork runs against the app state it sees, uses the given test intent and user context to decide the next step, and replans only within that boundary.
If the UI variant still supports the same journey, it can continue. If the flag or user state changes the intended behavior, it asks or fails honestly instead of forcing the test through.
PicWish
@charan_tej_kammara does it also support testing cross-app journeys?
QApilot's CoWork
Hi everyone! Aakash from QApilot here.
I'm one of the makers behind CoWork, and I'm really excited to finally share what we've been building!
CoWork helps AI and humans work together to make test automation more reliable instead of chasing full automation. We'd really appreciate your support on Product Hunt today, and I'd love to hear what you think. Thanks for checking us out!
QApilot's CoWork
QApilot's CoWork
Observer
Hey builders 👋
I am one of the makers behind CoWork!
We built CoWork - an AI agent that drives real mobile apps step by step, planning each action, reading the screen, and adapting when things go off-script.
We kept hitting the same wall: mobile automation breaks the moment a layout shifts. So we wanted something that actually sees and reasons about the screen instead of leaning on brittle scripts.
We'd love your feedback and support. Drop your thoughts/questions in the comments below and one of us will reply!
@vidushee_geetam The idea makes sense technically, but I’m interested in the operational impact.
If a team already has a mature manual regression process, what changes after six months of using CoWork? Is the biggest improvement shorter release cycles, higher regression coverage, fewer flaky tests, or simply less engineering time spent maintaining automation?
I’d be interested to know which metric your existing customers see improve first because that’s ultimately what teams will justify the investment with.
Observer
Humalike
Is agent behaviour humanlike? Or it feels more like an executioner? Congrats on the launch!
QApilot's CoWork
@mcarmonas That's an interesting question. I’d say it’s intentionally a mix. CoWork behaves humanlike in how it understands intent, reads app context, and adapts when the flow changes. But it executes with the discipline of an automation system.
So it’s not just a blind executioner, and it’s not trying to “pretend” to be human either. When it’s confident, it moves. When it needs judgment or input, it asks.
Thank you!
Bugasura
QApilot's CoWork
The selector breakage problem is real.... we've seen entire automation suites go down after a single navigation update.
Curious how CoWork handles dynamic test data mid-execution. if a flow requires an OTP or an auth password during the run, can that be injected in real time or does everything need to be pre-configured before the session starts?
QApilot's CoWork
@harini_mukesh There are a couple of we handle test data on CoWork, depending on the type of the test data. The user can choose to plug in the test data as part of the natural language test context that is given to CoWork. CoWork will make use of it as needed.
Otherwise, if CoWork comes across an input field like an OTP during its journey, it prompts the user to enter the input, and once the user does that, it continues to autonomously execute the rest of the steps. So, yes. Depending upon the test data and user preference, it can be injected in real-time or pre-configured.
@charan_tej_kammara The biggest challenge with mobile automation has never been writing the first version. It’s what happens after the app changes for the tenth or twentieth release.
You mention CoWork can replan execution when screens, labels or flows change, while still asking for human approval before changing intent. How much of that actually happens automatically in production? For teams using this every sprint, what percentage of failures end up needing manual intervention versus successfully recovering on their own?
That number would tell me more than any feature list because maintenance is usually where automation becomes expensive.
QApilot's CoWork