Your CI runs the tests you wrote. Spinal writes the one you didn't.
When we say Spinal validates a change by writing and running tests, the first reaction is usually: isn't that just another CI step, a GitHub Actions or Jenkins job with extra branding? It is closer to the opposite.
Your CI and Spinal's validation answer different questions, and they work best together — in fact, Spinal runs inside your CI.
CI asks "did this break a known test?" Spinal asks "is this suspected bug real?"
"Runs tests" sounds like CI. It works the other way around.
CI executes a fixed suite you wrote in advance and tells you whether it still passes. Spinal's validation generates a brand-new test for one specific change and runs it to settle a question the existing suite was never written to answer. The action is the same — running a test — but the question is different.
CI checks what you already knew to check.
A pipeline is a regression safety net. You encode the behaviors you care about as tests, and on every run the same suite confirms nothing known has broken. It is essential, and Spinal does not touch it.
But a green pipeline only says the tests you thought to write still pass. It is silent about the risk in this change that no existing test covers — the migration that locks a hot table, the handler that is no longer idempotent. That gap is exactly where bad changes slip through.
Spinal writes the test that doesn't exist yet.
When a change looks risky, Spinal hypothesizes the specific way it could fail, writes a focused test that targets exactly that, runs it, and reads the result to confirm or reject the finding. The test is generated for the review — a probe to settle one question, not a permanent addition you now have to maintain.
That is what turns "this looks risky" into "here is the test that reproduces it." The reviewer is not guessing; it is checking.
It runs inside your CI, not beside it.
Spinal does not stand up a parallel test system. It uses your CI as the execution environment — your runtime, your services, your fixtures — so the generated test runs where your real tests run, with the setup you already maintain. It reads your pipeline configuration to do this and confirms the setup works before relying on it.
So the relationship is not replacement; it is layering. Your CI guards the baseline: known behavior, every commit. Spinal probes the specific, unknown risk in the change in front of it.
Evidence, selectively.
Because Spinal writes the tests and validates only the changes that warrant it, you get the upside of execution without a new pile of CI to maintain or a slower pipeline on every trivial commit. Findings arrive reproduced, not merely asserted, and the tests that prove them run in the environment you already trust.
That is the whole point of production-aware review: a finding that arrives with the test that settles it, run where your code actually runs.
See validation run on a real change.
Connect a repo, open a pull request with a risky change, and watch Spinal write a focused test and run it in your CI to prove the finding. 15 days free, no credit card.