Platform
Automated QA for serious AI software delivery
Every AI-written change gets tested the way a user would experience it — in a real browser, before it ships and after it lands.
Ciao QA is the automated testing layer of the platform: deterministic browser replays, self-healing tests, smoke gates before publish and production checks after publish. Unlike test suites that rot as the application changes, Ciao's tests repair themselves when the UI evolves — so coverage keeps pace with AI-speed development instead of falling behind it.
Published 2026-07-03 · Last updated 2026-07-03
AI writes faster than humans can test
AI-assisted development moves the bottleneck. Code that used to take a sprint arrives in an afternoon — and every one of those changes can break checkout, login or the report a director reads every Monday. Manually clicking through the app does not scale to that pace, and traditional test suites decay the moment the UI shifts under them.
Ciao QA is built for that pace. It runs deterministic browser replays, self-healing tests, smoke gates before publish and production checks after publish — automatically, on every change, as part of the same loop that wrote the code.
How QA works
QA runs as part of the delivery loop — nothing here is a separate tool to adopt or a pipeline to maintain.
1. Flows are captured as replays
Key user journeys — sign in, create a record, check out — are captured as deterministic browser replays: the same steps, the same inputs, the same expected results, every run.
2. Tests run in a real browser
Replays execute against the actual application the way a user would experience it — real rendering, real network, real auth — not against mocked components.
3. Tests heal instead of rot
When the UI legitimately changes — a button moves, a label is reworded — self-healing tests update themselves to match the new reality instead of failing on a stale selector and getting deleted.
4. Smoke gates hold the door
Before any publish, smoke gates run the critical replays. A failing gate stops the publish, so the broken version does not ship through it.
5. Production checks close the loop
After publish, checks run against the live application to confirm the release behaves in production, where configuration and data are real.
6. Failures come back as work
A failed check lands back in the loop with context — which step failed and what was expected — where the fix can be built and re-verified.
Why it matters
Deterministic matters because flaky tests train teams to ignore red. When a replay fails, something actually changed — which makes the signal worth acting on and the gate worth trusting.
Self-healing matters because the alternative is a suite that dies quietly. Coverage that maintains itself keeps pace with AI-speed change, so the hundredth change is tested as thoroughly as the first. And gates on both sides of publish mean "it worked in preview" and "it works in production" are both verified, not assumed.
The habit this builds is the point. When every publish is gated and every release is checked in production, shipping stops being an act of courage. Teams make more changes, in smaller pieces, because the cost of being wrong is a stopped publish rather than a broken Monday — and the audit trail shows every gate each release passed.
Who uses it
QA is one of the six roles in Ciao's AI software organization, and different people lean on it differently.
- Non-engineers shipping real apps — People who cannot be expected to write test suites get one anyway — captured from the flows their app actually has.
- Engineering leaders — Gates instead of promises: a publish that failed its smoke gate does not go out, whoever requested it.
- Agencies — Every client application gets protected journeys without a per-project QA budget or a hand-maintained suite per client.
- Operations and support teams — Production checks catch regressions in the live app, so problems surface as findings rather than support tickets.
Security and governance notes
- ✓ Smoke gates run before every publish; production checks run after.
- ✓ Replays are deterministic — same steps, same data, same expected outcome each run.
- ✓ Self-healing keeps coverage alive as the UI evolves.
- ✓ QA results feed project health in Conductor, visible across the fleet.
- ✓ Test outcomes join the append-only audit trail alongside merges and deploys.
A hand-maintained suite vs Ciao QA
The contrast with a hand-maintained suite is structural, not cosmetic.
| Hand-maintained test suite | Ciao QA | |
|---|---|---|
| Authoring | Engineers write and update scripts | Flows captured as replays as the app is built |
| UI changes | Selectors break; tests get skipped | Tests self-heal to match the new UI |
| Before release | CI runs if someone wired it up | Smoke gates stop a failing publish |
| After release | Monitoring, if configured | Production checks verify the live app |
| Flaky failures | Re-run and hope | Deterministic replays — red means something changed |
Frequently asked questions
What does deterministic mean here?
Replays run the same steps with the same inputs and the same expectations every time. A failure therefore means the application changed, not that the test wobbled — which is what makes gating a publish on them reasonable.
Do I have to write tests myself?
No. Key journeys are captured as the application is built, and you can add the flows that matter most to your business. Engineers can inspect and extend what runs — it is part of the project, not a black box.
What happens when a smoke gate fails?
The publish stops. The failure comes back with context — the step, the expectation, what happened instead — so the fix can be made and re-verified. When the gate is green, the publish proceeds.
What are production checks, and why run them after publish?
Preview and production differ: configuration, data, integrations and traffic are real only in one of them. Production checks run against the live application after each release to confirm it behaves where it counts, and findings flow to Doctor and SysOps for diagnosis and response.
Does this replace QA engineers?
No — it changes what they spend time on. The mechanical work of keeping browser tests alive is automated; humans decide which journeys are critical, review what the gates catch and raise the bar over time.