Your Classic tests won’t appear in the Web Editor automatically — they need to be migrated first. Migration is AI-assisted and typically takes minutes, not days.
At a Glance
| Classic | Web Editor + CLI | |
|---|---|---|
| Test format | No-code steps in Stably UI | Playwright TypeScript in Git |
| Editing | Web UI only | Web Editor, CLI, or any IDE |
| Auto-fix | Runtime auto-heal on every run | Post-run Autofix — analyzes root cause, applies a permanent code fix, validates in a real browser |
| AI cost | Auto-heal burns tokens on every execution | AI only invoked when something actually breaks |
| Cost visibility | Limited | Per-run cost breakdown with spending limits |
| Flakiness | Auto-heal can mask underlying timing issues | Deterministic tests with proper wait strategies |
| Debugging | Limited visibility | Full traces, screenshots, DOM snapshots, commit-aware triage |
| Execution | Stably Cloud only | Anywhere — Cloud, CI, or locally with npx playwright test |
| Version control | None | Git-backed with full history |
Key Benefits
Dramatically Lower Costs
Classic auto-heal triggers AI calls on every test execution. These costs compound quickly — especially on scheduled suites — and they’re hard to predict because the amount of healing varies run to run. With the Web Editor + CLI, tests are resilient from the start. AI is only invoked when something genuinely breaks, and Autofix fixes the underlying code so the same issue doesn’t recur. One team eliminated 80–90% of their AI calls after migrating. The auto-heal overhead that had been silently inflating their bill disappeared because their tests no longer needed constant runtime patching. Every run now includes a detailed cost breakdown — AI tokens and browser minutes — so you can see exactly where spend goes. You can also set spending limits to prevent surprise bills.Smarter Auto-Fix
Classic auto-heal patches broken selectors live during each run. If you don’t accept the fix, it triggers again next run, and again the run after that. Autofix takes a different approach:- Root cause analysis — compares recent commits with past runs to pinpoint why tests broke, not just what broke
- Permanent fixes — edits your test code (or application code) rather than patching at runtime
- Validated with proof — re-runs the fix in a real browser and provides screenshots, traces, and DOM snapshots before anything reaches your codebase
- Delivered as a PR — when your repo is connected, fixes arrive as reviewable pull requests
- Grouped by root cause — catches shared issues across multiple failing tests instead of fixing them one by one
Tests Live in Your Codebase
After migrating, your tests are standard Playwright TypeScript in a Git repository — either your own or a Stably-managed one.- Edit anywhere — Web Editor, VS Code, Cursor, or any IDE. Changes sync automatically.
- Review changes — standard code review workflows with diffs, PRs, and branch history
- Run anywhere —
npx playwright testworks out of the box, no Stably dependency required - No lock-in — your tests are Playwright code you own. If you ever leave Stably, the tests still work.
Less Flakiness, Faster Runs
Classic auto-heal can mask flakiness — a test with a timing issue might “pass” after a few retries, but the underlying problem persists and the retries burn credits every run. The Web Editor + CLI produce deterministic tests with proper wait strategies, stable selectors, and the SDK’s AI locator when needed. When a test fails, it fails for a real reason — and you get full traces with screenshots to debug it. Without retry loops, tests also run faster. The Cloud Runner uses auto-scaling infrastructure for parallel execution, and the CLI can connect to dozens of cloud browsers simultaneously.Flexible Test Creation
Classic offers one way to build tests: the no-code editor in the browser. The Web Editor + CLI give you multiple paths depending on your workflow:| Approach | Best for |
|---|---|
| Web Editor AI chat | Quick creation — describe what you want in natural language, iterate conversationally |
| Browser recorder | Capturing real user flows by clicking through your app |
CLI (stably create) | Terminal-first workflows, CI automation, creating tests alongside code changes |
| Your IDE + Stably SDK | Full control — write Playwright tests directly with AI coding assistants like Cursor or Copilot |
FAQ
What happens to my Classic tests?
What happens to my Classic tests?
They remain available but won’t appear in the Web Editor until you migrate them. Migration is AI-assisted — an agent converts your Classic steps to Playwright code, applies compatibility fixes, and commits the result for your review. Most teams complete migration in a single session.
Do I lose the visual editing experience?
Do I lose the visual editing experience?
No. The Web Editor provides the same visual, no-code editing — drag-and-drop steps, click-to-edit selectors, AI assistance — but backed by real Playwright code and Git version control. You can switch between the visual view and code view at any time.
Will my scheduled runs break during migration?
Will my scheduled runs break during migration?
No. Your Classic scheduled runs continue as-is until you’re ready to switch. You can set up new schedules for migrated tests in parallel, verify they work, and then retire the Classic ones on your own timeline.
Can I migrate gradually?
Can I migrate gradually?
Yes. Migrate one suite at a time. Classic and Web Editor tests coexist in the same project during the transition — there’s no all-or-nothing cutover.
Is there any cost to migrate?
Is there any cost to migrate?
The AI-assisted migration uses a small amount of AI credits — negligible for most projects. Contact support if you’d like migration credits applied to your account.
Ready to Migrate?
Migration Guide
Step-by-step instructions — AI-assisted or manual export
Web Editor Quickstart
See the Web Editor in action
CLI Quickstart
Create and run tests from your terminal
Autofix Guide
See how the new Autofix works