Amikoo decides which user flows need a new test by mapping every pull request against a living model of the application's critical paths, then applying risk based testing logic to prioritize what a real user would hit, what the change actually touches, and what has never been covered before. Rather than generating a test for every modified line of code, Amikoo asks a narrower question: could this change break something a user depends on? Once a team turns on a Worker for new pull requests, that filtering happens on every PR, which is what keeps test suites relevant instead of bloated. For developers who inherited E2E testing, it also takes over the hardest part of the job: deciding what needs testing in the first place.
- Amikoo prioritizes user flows using risk-based testing: business criticality, how close the change is to a flow, existing coverage, and past fragility.
- Coverage gaps, including in product areas shipped long before Amikoo was adopted, show up in a weekly coverage report and directly in VS Code.
- When a test fails, Amikoo diagnoses whether it's a real product defect or a test issue before anything gets repaired. Real defects get reported, not patched over.
- Developers don't have to decide what to test or keep tests alive; people make the final call on release risk.
- This approach targets the real cost driver in QA: industry data shows automated regression testing maintenance alone can consume up to 60 percent of a QA team's effort, which is time not spent building new coverage.
Amikoo is built by MuukLabs, a company whose engineering team has spent years embedding QA practice into software, and the product reflects direct experience with how fast-shipping web teams actually lose test coverage: not from lack of effort, but from the gap between how quickly code ships and how quickly tests can be written and maintained.
Not every code change touches a path a user will ever take, and writing a test for each one wastes engineering time without reducing real risk. A user flow, in UX and QA terms, is the sequence of steps a person takes to complete a goal in a product, like signing up, checking out, or exporting a report [animaapp.com]. Some code changes sit entirely behind that flow (a refactor, a logging change, an internal utility) and have no observable effect on it. Others sit directly in the critical path and need verification every time they move.
This is the core logic behind risk based testing: concentrate testing effort where failure would actually hurt the user or the business, rather than spreading it evenly across every file touched in a commit. Teams that design user flows deliberately already think this way, documenting one goal per flow and treating each flow as a distinct, testable unit [dovetail.com]. Amikoo applies that discipline on every pull request. With a pull request Worker turned on, Amikoo reviews the changes, identifies which flows they could plausibly affect, and decides whether the right response is a new test, an update to an existing one, or no action at all. The tests it writes are added directly to the PR.
Building on that filtering logic, the harder problem is knowing what the flows even are before you can decide which ones matter. Amikoo analyzes the application and the repository to understand the paths users take through the product, from entry point to completed goal, rather than treating the app as a list of files or pages. Teams that use Jira can connect it, so Amikoo also has the context behind a change: what the ticket says should happen and why. Product usage data from analytics tools like Pendo is the next layer of context Amikoo is adding.
That map becomes the baseline for coverage mapping: what's tested today, what's missing, and which of the missing pieces are actually critical. This matters because a lot of test debt isn't new. It's product surface area that shipped months or years ago and was never covered, sitting quietly until a change nearby exposes it. Amikoo's coverage model treats that backlog as a first-class target, not an afterthought, because optimizing a flow starts with knowing its current state before deciding where to intervene [omniconvert.com].
Once the map exists, prioritization comes down to a handful of concrete signals rather than guesswork. Amikoo weighs:
- Change proximity: does the PR touch code inside or adjacent to a known user flow?
- Business criticality: is this a revenue path (checkout, onboarding, billing) or a low-traffic admin screen?
- Coverage gaps: is this flow already tested, partially tested, or untested?
- Historical fragility: has this area produced defects or flaky behavior before?
A flow that scores high on criticality and sits directly in the diff gets a new or updated test immediately. A flow that's tangential and low-risk might get flagged in the coverage report instead, visible but not blocking. This is the same judgment a senior QA engineer applies manually, just run consistently on every single pull request instead of occasionally during a sprint review.
Stepping back from the mechanics, it's worth separating this from older, cruder automated UI testing tool approaches that simply re-run everything or test whatever changed without judgment. A useful analogy: imagine a building inspector who checks every room in a house after any repair, versus one who checks the rooms connected to the pipe that was just replaced, plus any room with a known history of leaks. Both are "thorough," but only the second approach scales as the house gets bigger. Testing every changed file is the first inspector. Risk based testing, applied consistently, is the second.
This distinction matters for automated regression testing at scale. Most teams run well under full automation coverage, and the remaining manual testing volume is a known bottleneck for fast-shipping teams. Worse, maintenance of existing automated tests eats into a meaningful share of a QA team's effort industry-wide, which means even teams with decent coverage often can't afford to expand it. Prioritizing which flows get new tests, instead of blindly generating coverage everywhere, is what keeps that maintenance tax from growing unchecked.
Teams can run tests in Amikoo's cloud at any time, from the Tests list or by asking in the Amikoo chat, and each run returns the result, the duration, and a video of the run.
Generating the right test is only half the job; the other half is what happens when that flow legitimately changes or a test fails. When the Amikoo agent runs a generated Playwright test and it fails, the first step is not repair, it's diagnosis. Amikoo determines whether the failure is a real product defect or a test that's out of sync with an intentional change to the UI or a flow. Only test issues get repaired; real defects get reported, not patched over.
This diagnose-before-repair sequencing is deliberate. Repair without diagnosis risks masking a genuine product regression by quietly rewriting the test to match broken behavior. The Amikoo agent is designed to avoid that failure mode by requiring classification first. Amikoo's Repair Agent is built around this sequence. In internal benchmarks against Playwright's native Healer Agent, it achieved 2x the repair success rate and 5x faster repair cycles while using 28% fewer tokens. These are internal, benchmark-specific results, not independently verified. The architectural point stands regardless: fixing a test without knowing why it broke is guesswork, not maintenance.
A related but distinct question teams ask is which framework should back all this generated test code. Playwright is an open-source end-to-end testing framework developed by Microsoft, supporting JavaScript, TypeScript, Python, Java, and .NET, with cross-browser coverage across Chromium, Firefox, and WebKit, plus built-in automatic waiting, parallel execution, network interception, and mobile emulation. In the ongoing playwright vs cypress comparison, Playwright's native multi-browser support and language flexibility are typically what tips teams toward it for new automated UI testing tool investments, particularly as projects scale across browsers and CI environments.
Amikoo generates standard Playwright TypeScript tests and commits them directly into the customer's own repository. The tests are not proprietary, there's no special runtime required to run them, and if a team ever stops using Amikoo, the tests keep running as ordinary Playwright test automation code. Teams with existing Cypress or Selenium suites can have Amikoo generate new Playwright coverage alongside them.
All of the filtering, mapping, and diagnosis described above exists to answer one practical question for engineering leadership: is this worth the spend. Test automation ROI isn't just about how many tests exist, it's about how much of that coverage maps to flows that matter and how little of the team's time goes into just keeping old tests alive. Given that maintenance can eat up to 60 percent of QA effort industry-wide, and that poor software quality itself carries real cost to many organizations, the return on an ai qa agent depends heavily on whether it's generating noise or generating coverage where risk actually concentrates.
This is also where the human/AI division of labor matters for ROI, not just for trust. It also depends on who's doing the work. Amikoo handles it: deciding which flows need verification, writing and running tests, diagnosing failures, repairing test issues, and reporting real defects. Developers and QA leads make the final call on release risk, with the evidence Amikoo reports. That split is what keeps automated test generation from turning into a second maintenance burden.
Does Amikoo generate a test for every pull request?
No. With a pull request Worker turned on, Amikoo reviews each PR and writes or updates tests only where the change affects a user flow worth testing, rather than creating a test for every change.
What testing framework does Amikoo use?
Amikoo generates standard Playwright TypeScript tests and commits them to your repository as ordinary test code with no proprietary runtime.
How does Amikoo handle a failed test?
It first diagnoses whether the failure is a real product defect or a test issue. Only test issues are repaired; real defects get reported, not masked.
Can Amikoo find gaps in coverage I already have?
Yes. Amikoo identifies untested or partially tested flows, including product areas shipped before Amikoo was adopted. Teams can get a weekly coverage report by email and see coverage gaps directly in VS Code.
Does Amikoo replace manual QA judgment?
No. Amikoo takes over the testing work: writing and running tests, diagnosing failures, repairing test issues, and reporting real defects. People make the final call on release risk.
Which repositories does Amikoo connect to?
GitHub or Azure DevOps, including multiple repositories within the same integration. Bitbucket and GitLab support is in progress.
How long does setup take?
Developers typically connect their app and repository in about 30 minutes; that figure refers to setup time, not full suite execution time.
Amikoo is an AI agent by MuukLabs that owns end-to-end verification for web applications. Developers connect their app and repository in about 30 minutes. From then on, on every pull request, Amikoo understands the change, determines which user flows need verification, creates or updates standard Playwright TypeScript tests in the team's own repository, runs them, diagnoses each failure as a product defect, test issue, or environment issue, and reports real defects. It's built for fast-shipping teams, often using coding agents like Claude Code or Cursor, where E2E testing has fallen on developers and the current workflow can't keep up. Amikoo complements coding agents rather than replacing them: AI writes and reviews the code, Amikoo verifies the product actually works. It connects to GitHub and Azure DevOps, with Bitbucket and GitLab support in progress, with no proprietary runtime or lock-in. MuukLabs also offers MuukTest, an expert-backed services brand under the same parent company, for teams that want hands-on QA support alongside the platform.
If your team is shipping fast and guessing which flows need coverage, it's worth seeing how this works on your own codebase. Learn more at https\://amikoo.ai/.
- User flows in UX: Definition, examples & diagrams | Anima (animaapp.com)
- User Flows: A Guide With Best Practices & Examples (dovetail.com)
- User Flows: What They Are and How to Optimize Them (omniconvert.com)