--- title: "How to Adopt Shiplight AI: A Practical Guide to the MCP Server and Skills, CI, and YAML Tests" excerpt: "Modern QA has a new constraint: software changes faster than test suites can keep up." metaDescription: "How to adopt Shiplight AI: start with the MCP server and Skills in your coding agent, put YAML tests in CI on hosted or your own runners, and run beside an existing Playwright suite." publishedAt: 2026-03-25 updatedAt: 2026-08-10 author: Shiplight AI Team categories: - Engineering - Enterprise - Guides - Best Practices tags: - e2e-testing - shiplight-ai - two-speed - email - mcp - intent metaTitle: "How to Adopt Shiplight AI: A Practical Guide" featuredImage: ./cover.png featuredImageAlt: "Illustrated Shiplight blog cover: a glossy onboarding path of stepping stones leading up to a bright green productive verified state." related: - '[what is Shiplight AI and how it works](/blog/what-is-shiplight)' - '[best AI testing tools in 2026](/blog/best-ai-testing-tools-2026)' - '[Playwright alternatives](/blog/playwright-alternatives-no-code-testing)' - '[What Shiplight costs](/blog/how-much-does-shiplight-cost), plans, rates, and a real month' --- Modern QA has a new constraint: software changes faster than test suites can keep up. That is true even in disciplined teams with solid automation. It is even more true when AI coding agents are shipping UI changes at high velocity. The result is familiar: end-to-end coverage that starts strong, then collapses under maintenance, flaky selectors, and slow feedback loops. **Shiplight AI was built for this reality.** It combines agentic, AI-native execution with approachable authoring workflows so teams can scale end-to-end coverage with near-zero maintenance, without forcing everyone into a single way of working. This post breaks down the three primary ways teams adopt Shiplight, what each is best for, and how they fit together in a real rollout. ## The core idea: keep the test intent human, make execution resilient Traditional UI automation tends to bind test reliability to implementation details: selectors, DOM structure, and brittle assumptions about page timing. Shiplight flips the model. Tests are expressed as user intent in natural language, and the system resolves that intent at runtime, then stabilizes execution with deterministic replay where it matters. In practice, that gives you a spectrum: - **Natural-language steps** that are readable and easy to author. - **Deterministic replay** when you want speed and consistency. - **Self-healing behavior** when the UI shifts and cached locators go stale. That foundation shows up across every Shiplight surface: your coding agent, the CLI, CI, and Shiplight Cloud. ## Option 1: Shiplight's MCP Server and Skills for AI coding agents and local verification If your team uses AI coding agents in an IDE or CI workflow, start here. **Shiplight's MCP server and Skills** are designed to work alongside AI coding agents. The intent is simple: your agent implements a feature, opens a real browser, verifies the change, and can generate end-to-end tests as part of the same loop. ### When MCP is the best fit - You want **fast UI verification during development**, not after the PR is opened. - You are building with tools like **Claude Code, Cursor, or Windsurf**. - You need a practical way to reduce “looks good to me” approvals by replacing them with evidence. ### What it looks like day to day Install Shiplight as an MCP server plus a set of Skills, one line. Your agent can then drive a browser session, take screenshots, and click through flows, and it can use AI-powered actions when you supply a model key. One detail that matters more than it sounds: for authenticated apps, log in once manually and save the browser storage state. The agent reuses that session instead of re-authenticating on every run. ## Option 2: Run the tests in CI Local verification is where Shiplight starts. CI is where that coverage turns into a release gate. Tests run with `npx shiplight test`, so CI runs the same command your machine does. There are two ways to host it. ### Shiplight-hosted runners Install the Shiplight GitHub App, then set `runs-on: shiplight-small` (or `-medium`, `-large`, `-xlarge`). The runner arrives with the browser and credentials already in place, so the job is a checkout, `npx shiplight test`, and `npx shiplight report` to upload results. ### Your own runners Shiplight also runs on stock `ubuntu-latest`, and on GitLab, CircleCI, Jenkins, Buildkite, Azure DevOps, and Travis. You supply the LLM key and install the browser yourself. Nothing about that path is gated behind a plan. Either way the tests are the same YAML files in your repository, so moving between them changes the workflow file, not the suite. ### What a Shiplight Cloud account adds An account is not required to author or run tests. It gives you the shared layer: test results and history, analytics, hosted CI runners, API tokens, organization and member management, and billing. That is a reason to sign up once the team needs it, not a prerequisite for trying it. ## Option 3: Run beside an existing Playwright suite Some organizations already have meaningful automation coverage in Playwright. Rewriting that suite into a brand-new system is rarely the best ROI. Shiplight's YAML tests transpile to Playwright at run time, so they run side by side with the tests you already have. You get AI-native execution, stabilization, and reliability on the new and hard flows, and every test stays in code and inside normal review workflows. ### When this is the best fit - Your tests must remain **code-first** and live with the repo. - You want AI to improve execution and reduce flakiness, without changing how engineers structure the suite. - You want a path that preserves governance, review, and deterministic behavior in CI. ## The connective tissue: YAML tests you can read and debug Shiplight supports a pragmatic “start local, scale when you need to” approach. ### YAML tests that stay readable Tests are written in YAML as natural-language steps, with action entities and locators for deterministic replay. Locators act as a cache: a cached step replays at full speed and calls no model, and the agentic layer falls back to the original intent when a cached locator goes stale. ### A local debugger for the hard flows When a flow needs more than the agent produced on its own, step through the `*.test.yaml` file locally with screenshots and traces, and hand-tune the steps inline. Humans stay in control: the test is a file in your repo, reviewed like a spec. ## Enterprise considerations: security, reliability, and deployment flexibility Enterprise adds SOC 2 certification, encryption in transit and at rest, role-based access control, immutable audit logs, and a plus private cloud and VPC deployment and a dedicated CSM. ## A simple adoption plan that works in the real world If you want a rollout that avoids a long QA “platform migration,” use this sequence: 1. **Install into your coding agent** and run `/shiplight verify` on work you are already doing. No account, no token, nothing to procure. 2. **Standardize a few YAML flows** for your most valuable user journeys, with `/shiplight create-yaml-tests`. 3. **Put them in CI** so every pull request runs them, on Shiplight-hosted runners or your own. 4. **Add coverage beside an existing Playwright suite** where you already have strong tests and want the new flows without rewrites. None of those steps is a migration. Each is useful on its own, and you can stop at any of them. ## Key Takeaways - **Verify in a real browser during development.** Shiplight lets AI coding agents validate UI changes before code review. - **Generate stable regression tests automatically.** Verifications become YAML test files that self-heal when the UI changes. - **Reduce maintenance with AI-driven self-healing.** Cached locators keep execution fast; AI resolves only when the UI has changed. - **Integrate E2E testing into CI/CD as a quality gate.** Tests run on every PR, catching regressions before they reach staging. ## Get Started - [Try Shiplight](/coding-agents) - [Book a demo](/demo) - [YAML Test Format](/yaml-tests) - [Enterprise features](/enterprise) References: [Playwright Documentation](https://playwright.dev), [SOC 2 standard](https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2), [GitHub Actions documentation](https://docs.github.com/en/actions), [Google Testing Blog](https://testing.googleblog.com/) ## Frequently Asked Questions ### What is the smallest useful first step? Install the MCP server and ask your coding agent to verify one change in a real browser. Local runs need no account, so this happens before any procurement conversation. ### Do I have to replace my Playwright suite? No. The tests transpile to Playwright and run beside an existing suite, so adoption is additive rather than a migration. ### Where do the tests live? In your git repository, as YAML, reviewed in the same pull request as the change they cover. ### What should exist before rolling this out more widely? One flow covered end to end, running in CI, that someone other than the author can read. Everything after that is repetition.