This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady
What I Built
AI coding assistants have made developers write twice as much code in half the time. But nobody doubled the size of testing teams. Over 60% of startups ship without dedicated QA. Review bots like CodeRabbit and Greptile read your pull request diffs, but research shows that only around 15% of review comments catch real defects. The bugs that actually ruin a user's day — a dead checkout button, a broken dropdown, an Android ANR ("Application Not Responding"), or a silent 500 error — only reveal themselves when someone actually runs and interacts with the app.
Manually clicking through staging apps, filling out test forms, and inspecting devtools on every PR is tedious, dread-inducing work.
This week’s theme celebrates International Sloth Day: channeling your inner sloth, moving at a relaxed pace, and letting open-source AI do the work so you don't have to.
Enter QApybara (inspired by the capybara, the calmest, most unbothered creature in nature).
QApybara is an autonomous, open-source AI QA Engineer that doesn't just read your code — it runs it on a real Chromium browser and a physical Android phone plugged in over USB.
Instead of doing manual regression testing, you embrace pure sloth mode:
Push your code.
Slap a qa label (or comment /qa) on the GitHub pull request.
Sit back, relax, and take a nap.
QApybara spins up the app or installs the build APK on a physical phone, maps user journeys, exercises the app like a human user, catches crashes and console errors, captures screenshots and screen recordings, and posts an evidence-backed verdict directly back to your PR and team Slack thread.
Demo
Code
QApybara 🦥
Review bots read your code. QApybara runs it — on a real browser and a physical Android phone — and shows proof.
QApybara is an autonomous, open-source AI QA Engineer that tests pull requests by actually running and interacting with the application like a human user. When a developer labels a PR with qa or comments /qa, QApybara spins up the web preview or installs the APK on a USB-connected Android phone, maps user journeys, exercises the app, detects runtime errors, captures video and screenshot proof, and exports passing journeys as reusable Playwright or Maestro regression tests.
Built with open-weight models, the Eve agent framework, and the Model Context Protocol (MCP).
🌟 Key Highlights
- Runs, Doesn't Just Read: Code review bots analyze syntax and style; QApybara boots your app, clicks buttons, fills out forms, tests edge cases, and verifies real runtime behavior.
- Web & Real…
parth-lightning
/
qapybara-store-app
Mobile e-commerce store (Stillform) for QApybara - contains all source files, assets, and build configurations to generate the Android .apk
Stillform mobile
An offline Expo shopping app for sneakers and clothes. Accounts, sessions, per-user bags, orders and appearance are saved locally with AsyncStorage. All photography and fonts are bundled; no backend or network is required. Payments and fulfillment are simulated.
Run
Node.js 22+, npm. Run npm ci, then npm start. Expo SDK 58, Expo Router, React Native 0.88, React 19.3 and TypeScript. Use a native development or release build for native modules.
Existing test login remains demo@qapybara.dev / Demo1234!. You can also create and sign into local accounts. Passwords are stored as salted SHA-256 digests; this local implementation does not provide server authentication or cross-device sync.
Website parity
Source: /home/shahid/codes/hackathons/qapybara-store-web, commits 7d6379a and 8e86a75.
-
lib/catalog.ts,lib/pricing.ts,lib/schema.tsanddesign/tokens.tsare byte-identical copies. - All 38
public/images/*.webpfiles are copied unchanged intoassets/products.lib/images.tsmaps their website paths to bundled native modules. Login uses…
How I Built It
- Dynamic Agent Teams on the Eve Framework Many agent workflows use rigid, hardcoded pipelines (Explorer ➔ Tester ➔ Reporter). QApybara is built on the open-source Eve agent harness and decides its team dynamically:
For a small one-line PR, the main agent handles the check alone.
For a multi-component feature touching database schemas, APIs, and UIs, the main agent spawns an Explorer to map touched routes, spins up multiple Testers in parallel (one per critical journey), and terminates with a Reporter to synthesize the report.
Real Android Automation & 3.2x Batch Tool Calling
Most AI testing agents stop at the browser. QApybara drives real Android phones connected via USB. Rather than making a slow roundtrip to the model for every single tap or swipe, QApybara implements programmatic batch tool calling through MCP. The model generates batch sequences that execute in one go on the phone, speeding up Artemis execution by over 3.2x.Proof, Not Vibes (The Deterministic Proof Gate)
An LLM claiming "Everything looks good!" is useless if it missed a broken submit button. In QApybara, code — not the AI — enforces the verdict:
No screenshot or video trace? No pass.
Unaddressed console errors or HTTP 500s? No pass.
Critical configured flow skipped? Run marked as "QA Incomplete".
Passing journeys are compiled into reusable Playwright (.spec.ts) and Maestro (.yaml) test scripts, ensuring you gain permanent automated regression tests without writing boilerplate.
- Rewarding Laziness: Zero-Dashboard Setup Even setting up QA should be effortless. Running npx qapybara init wires the QApybara MCP server and setup skills directly into your local coding agent (Claude Code or Codex). You simply say: "Set this repo up for QApybara". Your coding agent inspects your repository, configures build and start commands, pushes encrypted env variables, and executes a dry-run test on the QA host until it passes.
Where Open Source AI Fits In?
QApybara is built around open-weight models and open protocols:
Open-Weight Model Backbone: Powered through any OpenAI-compatible runner (such as Moonshot Kimi, Qwen 2.5, or Llama 3 via vLLM/Ollama/OpenRouter). Swapping models or providers is a simple environment variable toggle (QA_MODEL_ID), requiring zero code changes.
Role-Based Model Specialization: You can route different roles to different open-weight models:
Deep reasoning open models for the Explorer to map subtle test cases.
Fast, low-latency open models for the parallel Testers executing UI actions.
Local Simulation Mode (QA_MODEL=sim): For complete offline testing, local CI, and testing the agent tree without an internet connection or API keys, QApybara includes a fully deterministic scripted simulation harness.
Model Context Protocol (MCP): Built on Anthropic's open MCP specification, enabling standardized communication between the QA host, coding agents, and the interactive embedded MCP App report viewer (ui://qapybara/qa-run.html).
Why Does Open Innovation Matter?
Testing real applications involves pre-release code, sensitive staging environment credentials, internal databases, unreleased Android APKs, and proprietary business logic.
Here is why an open approach beats closed proprietary QA services:
Data Privacy & Zero Cloud Leakage: Proprietary cloud QA services require handing over full repository write tokens, internal staging URLs, database credentials, and APK binaries to third-party servers. With QApybara, open-weight models and self-hosted agents can run entirely on a local machine or a dedicated office laptop (like an old ThinkPad with an Android phone plugged in). Secrets are encrypted with local keys, and unreleased APKs never touch a third-party cloud.
Zero SaaS Tax / Costs Nothing to Run: Closed QA platforms charge steep per-seat monthly fees or price-gouge per browser minute. By running open-weight models on your own hardware or through cost-effective open endpoints, continuous PR testing costs virtually nothing.
Model Freedom & Future-Proofing: Closed platforms lock you into their specific model version and pricing whims. With an open architecture, you can swap models, run quantized models locally on an edge workstation, or fine-tune an open-weight model specifically on your application's design system and terminology.
The Lazy Payoff
Before QApybara, manually verifying a non-trivial pull request was a 45-minute chore nobody wanted to do:
Pulling the branch and starting the dev server or downloading and adb install-ing the latest APK build on a phone.
Manually clicking through 8 different user journeys (signing up, typing credentials, testing search cases, adding items to the cart, applying coupons, checking order history).
Keeping devtools open to watch for silent 4xx/5xx network errors and scanning adb logcat for hidden Android ANRs.
Typing out a bug report by hand with screenshots when something inevitably broke.
Writing end-to-end Playwright or Maestro test scripts from scratch so the bug doesn't happen again.
With QApybara, the "lazy payoff" is real:
~3 Hours Saved Per PR: Instead of context-switching away from coding to babysit staging deployments and manual test clicks, we just label the PR qa and walk away.
Zero Test-Writing Effort: Because QApybara automatically converts passing runs into deterministic Playwright (.spec.ts) and Maestro (.yaml) test scripts, our regression test suite grows without us writing a single line of test code by hand.
Used Live This Week: We ran QApybara against our benchmark store with 10 tricky planted bugs (like coupon double-application and silent signup errors). While we grabbed coffee, QApybara's autonomous agent team ran in parallel, caught all 10 bugs, recorded every screen video, captured the HTTP 500 traces, and posted clean reproduction steps back to our PR thread.
Total developer effort required: typing qa. That's true sloth-level productivity.
Solo submission by @parthlightning
Top comments (0)