You connect an AI tool to your repository; it reads the codebase to map out real user journeys (login, checkout, navigation, etc.), then generates a full Playwright test suite — selectors, assertions, and all — for you to review and run. Below is exactly how that process works with Amikoo our AI QA tool, what to check before trusting the output, and where it fits if you already know Playwright.
If you've worked in QA or written a Playwright suite yourself, you don't need convincing that end-to-end testing is worth doing. You've felt the payoff of catching a broken checkout flow before it hits production. The value was never in question.
The bottleneck is time. Writing solid E2E coverage means:
Mapping every meaningful user journey through the app (not just the happy path)
Writing accurate selectors that won't break the moment a <div> gets restructured
Building out assertions that actually catch regressions instead of just checking that a page "loaded"
Maintaining all of it as the app changes (new features, redesigned components, updated flows)
That last point is where most test suites quietly rot. Someone writes great coverage during a sprint, and six months later half of it is skipped or commented out because nobody had time to fix the selectors after a UI refactor. This is a resourcing problem, and it's exactly the kind of problem AI-assisted test generation is built to address.
The useful way to think about AI-generated Playwright tests isn't "replacing QA"; it's a shift in role, from writer to reviewer and director.
Instead of manually tracing through the app to identify journeys and hand-writing page.locator() calls, you're pointing an AI at the codebase and reviewing what it produces. You're still the one deciding what "correct" behavior looks like, still the one who understands the app's edge cases, and still the one who signs off before a suite goes into CI. What disappears is the hours spent on the mechanical part: reading through components to find selectors, writing boilerplate, and re-doing all of it every time the UI shifts.
For teams and individual QAs already fluent in Playwright, this mostly means faster first drafts and better baseline coverage.
The general workflow looks like this:
Consider AI-generated tests as a draft, not a final signature. Before merging a generated suite, run through this checklist:
When something looks off, you generally have two options: edit the generated test directly if the fix is small (a selector swap, an added assertion), or regenerate with more specific direction if the whole approach missed the mark (e.g., "also test what happens when the cart is empty at checkout"). Treat it the way you'd treat a pull request from a fast but unfamiliar new teammate, worth reviewing carefully, not worth rewriting from scratch every time.
The video here shows this exact process on a real project: Amikoo, our AI QA assistant, connects to a GitHub repository for an online shop, reads the full codebase, and generates a complete Playwright test suite covering the homepage, login, navigation, and checkout — end to end, without a developer writing a single test by hand.
The workflow described above is what Amikoo is built to do. It's an AI assistant that specializes in QA. It connects directly to your repository, reads the project in full to avoid contextual errors, and delivers a complete, ready-to-run Playwright suite that covers your real user journeys, not just the obvious ones.
If you already know the value of E2E testing and just want your coverage generated faster, you can sign up and try Amikoo for free, connect it to a real project, and see a full test suite generated in minutes.
It's runnable out of the box, but should still go through a human review pass, same as you'd review any generated code before merging it into CI.
Yes, as long as it's connected to the actual codebase (e.g. via GitHub). This is what lets it generate tests based on real components and routes instead of guessing from the UI alone.
Good tools will follow the existing conventions in your codebase rather than imposing a generic structure, but it's worth confirming this in the generated output.
Since the AI can re-read the codebase after changes, it can regenerate or update affected tests instead of leaving broken selectors for a human to track down manually.
No — it replaces the manual writing of test code, not judgment calls like exploratory testing, usability review, or deciding what "correct" behavior means for an edge case.
Autocomplete helps you write one test faster; full generation reads the whole project and produces an entire suite across multiple user journeys without you writing the initial draft at all.