User Stories to Playwright TypeScript Specs with AI (2026)

Every SDET has a backlog of user stories that describe exactly what a test should do, and a shortage of hours to write those tests by hand. The obvious move in 2026 is to close that gap with AI: feed a Jira ticket or Gherkin scenario in, get a Playwright TypeScript spec out. The trap is that a naive prompt produces a wall of brittle, one-off selectors that costs more to maintain than it saved to generate. The fix is a pipeline built around the Page Object Model with a review gate at the end. This post walks the pipeline, shows why POM is the linchpin, and includes a full worked example from a Gherkin scenario to a .spec.ts.

This builds on our pillar, Building a Self-Operating QA Agent with Playwright MCP, and on the generator role in The Tri-Agent Testing Pipeline. For prompt fundamentals, see Prompt Engineering for QA and Test Automation.

What does the story-to-spec pipeline look like?

The pipeline has four stages, and each one exists to remove ambiguity before code is trusted.

1. Source: ticket or Gherkin. A Jira ticket or, better, a Gherkin scenario states the intent - preconditions, actions, expected outcomes.
2. Structured prompt. The source is wrapped with your conventions: POM rules, existing page-object signatures, a locator policy, and a required output shape.
3. Generation. The LLM emits a .spec.ts and, if needed, new or extended page objects.
4. Review gate. A human confirms it compiles, reuses page objects, asserts meaningfully, and runs green before merge.

Gherkin is the better source because it is already structured. A free-text ticket forces the model to guess the boundaries of the behavior; a scenario states them. If your team writes tickets, a cheap first step is having the model draft Gherkin from the ticket, then a human tightens it before generation.

Why does the Page Object Model matter so much here?

Ask an LLM for a Playwright test with no structure and it will inline a selector for every interaction. Ten specs later you have the same login selector copy-pasted ten times, and the next UI change breaks all ten. The Page Object Model solves this the same way it does for hand-written tests, but it matters more for generated code because volume amplifies the maintenance cost.

POM does two jobs in an AI pipeline:

• It centralizes selectors. Every locator lives in a page object. When the UI changes you fix one method, not every spec that touches that element.
• It constrains the model. When you hand the LLM the signatures of your existing page objects, it reuses loginPage.login(user, pass) instead of re-deriving how to log in from scratch. That single move is the difference between generated code that fits your repo and generated code you rewrite.

The rule of thumb: the spec should read like plain intent, and every selector should live behind a page-object method.

What goes in the prompt?

A good prompt ships your codebase’s conventions so the output matches. At minimum:

• The Gherkin scenario or ticket.
• Your POM conventions - one class per page, selectors as private fields, actions as public async methods.
• The signatures of relevant existing page objects so the model reuses them.
• A locator policy: prefer getByRole, getByLabel, and getByText; avoid brittle CSS and XPath.
• The required output: which files, in what shape.

The locator policy is worth enforcing hard. Role- and label-based locators are dramatically more resilient than CSS, and it costs nothing to make the model default to them. We cover why in Accessibility-Tree Driven Locators for Resilient Tests.

Worked example: from Gherkin to a spec

Start with the scenario the pipeline receives.

Feature: Checkout
  Scenario: Registered user completes a purchase
    Given a registered user is logged in
    And the cart contains a "Mechanical Keyboard"
    When the user proceeds to checkout
    And submits valid shipping and payment details
    Then an order confirmation with an order number is shown

The pipeline generates a page object first. Notice selectors are role- and label-based and confined to this file.

// pages/CheckoutPage.ts
import { type Page, type Locator, expect } from '@playwright/test';

export class CheckoutPage {
  private readonly page: Page;
  private readonly checkoutButton: Locator;
  private readonly shippingName: Locator;
  private readonly cardNumber: Locator;
  private readonly placeOrder: Locator;
  private readonly confirmation: Locator;

  constructor(page: Page) {
    this.page = page;
    this.checkoutButton = page.getByRole('button', { name: 'Proceed to checkout' });
    this.shippingName = page.getByLabel('Full name');
    this.cardNumber = page.getByLabel('Card number');
    this.placeOrder = page.getByRole('button', { name: 'Place order' });
    this.confirmation = page.getByRole('heading', { name: /order confirmed/i });
  }

  async proceedToCheckout(): Promise<void> {
    await this.checkoutButton.click();
  }

  async submitDetails(name: string, card: string): Promise<void> {
    await this.shippingName.fill(name);
    await this.cardNumber.fill(card);
    await this.placeOrder.click();
  }

  async orderNumber(): Promise<string> {
    await expect(this.confirmation).toBeVisible();
    return (await this.page.getByTestId('order-number').textContent()) ?? '';
  }
}

Then the spec, which reuses existing page objects (LoginPage, CartPage) and reads as pure intent. Each Gherkin clause maps to a line.

// tests/checkout.spec.ts
import { test, expect } from '@playwright/test';
import { LoginPage } from '../pages/LoginPage';
import { CartPage } from '../pages/CartPage';
import { CheckoutPage } from '../pages/CheckoutPage';

test('registered user completes a purchase', async ({ page }) => {
  const login = new LoginPage(page);
  const cart = new CartPage(page);
  const checkout = new CheckoutPage(page);

  // Given a registered user is logged in
  await login.goto();
  await login.login('[email protected]', 'correct-horse');

  // And the cart contains a "Mechanical Keyboard"
  await cart.addItem('Mechanical Keyboard');

  // When the user proceeds to checkout and submits valid details
  await checkout.proceedToCheckout();
  await checkout.submitDetails('Ada Lovelace', '4111111111111111');

  // Then an order confirmation with an order number is shown
  const orderNumber = await checkout.orderNumber();
  expect(orderNumber).toMatch(/^ORD-\d+$/);
});

The mapping is deliberate: Given becomes setup and navigation, When becomes page-object actions, Then becomes expect assertions. That is the entire translation rule, and it is why Gherkin is such a clean input.

What are the review gates?

Generation gets you a draft. Never merge a draft. Enforce gates in this order because each is cheaper than the next.

Automate the first three in CI. The last two need a human, at least until you trust a run enough to sample rather than review every spec.

Where does the AI struggle, and how do you compensate?

Being honest about the failure modes is what keeps this pipeline trustworthy. LLMs are strong at translating a well-formed scenario into idiomatic Playwright and weak in a few predictable places.

• Ambiguous tickets. Given a vague story, the model invents behavior to fill the gaps. The fix is the source stage: turn tickets into explicit Gherkin before generation so there is nothing to guess.
• Missing edge cases. A scenario describes the happy path, so the generated spec covers the happy path. Negative cases - invalid card, empty cart, expired session - need their own scenarios. Prompt the model to suggest edge cases, then a human decides which become tests.
• Over-assertion on brittle text. Models love asserting exact copy that marketing changes weekly. Steer them toward asserting structure and role - that a confirmation heading exists - rather than a specific sentence.
• Selector invention. Even with a locator policy, a model will occasionally reach for CSS when it cannot infer a role. The compile and locator-policy gates catch this before it lands.
• Tautological assertions. The classic expect(true).toBe(true). Only a human reviewing against the Then clause reliably catches a check that always passes.

The pattern across all of these: push structure upstream into the source and prompt, and keep a human on the assertions downstream. The model fills the middle well; the ends are where judgment lives.

Where does this fit in a 2026 SDET workflow?

The teams getting real leverage from this in 2026 wire generation into their definition of done. When a story is specced, its Gherkin is written; when the Gherkin is approved, the pipeline drafts the spec and page objects; an SDET reviews at the gate and merges. The model does the typing, the Page Object Model keeps the output maintainable, and the review gate keeps it trustworthy.

Start with the pillar guide to see where generation sits in the larger agent workflow, and pair this with The Tri-Agent Testing Pipeline if you want a planner feeding scenarios in and a healer maintaining specs after they land. Generate the draft, gate the merge, and let POM absorb the churn.