Point AI test generation at the base of the test pyramid first: many fast, focused unit tests, then a smaller set of service level tests, and very few through the user interface. Generating hundreds of slow UI tests is easy and usually a mistake.
The pyramid in brief
Martin Fowler describes the test pyramid as a balanced portfolio with many more low level unit tests than high level tests running through a GUI. His reasons are practical. UI tests are brittle, expensive to write and time consuming to run, and they are hard to run headless in a deployment pipeline. Unit tests are faster and more focused.
In the middle sit subcutaneous tests, which exercise the application through its service layer or API. They keep many benefits of end to end tests while avoiding UI framework complexity.
What this means for a model
A model can produce a UI test script as quickly as a unit test. The cost shows up later: slow suites, flaky failures and tests that break when a button moves. Direct the tool deliberately.
- Ask for unit tests of pure logic first, with cases written from the requirement.
- Ask for service level tests for key flows, using the API.
- Ask for UI tests only for a few critical journeys, and keep them few.
A bug workflow worth copying
Fowler advises that before fixing a bug exposed by a high level test, you should replicate the bug with a unit test. This is a good job for an assistant. Give it the failing scenario and ask for the smallest unit test that reproduces it. Then fix the code and confirm that test passes.
Caveats from the same source
The pyramid assumes broad tests are slow and brittle. If yours are fast, reliable and cheap to change, you may not need as many low level ones. Fowler also calls record and playback tools almost always a bad idea except for generating fragments to edit by hand. Treat any generated end to end script with the same suspicion. Some practitioners prefer more integration tests, and he suggests part of that disagreement comes from different definitions of a unit test, so agree on definitions with your team.
Check what you generated
Whatever the level, audit the tests: break the code and see if they fail. A fast test that cannot fail is still useless.
A starter prompt shape
Describe the behavior in plain words, list the inputs and expected outputs you care about, name the level (unit, service or UI), and state the framework. Ask for no mocks of the code under test. Then review every test as you would a human contribution.
Quick check
Why not generate lots of UI tests?
They are brittle, slow and costly to maintain, according to the test pyramid guidance, so a few critical ones are enough.
What is a good first use of a model after a bug report?
Ask it for the smallest unit test that reproduces the bug, then fix the code.
Sources
Last reviewed: 19 October 2026.
