In an agentic SDLC, it doesn’t matter whether AI generates your test code or a developer or SDET writes it by hand. Traditional functional testing does not scale.
Every coded test depends on locators that break when a developer renames a class or restructures the DOM. AI-generated tests add a new cost: they arrive full of code and selectors that are slow to review, so they often get merged and unreviewed. Over time, suites bloat, run longer, grow flakier, and still cover only a fraction of the application.
Plain-English testing in Applitools flips the model. You describe what a user does, and Applitools executes it:
Click the "Contact Us" link
You can also include these English test steps right in your open source-based coded tests:
await eyes.run('Click the "Contact Us" link');English test steps are the easiest tests to author and trivial to review. They execute deterministically and fast, at close to code speed, unlike tests executed live by an LLM. They reduce the size and complexity of tests, and because they don’t rely on locators, they stop breaking when the UI changes. This post explains how it works, why it matters, and how it compares with the frameworks most teams use today.
Applitools built its reputation on Visual AI, which reduces code by replacing hundreds of locator-based assertions with a single visual checkpoint. Visual AI took locators out of validation, but teams still needed code and locators to drive the test, and that is where most of the maintenance burden remained.
Specifying test steps in plain English addresses that remaining gap. The barrier today is not who can write test code. Most teams have shifted left, AI can write the code, and non-developers have always had no-code tools. The bottleneck is what comes after: reviewing AI-generated test code, maintaining fragile locator-based tests, and managing suites that are bloated with duplicates, run longer, grow less stable and still provide little coverage. English steps are short enough to review at a glance and have no locators to maintain.
Applitools also designed it for reliability. Every step is interpreted and executed by Applitools’ own Deterministic Language Model (DLM), on every run, with no code generated under the hood. Unlike tests executed by LLMs, DLM-executed tests run deterministically and fast, at close to code speed, so results stay consistent in CI. And when it is genuinely easier to point at an element than to describe it, the DLM also supports CSS and XPath locators.
| Challenge | What teams experienced | How plain-English testing addresses it |
|---|---|---|
| Unpredictable AI | LLMs can execute plain-English tests and solve some of the challenges below, but results vary from run to run | Every step runs on Applitools’ DLM, so execution is consistent on every run |
| Reviewing AI-generated tests | AI-generated end-to-end tests are full of code and locators, so they are slow to review and often get merged unreviewed | English steps read like a test case and are trivial to review |
| Slow, costly execution | LLM-executed steps add latency and token costs to every run | The DLM runs at close to code speed and never consumes tokens at run time |
| Security | Sending UI snapshots that include user details and input to an external LLM on every run raises data-exposure concerns | Execution runs on Applitools’ own deterministic model, with no third-party LLM in the loop at run time. We never train our models on customer data. |
| Brittle locators | CSS and XPath selectors break with every UI refactor | Steps reference elements the way a user sees them, not by DOM path, so tests no longer fail when the UI changes |
| Dynamic or hard-to-test apps | Locators change at runtime, or the app was not built with testability in mind and elements lack stable locators | English steps identify elements by what users see, so they don’t depend on stable locators |
| High maintenance cost | Sprints spent fixing tests instead of adding coverage | Smaller, simpler tests with no locators leave far less to break |
| Unreadable tests | Developers, testers and product owners struggle to see what a test actually checks | The test reads as documentation of expected behavior, for developers and non-developers alike |
Plain-English testing started in Applitools Autonomous and, as of September 2026, is available to coded tests in Applitools Eyes. That means both no-code and code-first teams can use it.
Applitools invented visual testing and has published dozens of SDKs that let teams add visual checks to their open source, coded tests. Many commercial no-code tools integrated with Applitools as well. Still, we kept meeting teams in our customer base whose testers didn’t have coding skills, and they asked us for a solution built for them, and it has since become just as useful to developers who want tests they can review at a glance.
Autonomous was built to close that gap. It launched with an NLP engine that lets anyone write the driving steps in plain English, with no selectors behind them, and include visual checks as provided by the Eyes SDKs. Over the following releases it added live interactive authoring, an auto-correction model, AI-generated steps from business intent, and plain-English API calls, test data, conditional logic and PDF checks. All of these kept the same deterministic execution. Over the years, dozens of teams have used the technology intensively to test complex, dynamic applications, from packaged applications to content-rich websites and complex web applications.
The latest step brings that work back to where it started. Eyes now supports NLP test steps inside coded tests via the Eyes SDK, starting with the Playwright Fixtures SDK, with more web and mobile SDKs coming soon. Developers can keep their framework and replace brittle selectors with plain-English actions and assertions. Visual AI removed locators from validation, and NLP steps are now removing them from test execution too.
| Applitools Autonomous | Applitools Eyes | |
|---|---|---|
| Who it is for | QA, manual testers, BAs, product owners, and engineers who want no-code | Developers and SDETs working in their own framework |
| How English is used | The entire test is written in English steps, typed or recorded | NLP test steps for actions and assertions inside your coded test. Tests can be a hybrid of programmatic, coded syntax steps and NLP or 100% NLP if the tester/developer chooses. |
| Framework support | No framework needed. Everything is included out of the box, from the devices and browsers your tests run on to test execution scheduling infrastructure | Playwright today, with more web and mobile platforms coming soon |
| Execution model | Deterministic, executed by Applitools’ DLM. Built-in AI model used for intent-based test authoring. | Deterministic, powered by Applitools’ DLM. Use your own AI model to assist with test authoring. |
In Applitools Autonomous, a test is a list of plain-English steps. There are no locators, no page objects and no framework boilerplate. A Contact Us form test can look like this:
Behind the scenes, a few things happen:
The same English vocabulary covers tables and grids, file uploads, HTTP requests and API checks, generated test data, and pre-steps, so one readable test can span UI and API.
In Applitools Eyes, the same English steps run inside your coded tests with eyes.run. Here is the identical flow in a Playwright Fixtures test:
The same login step reads very differently depending on the tool.
await page.getByRole('button', { name: 'Sign in' }).click();Playwright, Cypress and Selenium are powerful, flexible and developer-friendly, but every step still depends on code and locators. That brings back the challenges described above: brittle locators, slow reviews of AI-generated test code, high maintenance, and tests that only developers can read.
When I click the Sign in buttonThis looks like plain English, but it is a contract, not an engine. Every Gherkin phrase needs a matching step definition written in code, so someone still writes and maintains the glue, locators and assertions behind it. Wording must match exactly or the step fails.
Click the Sign in button
English text is the source of truth. There’s no step-definition layer, no locator, and no glue code, and Applitools’ DLM executes it the same way on every run.
Other no-code and AI testing tools generally fall into two camps. Some still rely on brittle locators under the hood, often with limited self-healing, which leads to flaky execution and high maintenance overhead. Others use LLMs to execute test steps at run time, which is inconsistent and unreliable. Applitools avoids both: English steps with no locators to maintain, executed deterministically by the DLM.
In an agentic SDLC, generating tests is no longer the hard part. Anyone can use an LLM to execute English test steps or generate test code from an English description. The hard part is everything after: reviewing that code, confirming it actually tests what was intended, and maintaining locator-based tests that break whenever the UI changes.
Applitools moves that work into plain English, and your AI coding agents can write those steps as easily as they write code. Tests are trivial to review because they read like the test case itself, they run deterministically and fast on the DLM, and they have no locators to break. The result is a test suite that keeps pace with AI-driven development instead of slowing it down.
If you would like to see it on your own application, reach out to your Applitools account team. We are happy to walk through a live session and convert one of your existing test cases into plain English together.
