AI Can Write the Test. Your Team Owns the Maintenance

AI has made the first hour of test automation dramatically cheaper.

Describe a workflow, paste a requirement, or point an agent at an application, and it can produce a respectable first draft. The code may include page objects, fixtures, assertions, and comments. It looks like progress because it is progress.

But creation was never the full cost.

The expensive part begins after the test joins the repository.

Now the team must decide whether the assertions are meaningful, whether the selectors are durable, whether the data is safe, whether the test fails for the right reasons, and who will fix it six months later when the interface changes.

AI lowers the cost of producing tests. It can also increase the number of tests you are responsible for.

That is the trade-off teams need to understand.

Generated code can fail before generated tests even run

AI-generated frontend changes frequently work in a local environment and fail in CI. The problem is not always the quality of the generated code. It is the missing context around it.

The CI environment may use a different Node version, package lock state, browser build, environment variable set, feature flag, operating system, or resource limit.

This analysis of describes the shift well. Reviewers need to evaluate more than syntax.

A generated test can be perfectly valid TypeScript and still be a poor test because it:

• asserts incidental copy;


• uses a selector that matches multiple elements;


• hides an unreliable action behind retries;


• duplicates coverage that already exists;


• skips negative behaviour;


• passes after an optimistic update but before server confirmation;


• creates data it never cleans up.

Code review for generated tests should begin with intent:

1. What product risk is this test reducing?


2. What failure would it catch?


3. Why is the browser the right layer?


4. Does it fail when the product is broken?


5. Will the team understand the failure report?

Only then should the reviewer care about formatting and helper reuse.

The test count can become a vanity metric

When generation is expensive, teams are selective. When generation becomes almost free, restraint becomes more important.

It is easy to produce 200 tests from requirements, tickets, and recorded sessions. The number looks impressive. Then the product changes, 47 tests fail, and nobody knows which failures matter.

This framework on offers a healthier cost model.

Do not compare only subscription price with an open-source licence price.

Compare the full workflow:

Total cost = platform cost

           + test creation time

           + review time

           + maintenance time

           + infrastructure

           + failure diagnosis

           + training and adoption

The same equation should be used for a home-grown framework.

“Free” software can be expensive when specialised engineers spend a significant part of every sprint maintaining it. A paid platform can also be expensive when it requires constant human supervision.

The correct unit is not licence cost. It is cost per trustworthy result.

Build versus buy is mostly a staffing decision

The comparison between recommends testing the state machine rather than the precise output.

For example, verify that:

• a response begins within an acceptable period;


• the loading or streaming state is visible;


• content grows rather than being replaced incorrectly;


• controls are enabled or disabled at the right times;


• cancellation stops the stream;


• the final state is persisted correctly;


• an error offers a recovery action.

For non-deterministic content, assert structure and constraints instead of a complete sentence.

You may check that the response is non-empty, contains required facts, follows a schema, avoids prohibited content, or receives an acceptable evaluation score.

The more variable the product, the more deliberate the oracle must be.

Stable coverage does not require a heavy framework

Some teams need deep framework control. Others mainly need dependable coverage of business-critical journeys without dedicating several engineers to test infrastructure.

This practical review of Endtest for teams that need stable coverage without a heavy framework represents the second group.

The value proposition is not that code is bad. It is that infrastructure work has an opportunity cost.

A team that avoids building its own reporting, test editor, execution grid, collaboration layer, and integrations can spend that time improving product coverage.

The trade-off is accepting the platform's model and limits. That is why a proof of concept should test the awkward workflows, not only login.

Try:

• multi-step authentication;


• file uploads and downloads;


• dynamic tables;


• cross-domain navigation;


• email and SMS verification;


• failure diagnosis;


• role-based collaboration;


• CI execution under realistic parallelism.

Any tool looks good when the demo is “open page, click button.”

Human approval should focus on risk

AI-generated tests should not require a committee meeting. But they should receive review proportional to their impact.

A low-risk visual check for an internal page may need a quick inspection. A payment, access-control, deletion, or regulatory workflow deserves deeper review.

A lightweight approval checklist can ask:

• Is the workflow worth testing at the browser layer?


• Are secrets and personal data handled safely?


• Can the test run in parallel?


• Are assertions tied to user outcomes?


• Does failure produce enough evidence?


• Is cleanup defined?


• Who owns future maintenance?

This prevents the two common extremes: blindly accepting generated code or making AI assistance so bureaucratic that nobody uses it.

The goal is not perfect generation.

The goal is controlled leverage.

The new bottleneck is judgement

For years, the bottleneck in browser automation was writing the code.

AI is removing part of that bottleneck.

What remains is judgement:

• choosing the right risks;


• deciding the right test layer;


• defining stable assertions;


• controlling test data;


• evaluating failures;


• deleting low-value coverage;


• choosing which infrastructure to own.

That is good news. These are more valuable problems than remembering the syntax for a locator.

But they are not automatic.

AI can write the test.

Your team still owns whether anyone should trust it.