The point of AI-first execution
Traditional test automation says: take a manual test case, ask a programmer to rewrite it as code, then keep paying that programmer every time the page changes. The programmer becomes the bottleneck for what is fundamentally QA work.
AI-first execution flips this. The manual description is the canonical artifact. An AI agent reads it, drives the browser, makes the assertions, and reports a verdict — the same way a human QA tester would, but without the click-through fatigue. Updates to the test are updates to the description. Anyone on the team who can write a clear English step can edit, add, or fix a test.
The programmer cost disappears because there's no code to maintain. The cases that do need a programmer (because they hit an API you control, or check a database row) can have a small fixture written once and reused — but that's a small minority of any real test suite.
"The test description is the test. Editable by anyone who can write a clear step."
What a case looks like
The same case you already have in TestRail or a wiki — formatted as plain steps. No translation. The AI treats each step as a directive to figure out and execute.
The AI handles the actual locators — finding the right "Sign in" link, the right email field, the right
button to submit. If your page changes (the link moves, the label updates, a banner appears that wasn't
there), the AI adapts on the next run. No selector to update; no brittle By.xpath string to fix.
vs. classic test automation
Both paths take the same input. They diverge on who owns the suite over its lifetime.
Classic code-based
Selenium · Playwright · CypressA programmer converts each manual case to code, lives with the conversion, and is on the hook every time a selector breaks.
Updates require the programmer (or someone who can read the framework). Test edits go through PR.
Maintenance compounds — every selector that drifts is a tiny ticket.
Faster on first run; cheaper at startup; brittle over time.
AI-first execution
Manual cases as-isNo conversion step. The case is the test. The AI reads it and drives the browser.
Updates are edits to the description. The QA lead, the PM, or anyone who can write a step can modify a test.
Maintenance is near-zero for typical UI drift — the AI adapts on the next run.
Slower per individual run; broadly cheaper over the suite's life; resilient to drift.
What the AI flags as missing
Manual test cases describe the happy path. They rarely describe what the page looks like, what data the test assumes, or what state the user is in. The AI runs into those gaps constantly and is built to ask, not to guess.
Before the first run — during the import + tidy phase — the AI flags ambiguities it can't resolve from the case alone. A step that says "verify the dashboard shows today's orders" without saying what timezone "today" means. A precondition "user has a saved payment method" without saying how to get there. An expected result "order confirmation appears" when two different confirmation banners exist on your real site. All flagged as one-line questions for your team rather than silently guessed.
During the burn-in — when each case runs against your real site — the AI catches a different class of gap. A step says "click the Profile link" but Profile is now under a "More" dropdown. A login expects an MFA code that wasn't in the test data. A flow assumes the user starts logged out but the previous test left them logged in. Each one becomes a clarifying question with a screenshot of the page state and a one-line ask.
These questions are the most valuable artifact of the sprint after the runnable suite itself. They surface gaps in your test cases and your tribal-knowledge documentation that a human tester would just figure out and move on from. Now they're written down. Your team answers each one in a sentence, the case re-runs, and the documentation gets better as a side effect.
What the sprint delivers
A 30-day engagement that turns the manual-case pile into a runnable AI-first suite — and trains the team to keep it that way without us.
- Import + tidy — pull cases from TestRail / Xray / your wiki / spreadsheets / PDFs. Normalize the step format so the AI runs them reliably without changing intent.
- First full run — every case runs against your real site. Per-case verdict, screenshot of the outcome, and a triage list of cases that need clarification before they can run reliably.
- Triage pass — together we resolve the cases the AI flagged — usually one sentence of clarification per case is enough. After the pass, your suite stabilizes.
- Hand-off — your team owns the suite. They edit cases in plain English. New cases get added the same way. The runner runs on your schedule (nightly, per-merge, on-demand).
- Optional code export — if you want code-based artifacts for any subset, we generate them. Not required; many teams stay AI-first end-to-end.
Connect to what you have
- TestRail / Xray import — connect via API and pull cases by project, suite, or section. Steps, expected results, and metadata come over intact.
- File upload — drop a folder of PDFs, markdown, CSVs, or spreadsheets. The importer normalizes them into the same case shape.
- Reverse-proxy connection — staging or internal sites behind a firewall? We stand up a one-way reverse proxy that lets the runner reach your environment without us touching your network. Configure once, run the sprint, tear it down.
- Almost any artifact — if it looks like a test case in any structured way, the importer accepts it. Send a sample if you're unsure.
Beyond the test conversion
Lifting the manual suite into AI-first execution is the headline. The sprint also runs an AI-driven quality assessment alongside the lift — broader coverage than your manual cases ever covered, plus an overall AI-strategy read for your QA practice.
- AI bug detection — fully automated bug-hunting on your real site across personas, UX, accessibility, perf, and content. Surfaces issues your manual cases aren't looking for.
- Risk assessment — four-dimensional read on code blast-radius, GenAI smell, user frustration, and business risk.
- Quality scoring — multi-attribute jank score across 12 dimensions.
- Competitive quality metrics — how your site benchmarks against peers in your industry. Issue counts, severity, persona-rated UX, perf, and accessibility compared to a curated peer set. You see where you stand, not just where you are.
- AI-strategy recommendations — based on what the assessment surfaced: which cases to write next, where AI is high-confidence vs needs a human, which dimensions to invest in.
The math, manual-first
Three buckets, not one. Conversion savings are visible. Manual execution savings dominate for manual-first teams — most teams pay more for the human running the test than for everything else combined.
Bucket 1 — Conversion savings (one-time)
Pay a programmer to convert the high-priority subset to code: ~25 minutes per case at $125/hour = $10,000 of hand-work over a month for ~100 cases. The AI-first sprint matches the cost, skips the code-conversion step entirely, and leaves your cases editable by anyone on the team.
Bucket 2 — Maintenance savings (annual, compounding)
Classic code-based suites cost ~$9,000/year per ~100-case suite just to keep green — selectors rot, framework versions break old tests, deprecated APIs need swapping. AI-first execution cuts this further still — the AI runner adapts to drift rather than failing on it. Conservatively a 60–80% drop in test-maintenance cost over three years vs classic automation — and effectively 100% vs the "no maintenance, we just keep manual" status quo, because you were already paying for that maintenance in human execution time.
Bucket 3 — Manual execution savings (per release, compounding — biggest bucket)
The biggest cost in manual-first teams is the time spent running the cases by hand before each release. A typical pass is 30–60 minutes per case for a manual tester if you include setup, teardown, and writing up the result — call it 40 minutes average. At $75/hour for a manual tester, a 100-case smoke pass is $3,000–$5,000 per release. Monthly releases = ~$45,000/year on manual execution alone. Quarterly + per-hotfix passes push that higher. Automated AI execution is essentially free per run.
Three-year picture for a typical manual team
$10K sprint · ~$15K saved on conversion vs the code-based alternative · ~$25K saved on maintenance · ~$135K saved on manual execution. For manual teams, the execution-time bucket is the dominant payoff by an order of magnitude — and it compounds every month you ship.
The dollar gap widens over time. Maintenance is the part of test automation that compounds; AI-first execution removes most of it. The bigger win — manual execution at scale — never stops paying.
Or you might want…
Two sibling paths cover the code-based starting points if you have an existing automation suite.
Send us the wiki page. We'll run it.
A 30-minute scoping call covers what's in your manual backlog, whether AI-first execution is the right call for your team, and whether the sprint fits this quarter.
Book a scoping call →