QApilot's CoWork

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.

Can this be used for scraping/automation tasks as well as testing?

@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?

looks cool! can it work on my local device?

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

@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.

Congrats on the launch guys!!Nice idea! Is the generated automation framework-agnostic, or does it target a specific testing framework?

@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.

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?

the six-months-to-automate part is real. my team gave up automating our iOS app last year because every release broke the selectors. went back to manual regression and shipped slower for 6 months.what i'd want to know about qapilot: when an iOS update changes the entire navigation hierarchy, does the AI re-plan or does it break the same way our selectors did? that's the test for whether this actually saves a QA team or just shifts the breakage to a different layer.

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!