From 0 to 500+ Playwright Tests: How Ariso Handed Off End-to-end Testing
Ariso was shipping faster with coding agents, but nobody had time to build and maintain an end-to-end test suite. With Amikoo, the team went from almost no active Playwright coverage to more than 500 tests, put automated checks into its staging workflow, and caught defects before production, without making E2E testing another daily responsibility for its developers.
Impact at a glance
Max Heckel, CTO at Ariso, on going from essentially zero E2E coverage to 500+ Playwright tests without managing them himself.
Our test runners are executing on their own autonomously. I’m not doing anything on my end, and it appears to be working great. I don’t feel like I need to manage the end-to-end tests on my own.
The problem: Coding got faster, but E2E testing still had no owner
Ariso is an AI management platform that connects people, projects, and company knowledge into one shared system. As the engineering team adopted coding agents, Max estimates its development output grew 2–4×. But testing the behavior of the running application had not scaled in the same way.
The team already had unit and integration tests. What it lacked was an actively maintained end-to-end suite. A few older Playwright tests existed, but there was no dependable workflow for expanding coverage and running regression checks as the product changed.
The challenge wasn’t whether Playwright could test the application. It was who would create the tests, run them, investigate failures and keep them working after the next UI change. Developers had product work to ship; E2E maintenance did not have a clear owner.
The shift: Handing off Playwright E2E testing to Amikoo
Max configured an Amikoo worker with the application access and test credentials it needed. Then he gave it a straightforward task: explore the application and add around 20 end-to-end tests per day.
Over a few weeks, that directed work produced more than 500 Playwright tests. Instead of assigning developers a separate test-automation project, Ariso used the worker to establish the initial suite while the team kept building.
For developers, generating a Playwright file is only the first step. The ongoing job is running it reliably, understanding what failed, and updating it when the product changes.
Adding Playwright verification to CI/CD
When the team deploys to its staging environment, the Amikoo tests run automatically after the environment has had time to settle. The team can then review failures before the release moves to production.
Max says the workflow has increased confidence in releases and already surfaced real product problems. Instead of relying only on the developer who made the change to manually verify it, Ariso now has another layer checking whether important product workflows still behave as expected.
When an E2E test fails, is it the test or the product?
Building a large E2E suite introduces another challenge: keeping it current.
Ariso uses an Amikoo worker to help manage that loop. When tests fail because an expected UI change made them outdated, the worker can repair them. When a failure represents a real problem, it can surface that instead.
Max described the desired behavior as automatically fixing broken tests while reporting legitimate failures as actual bugs rather than blindly rewriting the test.
A 500-test suite is useful only if someone, or something, keeps it current.
The result: 500+ E2E tests without making Playwright another engineering job
Ariso started with essentially no active E2E coverage. Instead of turning Playwright into another internal engineering project, the team used Amikoo to establish and run its E2E foundation while developers continued building the product.
But the more important result came after the suite existed.
Max no longer has to continually trigger and manage the testing workflow himself.
That is the difference between using AI to write tests and handing off the E2E job.
For Max, the shift was not about becoming better at maintaining E2E tests. It was about not having to own that job in the first place.
A real defect caught before customers
In one example, a delete button on a team dashboard was throwing an error in the UI. An Amikoo test exercised the workflow and surfaced the failure before customers encountered it. And it was not an isolated incident.
Max estimates Amikoo has already caught two or three defects before they reached production.
What’s next for Ariso
Ariso’s product continues to change quickly, so its E2E coverage cannot be static. The goal is to keep the product continuously verified without handing the maintenance job back to developers.
Writing more code faster only helps if you can still prove the product works.
Frequently asked questions
How did Ariso go from zero to 500+ E2E tests?
Max set up a worker with application access and asked it to explore the app and add roughly 20 Playwright E2E tests a day. It built the initial suite over a few weeks.
How does Ariso use Playwright testing in CI/CD?
Ariso’s Amikoo E2E tests run automatically after staging deployment. The team reviews results before its production releases, creating another verification layer around its daily deployment cadence.
How does Ariso maintain its Playwright tests when the product changes?
Ariso uses an Amikoo worker to respond to failed tests. When an intentional UI change makes a test outdated, the worker can repair it. When the failure appears to be a legitimate application problem, the workflow can surface it as a real defect instead.
Your team ships faster. Who owns E2E now?
Coding agents can generate features and even Playwright tests. But somebody still has to decide what to verify, run it, investigate failures, and keep the suite working. See how Amikoo helps your team hand off that ongoing E2E work while keeping control of standard Playwright tests.
Get started with Amikoo
