DEV Community: Parth Patil

QApybara: Autonomous Open-Source AI QA Engineer for Web & Real Android Devices — Channeling Sloth Energy to Never Test a PR Manually Again

Parth Patil — Mon, 26 Oct 2026 05:14:55 +0000

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

qapybara-dashboard.vercel.app

Code

parth-lightning / QApybara

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…

View on GitHub

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.ts and design/tokens.ts are byte-identical copies.
All 38 public/images/*.webp files are copied unchanged into assets/products. lib/images.ts maps their website paths to bundled native modules. Login uses…

View on GitHub

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

VITRide: A ride sharing Flutter Prototype with H3 and a Gemma Matching Roadmap for VIT Pune Students

Parth Patil — Mon, 19 Oct 2026 05:01:20 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

I built a Flutter-based student ride-sharing prototype that covers the core journey of requesting a ride. Students can choose a destination, preview a route, compare ride categories and estimated fares, view nearby vehicles on a map, and request a ride.

The goal is to explore how spatial indexing and AI-assisted preferences could make student ride-sharing more practical. The project includes an H3-based spatial layer as a starting point for finding geographically nearby candidates.

The app is currently a prototype, not a live ride-sharing service. Nearby vehicles are synthetic, ride requests use a predefined driver assignment after a short delay, and there is no backend, real-time driver dispatch, student verification, or shared-ride matching yet.

Demo

Code

parth-lightning / HacktoberFest-Week-2

Student Ride-Sharing Prototype

A Flutter prototype exploring a student ride-sharing experience. It demonstrates a map-based trip flow: choose a destination, preview a route, compare ride categories and estimated fares, and request a ride.

This is a completed prototype, not a live ride service. Nearby vehicles are synthetic, and ride requests use a simulated dispatch flow that assigns a predefined driver after a short delay. The app has no backend, live driver dispatch, student verification, or shared-ride matching.

Features

Custom Flutter vector map with synthetic nearby vehicles and route visualization.
Destination selection and generated route previews with distance and duration estimates.
Ride category selection and fare estimates.
A simulated ride-request and driver-assignment flow.
A pure Dart H3-style spatial indexing implementation, with an optional map grid visualization.
Prototype security-status and device-audit UI.

The route geometry, vehicle positions, traffic segments, fares, surge values, and driver details are illustrative prototype data. They should not…

View on GitHub

How I Built It

I focused on building the ride flow first, so the prototype demonstrates how a student would interact with a ride-sharing application before introducing the complexity of a live backend.

The app brings together destination selection, route visualization, ride-category comparison, fare estimation, nearby vehicle markers, and ride requests. The spatial indexing layer provides a foundation for organizing geographic data and identifying potential candidates efficiently.

The next development phase is to replace simulated assignments with a backend that manages students, available rides, routes, departure times, and seat availability. A deterministic matching service could then evaluate location proximity, route overlap, timing compatibility, and available seats.

Where Does Gemma Fit?

For example, a student could enter a request in natural language:

“I need a ride to college around 8:30 AM, and I can take a small detour if it reduces the cost.”

A Gemma-powered component could interpret this request and convert it into structured preferences, such as the desired departure window and acceptable detour. A separate matching service would then evaluate candidate rides against explicit rules for location, route overlap, timing, and seat availability.

Gemma could also explain why a ride is compatible with a student's preferences. However, the actual matching and dispatch decisions should remain deterministic, testable, and independent of the language model.

This separation would make AI useful without giving it unchecked control over ride assignments.

Why Does Open Innovation Matter?

Student ride-sharing involves potentially sensitive information, including travel routes, schedules, and location data. Open-weight models such as Gemma offer an opportunity to explore local inference, where supported, instead of relying entirely on a hosted AI service.

This could provide greater control over how ride preferences are processed and where that information is sent. However, local inference is a future direction for this project, not a feature of the current prototype.

A real deployment would also require appropriate consent, location-data minimization, secure storage, student verification, and thorough testing of the matching system. Using an open-weight model alone does not guarantee privacy or security.

My First User

My first user being my friends from college who found the idea highly useful and recommended a lot of things in order to make the application helpful for everyone.

Solo submission by @parthlightning

WildPack: A Local-First Trail Guide with Gemma

Parth Patil — Mon, 12 Oct 2026 04:35:19 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

WildPack is a local-first trail-guide prototype for hikers and curious naturalists. It brings an imported region pack, trail notes, and pack-grounded questions together in a browser app, with GPX route replay and optional browser geolocation.

The goal is to make a phone or laptop more useful outdoors—not to keep someone scrolling. The app stores packs and observations in the browser, and the local AI path can answer questions without sending them to a hosted model. The app is still a prototype: its bundled route and nature text are synthetic examples, not verified trail or species information.

Demo

Code

WildPack on GitHub.

parth-lightning / Hacktoberfest-Week1-Challenge

WildPack

WildPack is a desktop-first, local-first trail-guide prototype. It stores imported .wildpack files and observations in this browser, can replay synthetic GPX routes, and can use Ollama on the same computer for pack-grounded questions The bundled demo route and its natural-history text are synthetic: they are not a real trail, species record, or source of outdoor-safety advice.

The implementation follows the accompanying Software Requirements Specification but not every phase or acceptance criterion is complete. The current status and limitations are listed in the phase-status checklist. DigitalOcean is not required for the local prototype.

Run the laptop prototype

Requirements: Node.js 20.19+ or 22.12+, npm, and (for local model features) Ollama.

npm install
ollama pull gemma3:4b
ollama pull embeddinggemma
npm run dev:all

Open http://localhost:5173. dev:all starts Vite on port 5173 and the Express API on port 3001. The app can load its synthetic demo pack without credentials Local…

View on GitHub

How I Built It

WildPack uses React, TypeScript, and Vite for the frontend, with an Express API for local model calls. Imported packs and observations are stored in browser storage, and a service worker provides an app shell and caches same-origin resources.

For AI, I used Gemma 3 4B through Ollama for local model features and EmbeddingGemma for embeddings and retrieval. The intent is to keep questions and location data on the user’s machine rather than depend on a hosted inference service.

I also added an ElevenLabs integration path for narration generation in the pack builder. I didn’t generate or test a voiced pack for this prototype, so narration should be treated as an unverified capability—not as part of the demo.

Why Does Open Innovation Matter?

Open-weight models and local inference let this prototype explore a useful trade-off: AI features can be available without sending a hiker’s question or location to a hosted model provider. They also make it possible to experiment on modest local infrastructure rather than requiring a cloud account.

That matters for an outdoor guide, where connectivity can be limited and location is sensitive. The current app’s pack storage and GPX replay work locally; offline model inference and real-world field use still need further testing.

Prize Categories

Gemma: WildPack uses Gemma 3 4B locally through Ollama for pack-grounded questions, with EmbeddingGemma for retrieval.

ElevenLabs: The pack builder includes an ElevenLabs narration-generation integration. I did not generate or test narrated audio for this prototype, so please confirm this qualifies for the category before submitting.

Solo submission by @parthlightning

Beacon: Turning inspection reports into work orders

Parth Patil — Mon, 05 Oct 2026 06:33:55 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built 'Beacon' around a problem a friend of mine who just got placed in machinery plant maintenance could run into: inspection findings arrive in a PDF, but someone still has to turn them into a useful follow-up.

Beacon can read an inspection report, extract its findings, and use browser control to prepare a work order in a separate maintenance app. It asks the operator before submitting, then checks the saved work order. The maintenance app uses synthetic data and runs locally. It’s a working demo, not software connected to a real plant.

Architecture

Demo Snapshot

Code

Beacon on Github

How I Built It

Beacon’s chat app uses Next.js, React, and TypeScript. The agent runs on Eve, with a separate Eve session and workspace for each chat. I use the Vercel AI SDK and its OpenAI and OpenAI-compatible provider packages to connect the agent to models.

For the open-weight model path, Beacon connects to a self-hosted Qwen 3.8 27B Max endpoint. The model picker also offers hosted models through OpenCode Go. For inspection PDFs, the agent sends the document to a private PaddleOCR-VL service, then uses the extracted findings as evidence when preparing the work order.

The app and agent runtime can run on a local machine with Bun. To run inference locally too, point QWEN_BASE_URL at a local server that exposes an OpenAI-compatible API and serves the Qwen model. For a fully local document workflow, the OCR service must also run locally, and you should choose the Qwen endpoint rather than a hosted model.

Why Does Open Innovation Matter?

The open-weight model gives me a choice about where inference runs. I can use a hosted model while building, or run Qwen behind an endpoint I control. The OpenAI-compatible interface lets Beacon connect to that endpoint without tying its agent code to one model provider.

That matters for inspection documents. If the model and OCR services run locally, the report can stay on the operator’s machine. The current setup also supports hosted models, so local processing depends on configuring local endpoints and selecting them.

Prize Categories

Best Use of GitHub Copilot: The most useful thing GitHub Copilot did was help me turn Beacon from an idea into a working end-to-end project. It helped me connect the chat app, Eve agent, model providers, inspection-report parsing, and browser control into one workflow. The part I found most valuable was shaping and testing the handoff from a report’s findings to a work order, with the agent asking for approval before submitting and checking that the order was saved afterward. Copilot sped up the implementation, but I still had to make the product decisions and verify the pieces worked together.

Solo Submission by @parthlightning