An AI generated Page Object Model can save time, especially when you are starting a new Selenium framework or cleaning up a test suite that has grown messy. AI tools are good at drafting class structure, suggesting method names, and turning repeated UI steps into reusable functions. The risk is that the first draft often looks cleaner than it really is. A generated page object may hide weak locators, mix assertions with actions, expose too much page internals, or hard-code assumptions that break as soon as the UI changes.

This tutorial explains when AI-generated page objects are useful, where they commonly go wrong, and how QA engineers and SDETs should review them before they become part of a real automation suite. The goal is not to reject AI assistance. The goal is to use it as a drafting tool while keeping maintainability, readability, and reliability under human control.

What an AI generated Page Object Model is supposed to solve

The Page Object Model, usually called POM, helps organize UI automation by putting page-specific locators and actions into dedicated classes. Instead of writing selectors directly in every test, the test calls methods such as loginPage.enterUsername() or checkoutPage.submitOrder(). This reduces duplication and makes UI changes easier to manage.

AI can help because the pattern is predictable. If you give a model a page screenshot, HTML snippet, or an existing test flow, it can usually draft a page class with fields, locators, and action methods quickly. That is useful when:

  • You need a starting point for a new module.
  • You are migrating raw Selenium scripts into a cleaner framework.
  • You want naming suggestions for repetitive interaction methods.
  • You need help spotting duplicated page actions across tests.

Used this way, AI is a productivity accelerator. Used carelessly, it becomes a duplication machine that spreads bad framework decisions across dozens of files.

Why AI-generated page objects often look better than they are

The biggest problem with an AI generated Page Object Model is that generated code often matches surface conventions without understanding the deeper design intent. A class may compile and still be a poor page object. For example, the model may create methods that click elements and immediately assert success, combine navigation with validation, or expose ten locator getters that allow tests to reach inside the page object and bypass the abstraction.

  • Brittle locators: long CSS chains, text-dependent XPath, or selectors tied to styling classes.
  • Mixed responsibilities: actions, assertions, test data creation, and navigation all in one class.
  • Weak naming: generic methods like clickButton() that do not describe business intent.
  • Timing shortcuts: broad waits or fixed delays instead of waiting for meaningful UI state.
  • Overexposed internals: public WebElements everywhere, which makes tests tightly coupled to the DOM.

That is why a green test run after generation is not enough. You need to review whether the abstraction will stay understandable six months later when more tests depend on it.

A bad example of AI-generated POM design

Here is a pattern QA teams should be careful with. It is common in AI-generated drafts because the model tries to be “helpful” by doing too much in one method.

public class LoginPage {
    WebDriver driver;

    @FindBy(xpath = "//input[@placeholder='Email']")
    WebElement email;

    @FindBy(xpath = "//input[@placeholder='Password']")
    WebElement password;

    @FindBy(xpath = "//button[text()='Login']")
    WebElement loginButton;

    @FindBy(css = ".dashboard-title")
    WebElement dashboardTitle;

    public void login(String user, String pass) {
        email.sendKeys(user);
        password.sendKeys(pass);
        loginButton.click();
        assert dashboardTitle.isDisplayed();
    }
}

This looks compact, but it mixes page interaction with a business assertion. It also uses fragile selectors based on placeholder text and button text. If the UI wording changes, the page object breaks even when the workflow is still valid.

A better review target for Selenium teams

A stronger page object keeps actions focused and exposes behavior, not DOM detail. The test can decide what to assert, while the page object handles reliable interaction and synchronization.

public class LoginPage {
    private final WebDriver driver;
    private final WebDriverWait wait;

    private final By emailInput = By.cssSelector("[data-testid='login-email']");
    private final By passwordInput = By.cssSelector("[data-testid='login-password']");
    private final By submitButton = By.cssSelector("[data-testid='login-submit']");

    public LoginPage(WebDriver driver) {
        this.driver = driver;
        this.wait = new WebDriverWait(driver, Duration.ofSeconds(10));
    }

    public LoginPage open(String baseUrl) {
        driver.get(baseUrl + "/login");
        wait.until(ExpectedConditions.visibilityOfElementLocated(emailInput));
        return this;
    }

    public DashboardPage loginAs(String user, String pass) {
        driver.findElement(emailInput).sendKeys(user);
        driver.findElement(passwordInput).sendKeys(pass);
        driver.findElement(submitButton).click();
        return new DashboardPage(driver);
    }
}

This design is not perfect for every framework, but it is easier to maintain. It uses stable automation-friendly selectors, keeps the method names business-oriented, and returns the next page object instead of performing assertions that belong in the test layer.

How to review an AI generated Page Object Model

When reviewing AI-generated page objects, use a checklist instead of relying on intuition. Review the class like framework code, not just like a one-off test helper.

  • Check locator quality: prefer IDs or data-testid attributes created for automation.
  • Check abstraction boundaries: page objects should expose actions and state queries, not every raw element.
  • Check method responsibility: one method should do one meaningful UI action or return one meaningful state.
  • Check wait strategy: waits should be tied to visible or interactive state, not fixed timing assumptions.
  • Check naming: method names should describe user intent such as applyCoupon or submitLogin.
  • Check reuse: repeated widgets such as headers, modals, and tables may deserve component objects instead of copy-paste locators.

If the generated class fails three or four of these checks, it is usually faster to refactor immediately than to let the design spread to the rest of the framework.

Common mistakes QA teams make after generation

  • Merging the first draft: generated code is a starting point, not a final framework standard.
  • Letting tests assert inside page objects: this hides intent and makes failures harder to diagnose.
  • Ignoring page components: complex apps need reusable component objects, not one giant page class.
  • Copying selectors from unstable markup: the AI only knows what you gave it, and many HTML samples are not automation-friendly.
  • Skipping framework consistency: one generated class may use a style that conflicts with the rest of the suite.

The short-term speed gain disappears if every generated file introduces a slightly different pattern.

Best prompts for AI-assisted POM drafting

If you want better output from AI, prompt it with your framework rules instead of only describing the page. Tell the model what good looks like in your codebase.

Create a Selenium Java page object for the login page.
Use data-testid selectors when possible.
Do not place assertions in the page object.
Return the next page object after successful submission.
Use explicit waits only where page readiness matters.
Keep methods business-oriented and avoid exposing WebElement fields.

This kind of prompt narrows the model toward maintainable output. Even then, review is still required because the HTML sample or page assumptions may still be wrong.

When AI-generated page objects are worth using

An AI generated Page Object Model is useful when the team already has framework standards and wants help drafting repetitive structure. It is less useful when the team has not agreed on its abstraction rules, locator strategy, or synchronization model. In that situation, AI tends to amplify confusion rather than resolve it.

  • Use AI for first drafts, migration support, and refactoring suggestions.
  • Do not use AI output as the source of truth for framework architecture.
  • Require human review for selectors, method boundaries, waits, and naming.
  • Treat repeated review comments as rules to include in future prompts.

Conclusion

So, is an AI-generated page object model good or bad? The practical answer is that it can be good as a draft and bad as an unchecked framework decision. AI is strong at generating structure, but weak at understanding which abstractions will stay stable as your product and test suite evolve.

For QA engineers and SDETs, the best workflow is simple: let AI generate the first version, then review it with the same discipline you would apply to any shared automation framework code. That is how an AI generated Page Object Model becomes a productivity boost instead of technical debt.