Built for teams who ship fast & care about code quality
Engineered for backend testing precision, depth, and reliability.
The Kerno Engine compiles a deep map of your code, gates every step behind deterministic guardrails, hardens every test with adversarial reviews, and sharpens with distributed learning. That's why it's the most thorough and most trustworthy AI engine in backend testing.
Your coding agents are built to be good at many things. The Kerno Engine is built to be exceptional at one: backend testing.
Subsystem 01
Compile Code Intelligence
The accuracy of every test rests on how deeply the engine understands the code beneath it. The deeper that understanding, the more precise the tests.
Specification
1.1Covers every major backend language
1.2Resolves each framework's own routing, tasks, and queues
1.3Compiler-grade map of how your code connects
1.4Unresolved wiring is labeled and explained
Subsystem 02
Compose the Test Plan
To plan a surface, Kerno walks its call graph, every caller and callee, mapping what the code touches, which permissions guard it, and how it can fail. It then designs the exact scenarios those paths demand, across every endpoint, task, queue, and scheduled job. That grounding is where Kerno's precision comes from.
Specification
2.1Deep per-endpoint analysis
2.2Scoped by intent, functional by default and security on demand
2.3Assertions pinned to your response contract, field by field
2.4Deeper where a change reaches, lean everywhere else
Subsystem 03
Execute the Suite
The execution engine gates every scenario behind deterministic guardrails and hardens every result with adversarial reviews. This is where Kerno's reliability comes from. Every verdict is produced by the same deterministic checks, so results stay consistent and hold up in review and in CI.
Specification
3.1Pre-flight readiness checks
3.2Deterministic execution the engine controls
3.3Verifies side effects where a connection is configured
3.4Per-scenario isolation and teardown
Subsystem 04
Learn Your Standards
The learning engine applies your team's standards on every run and mints its own lessons from what each run proves, keeping what holds and retiring what goes stale. This is the distributed learning that sharpens Kerno over time.
Specification
4.1Custom rules in plain English, scoped to your routes
4.2Human decisions remembered and honored
4.3Lessons minted only from evidence a run can vouch for
4.4Self-healing, stale lessons suspended and dropped
Subsystem 05
Detect the Drift
Drift detection is fully deterministic. Kerno decides whether your code's behavior changed or a test simply broke from the exact class of error a run throws, turns each real change into a tripwire that fires if that behavior ever moves again, and replays the whole suite in CI with no model in the loop. That determinism is what makes a Kerno diff trustworthy.
Specification
5.1Drift and breakage split by error class
5.2Suspected bugs recorded as regression sentinels
5.3Every drifted field reported in one run
5.4Deterministic replay, no model in the loop
Subsystem 06
Scale to Any Codebase
A model's reasoning degrades as its context fills, well before it hits the limit. Kerno treats context as a budget it actively manages, splitting the work into small tasks and feeding each one only the exact slice of code it needs from an index. That is how Kerno stays precise on a codebase of any size.
Specification
6.1A focused, relevant context for every task
6.2Work split into small, clean tasks
6.3Only the slice each task needs, pulled from an index
6.4Context spent on what your change touched
FAQs
Got any extra questions? Reach out on our community channel and we'll be happy to help.
What is the Kerno Engine?
The Kerno Engine is an AI engine built for backend testing. A model plans and writes the tests for every surface of your backend, deterministic guardrails decide which ones count, and it runs against your real stack and replays in CI on every change.
How is Kerno different from asking an AI agent to write tests?
Kerno's model plans and writes the scenarios, then the engine gates every step behind deterministic guardrails and hardens each result with an adversarial review before it counts. It plans from your call graph, keeps a baseline of how your backend behaves, and replays the suite in CI on every change.
How does Kerno maintain its tests as my code changes?
Kerno does. On each run it reads what your change touched, keeps the coverage that still holds, updates only the scenarios that moved, and retires the ones your code no longer supports. A small change produces a small update sized to what actually moved.
What kinds of tests does Kerno generate?
Kerno generates functional scenarios by default and security scenarios, mapped to the OWASP Top 10, on demand. Where it has a database or dependency connection it verifies side effects too, the rows written, messages queued, and downstream calls made, alongside the response. It tests black-box over HTTP or white-box with direct access to your state.
How does Kerno prevent false passes?
Every scenario passes an adversarial review before it counts. Kerno rejects a test that weakens its own assertion, hardcodes an id, or leaves its cleanup unverified, and a stub that was never implemented is never scored as a pass.
Does Kerno test background jobs and queues?
Yes. Kerno tests every surface of your backend, including HTTP endpoints, background tasks, queue consumers, scheduled jobs, and MCP tools, discovering and testing each as its own kind of entry point.
Which languages and frameworks does Kerno support?
Kerno reads every major backend language, from TypeScript and Python to Go, Rust, Ruby, PHP, C#, Java, Kotlin, and Scala. It resolves each framework's own wiring too, with dedicated discovery for Django, AWS SAM and Lambda, Celery, and SQS. HTTP routes and async task handlers are both found.
Does Kerno do black-box or white-box testing?
Both. With database access Kerno seeds and verifies state directly. Without it, Kerno tests over HTTP, and it blocks any scenario the environment cannot satisfy up front.
Does Kerno touch my production data?
No. Kerno connects to the environment you point it at and runs against the dependencies you already run. You decide what it can access, and every scenario is checked against that access before a request is made.
