Your coding agent says the feature is done. The tests pass. The demo looks good.
Would you ship it?
That is a different question. A green test suite tells you that certain checks passed under certain conditions. It does not tell you whether those were the right checks, whether they could detect the important failures, or whether the conditions look anything like your customers' lives.
As AI makes software faster to build, this gap gets more interesting. We can generate the feature, generate its tests, and generate a reassuring explanation of why it works. All from the same assumptions.
We need a better way to earn confidence.
That is what CARBON's confidence command is for. Install CARBON in an AI coding agent such as Claude, Codex, or Cursor, open your project, and run:
/carbon-confidence
It is not just a request for a score. It starts an investigation.
Start with the promise
Imagine you are building checkout. You have tests for adding an item, entering payment details, and displaying the receipt. They all pass.
But the customer does not care whether your receipt component rendered. They care whether they got the order they paid for, at the price they agreed to, without being charged twice.
That is the promise worth investigating.
CARBON starts from the product's intended behavior, the release scope, and the consequences of failure. It looks at the available code, specifications, existing tests, prior findings, and other relevant context. An assumption inferred from code is not automatically treated as an approved requirement.
The question becomes: what evidence would support this promise, and what would break it?
Follow the question that matters next
A fixed checklist follows the list. A confidence investigation should follow what it learns.
Suppose the next useful question is what happens when payment succeeds but the browser never receives the response.
In an authorized payment sandbox, the agent can investigate the timeout, the retry, the order record, and the payment outcome. Reading the retry code helps. Watching the browser helps. Neither, by itself, establishes whether the customer was charged twice.
If the retry creates a second order, the next question changes. Does the same failure affect inventory? Does the customer receive two receipts? Is the duplicate visible to support? Can recovery make the situation worse?
If the retry behaves correctly, there may be a more valuable uncertainty elsewhere.
CARBON's loop is designed around that progression: assess the evidence, prioritize a consequential question, investigate it, challenge the result, reassess, and choose what to pursue next.
The agent can use source inspection, existing automation, browser journeys, API checks, stateful experiments, or other available methods. The method follows the question, not the other way around.
The checkout example here is illustrative, not a claim about a particular test run. The point is how the investigation develops.
Test the test, too
Here is the part that is easy to skip: could your check have detected the failure you care about?
A test that sees an error message after a payment timeout has not established that the payment failed. A test that sees a receipt has not established that the amount was right. And a test generated from the same mistaken assumption as the implementation can agree with it beautifully.
CARBON asks the agent to challenge the basis of the result. What defines correct behavior? Is that expectation independent of the implementation? Can the important observation be reproduced? Would a controlled negative case expose a broken check?
This does not make the evaluator infallible. It makes the quality of the evaluation part of the work.
That is a substantial difference from asking the agent to run the suite and summarize the green output.
Watch confidence change as the evidence changes
The investigation has a live HTML view, opened alongside the conversation where the coding agent supports it.
You can see what CARBON is investigating, why it chose that question, what it expected to observe, and what actually happened. The report keeps the evidence, limitations, and changes in the assessment together.
These are concise explanations of decisions and observations. You should not have to interpret a wall of activity logs to understand why a checkout retry suddenly became the most important thing to test.
And the score is allowed to go down.
Finding a serious flaw should reduce confidence in the current release, even if the agent has just done excellent testing. A dashboard that rewards every additional test with a higher score is measuring activity, not readiness.
What the number actually means
When the evidence supports a numeric assessment, CARBON can provide a 0–100 reasoned judgment, with a range and an explanation of what drove it.
That is not a probability that the product is correct. It is not a statistical confidence interval. It is an assessment of the available evidence for a particular scope, version, and environment.
The useful part is the explanation. Which promises have strong support? Which have only limited evidence? Which were contradicted by an observed failure? What remains unexamined?
One consequential failure cannot disappear inside an average of hundreds of passing checks. Evidence from an old build does not automatically support a changed one. A successful staging journey does not establish production behavior at scale.
If the evidence cannot support a number, CARBON should give you the assessment without inventing one.
A useful stopping point, not an endless test run
The default investigation is bounded to 20 minutes and up to six investigations. Those are limits on the initial effort, not a promise of complete coverage or a guaranteed verdict.
CARBON saves the work so it can be continued. It should finish with a scoped recommendation, the important unresolved risks, and the next evidence most likely to change the decision. Sometimes that recommendation is to ship. Sometimes it is to hold, use a limited canary, or gather more evidence.
You still own the release decision. The agent does not get to accept customer harm on your behalf, and it needs permission for consequential actions or product changes.
But you should have a much better answer than “the tests passed.”
Try it on the release you are considering
Install CARBON at testers.ai/carbon, then give the confidence command a real decision:
/carbon-confidence assess whether the checkout change is ready for staging; focus on retries, duplicate orders, and recovery; use local or sandbox evidence only; stop after 15 minutes
Local work can use the allowance in your subscription coding agent. Subscription limits and any optional external service costs still apply. The command does not require you to start by building a separate evaluation platform.
AI made it easy to produce software that looks finished.
The next step is making it easier to understand whether it is ready.
— Jason Arbon, CEO testers.ai