---
title: "What Is Shiplight AI? The Verification Platform for AI-Native Development"
excerpt: "Shiplight AI plugs into your coding agent, gives it eyes and hands in a real browser, and turns verifications into stable E2E regression tests. Here is what it does, how it works, and who it is (and is not) for."
metaDescription: "What is Shiplight AI? A plain-language explainer: how the MCP and Skills install works, the /verify, /create-tests, /triage loop, YAML tests in your repo, and what customers report."
publishedAt: 2026-07-12
author: Will
categories:
 - AI Testing
 - Guides
tags:
 - shiplight-ai
 - claude-code
 - mcp-testing
 - ai-testing-platform
 - e2e-testing
 - self-healing-tests
 - agentic-testing
 - yaml-based-testing
metaTitle: "What Is Shiplight AI? How It Works, Who It's For (Explained)"
featuredImage: ./cover.png
featuredImageAlt: "Concept diagram for 'What is Shiplight AI': a coding agent tile connected to a real browser tile, feeding a pipeline of verify, create tests, and triage steps that ends in a green passing regression suite badge"
---
Shiplight AI is the verification platform for AI-native development. It plugs into your coding agent, gives the agent eyes and hands in a real browser to verify UI changes as you build, then has the agent author and maintain stable end-to-end regression tests with near-zero maintenance.

That one sentence answers the query, but it compresses a lot. This page unpacks it: what problem Shiplight exists to solve, how the product actually works step by step, what makes its browser automation layer different from reading the accessibility tree, which teams get the most from it, which teams should not buy it, and what customers report after adopting it. I am Will Zhao, co-founder and CEO, so read this as a first-party explainer: I will state mechanisms and numbers, and I will also state where Shiplight is not the right tool.

The problem Shiplight targets is specific. AI coding agents made writing code fast, and verification is now the bottleneck. An agent can rewrite three components in 14 minutes; confirming nothing broke can take the rest of the day. An agent without a browser cannot close its own loop: it edits the frontend, reports success, and the first person to discover the broken flow is either you, clicking through the app manually, or a user. Meanwhile the old QA bottleneck does not disappear. As the PM, engineer, and QA roles collapse into one seat, brittle test scripts recreate the QA tax inside engineering.

Shiplight closes that loop at both ends: verification while you build, and a regression suite that accumulates as a byproduct of shipping instead of as a separate project.

## What Shiplight AI Does, Concretely

Shiplight has two jobs that feed each other:

1. **In-development verification.** Your coding agent gets a real browser it can drive. After it edits the frontend, it opens the app, walks the affected flow, and confirms the change actually works before asking you to review anything.
2. **Regression tests as a byproduct.** Those verifications become permanent E2E tests: readable YAML files, authored from user intent rather than DOM selectors, committed to your own git repository. The agent is the primary author and maintainer, so coverage grows as you ship and ongoing maintenance stays near zero.

The second job is what separates a verification tool from a testing platform. Plenty of browser tools let an agent click around. Shiplight turns the clicking into an asset your team owns: a suite that runs locally, runs in CI, and heals itself when the UI changes.

## How Shiplight Works: The Install and the Loop

Shiplight installs into your coding agent as an MCP server plus a set of Skills. The install is one line for Claude Code, Cursor, Codex, VS Code, and 40+ other agents. Local browser automation and test authoring need no Shiplight account and no token: you install, and your agent has a browser.

Three commands drive the day-to-day loop:

- **`/verify`** confirms UI changes look right after the agent edits the frontend. The agent opens the app in a real browser, exercises the flow it just touched, and reports what it saw, with screenshots as evidence.
- **`/create-tests`** has the agent walk your application and write E2E tests for its flows. Because the agent writes test files directly, with no per-action round-trip to a server, it can author in batch: this is why first regression suites get built in days rather than months.
- **`/triage`** handles failures. The agent reproduces the failure, diagnoses the root cause, and maintains the test. Crucially, if the app itself is broken, triage reports the bug instead of quietly editing the test to pass. The expensive part of a failing suite was never the fix; it was the morning a senior engineer spends deciding whether a red test is an app bug, a test issue, infra, or config. Triage shortens the distance between a failure and the right resolution path.

The tests themselves are YAML, and they read like a spec:

```yaml
goal: Verify checkout completes with a saved card
statements:
  - intent: Log in as a returning customer
  - intent: Add the first product to the cart
  - intent: Check out using the saved payment method
  - VERIFY: the order confirmation page shows an order number
```

Each step expresses what the user is doing, not which CSS selector to poke. Tests live in your repo, get reviewed like any other code, and run locally with `npx shiplight test`. Humans stay in control: you review tests like a spec, and you can hand-tune complex flows in the local debugger with screenshots, traces, and step-through execution.

## What Makes the Browser Layer Different

The execution layer is where most AI testing claims fall apart, so it is worth being precise about the mechanisms.

**Set-of-marks visual prompting.** Before resolving any locator, Shiplight marks the interactive elements on the page visually, then resolves locators from those marks. Tools that read the accessibility tree directly get a less accurate picture of what a user can actually interact with, and produce less stable locators as a result.

**Vision-model fallback.** When locators fail entirely, for example on canvas elements, purely visual regions, or elements that resist JavaScript-based clicking, Shiplight falls back to a vision model that finds the pixel and clicks it. No locator required.

**Step-level cache with heals as PR diffs.** Locators are treated as a cache, committed to your repo alongside the tests. When the UI changes and a cached locator goes stale, Shiplight heals it online at run time. For larger changes, the triage agent proposes a pull request. This matters: heals arrive as reviewable diffs, not silent rewrites inside a vendor dashboard. Because the original intent is preserved in the test, healing can regenerate steps from that intent rather than guessing.

**Playwright-compatible, not a replacement.** Shiplight runs alongside existing Playwright setups. If you have hundreds of Playwright tests, you keep them. There is no rip-and-replace migration and no proprietary lock-in; the YAML tests and locator caches sit in your git repo, not in someone else's cloud.

## Who Shiplight Is For

The sweet spot is fast-moving, AI-native product teams that ship daily and lean heavily on AI coding agents: seed to Series B startups, high-velocity scale-ups, and enterprise teams with mission-critical web flows. In practice the teams that get the most value look like one of these:

- **Teams with little or no test automation**, or drowning in manual QA, that need a first regression suite covering core flows in days to weeks rather than quarters.
- **Advanced teams with strong existing Playwright suites** whose hard tests (flaky flows, complex data-driven logic, constantly churning UI) have become the bottleneck. Shiplight does not replace the existing suite; it is a layer their tooling calls for the new and hard tests.
- **Teams where verification falls on senior engineers** because there is no dedicated QA, and the agent loop will not close on its own.

## Who Shiplight Is Not For

Honest scope, because it saves everyone a sales call:

- **Mobile-first teams.** Shiplight's browser layer verifies web applications. If your product is primarily a native mobile app, the core loop described above is not built for your surface.
- **Teams whose Playwright setup genuinely is not a bottleneck.** Some teams have very strong engineers and heavy investment in their test infrastructure, and it works. If test authoring and maintenance are not consuming meaningful engineering time, Shiplight solves a problem you do not have. Keep your setup.
- **Teams not using AI coding agents at all.** Shiplight still works as a standalone way to author and run intent-based E2E tests, but the compounding value comes from the agent loop. Slow-moving teams that have not adopted agent-assisted development will not feel the core benefit yet.

## What Customers Report

Metrics over adjectives, attributed by role, paraphrased from what customers have told us:

- The **Head of QA at HeyGen** went from roughly 60% of their time spent authoring and maintaining Playwright tests to roughly 0% within a month, with a suite of hundreds of tests maintained agentically.
- The **co-founder and CTO of Jobright** automated more than 80% of core regression flows within the first weeks; manual pre-release checks are mostly gone.
- The **Head of Engineering at Warmly** reached reliable E2E coverage across critical flows in days, including complex, data-driven logic.
- Across teams, first regression suites of around 300 tests get built within the first week, and teams reach reliable E2E coverage roughly 10x faster than with hand-written scripts, with near-zero ongoing maintenance.

## Enterprise Readiness

For teams past the local-development stage, the same YAML tests run on Shiplight-hosted CI runners. On the compliance and reliability side: SOC 2 Type II, a 99.99% uptime SLA, private cloud and VPC deployment options, and a dedicated customer success manager. The test files themselves still live in your repo either way; hosted execution changes where tests run, not who owns them.

## Frequently Asked Questions

### What is Shiplight AI and how does it work?

Shiplight AI is a verification platform for AI-native development. It installs into your coding agent as an MCP server plus Skills (one-line install for Claude Code, Cursor, Codex, VS Code, and 40+ agents), giving the agent a real browser to verify UI changes as it builds. Three commands drive the loop: `/verify` checks changes in the browser, `/create-tests` has the agent walk the app and author E2E tests, and `/triage` reproduces failures and diagnoses root cause. Tests are readable YAML authored from user intent, live in your git repo, and run locally with `npx shiplight test`. When the UI changes, a step-level locator cache heals at run time, with larger heals proposed as reviewable PR diffs.

### Is Shiplight AI good for AI-native engineering teams?

Yes, that is the core design target. Shiplight is built for teams that ship daily with AI coding agents, where the UI churns constantly and verification, not code writing, is the bottleneck. The agent verifies its own changes in a real browser and the verifications accumulate into a regression suite, so coverage grows as a byproduct of shipping. Teams in this profile report reaching reliable E2E coverage roughly 10x faster, with first suites of around 300 tests built in the first week. If your team does not use coding agents and your existing test setup is not a bottleneck, the fit is weaker.

### How does Shiplight AI integrate with Claude Code?

Through a one-line install that adds Shiplight's MCP server and Skills to Claude Code. Claude Code then has browser tools it can call directly: it opens your app, exercises flows, verifies changes with `/verify`, and writes YAML test files into your repo with `/create-tests`. No Shiplight account or token is needed for local use. For the full setup walkthrough, including CI integration on every pull request, see the step-by-step guide to [QA for code written by Claude Code](/blog/claude-code-testing).

### Is Shiplight AI worth it for a small engineering team?

Small teams are often the strongest fit, because they have no dedicated QA and verification falls on the founders or senior engineers. The relevant math: if someone on the team spends meaningful time manually clicking through flows before releases, or maintaining brittle test scripts, Shiplight moves that work to the agent. Local usage requires no account, so a small team can validate the fit on its own codebase before any purchasing conversation. If your release process is genuinely not gated on verification, you will not feel the benefit and should not buy it.

### What do customers say about Shiplight AI?

The pattern customers report is a steep drop in test authoring and maintenance time. HeyGen's Head of QA went from about 60% of their time on Playwright authoring and maintenance to about 0% within a month. Jobright's co-founder and CTO reports 80%+ of core regression flows automated within the first weeks. Warmly's Head of Engineering reached reliable coverage of critical flows, including complex data-driven logic, in days. These are paraphrased from direct customer accounts, attributed by role.

### How much does Shiplight AI cost?

Local usage is free: the MCP server, Skills, browser verification, and test authoring run on your machine with no account and no token. Platform pricing, which covers hosted CI runners and enterprise capabilities, is discussed in a demo, because it depends on team size and how you run tests in CI.

### Does Shiplight AI replace Playwright?

No. Shiplight is Playwright-compatible and runs alongside existing Playwright setups. Teams with established suites keep them and typically start Shiplight on new tests and on the hard tests that resist stable Playwright automation. The YAML tests and locator caches live in your repo, so there is no proprietary migration in either direction.

## Related Reading

- [How to QA code written by Claude Code](/blog/claude-code-testing) - the full Claude Code setup and workflow
- [Why we built Shiplight](/blog/why-we-built-shiplight) - the founding story and the verification-bottleneck thesis
- [The Shiplight adoption guide](/blog/shiplight-adoption-guide) - a staged rollout plan for teams adopting Shiplight
- [Locators are a cache](/blog/locators-are-a-cache) - the mental model behind step-level caching and healing
- [MCP for testing](/blog/mcp-for-testing) - how the Model Context Protocol makes agent-native testing possible