We made it ridiculously easy to generate software. We should make it just as easy to investigate whether that software works.
Right now, a lot of testing starts with a hopeful prompt: “Can you test this?” The agent runs a few checks, fixes something, and says things look good. You still have to figure out what it understood, what it missed, and whether those checks had much to do with your customers.
That is the problem I want CARBON to solve.
Install CARBON in your AI coding agent, open your project, and type:
/carbon
That starts a testing loop: understand the product, assess the risks, inspect existing coverage, generate the next useful tests, exercise the application, investigate failures, and explain the confidence supported by the evidence.
The coding agent does the work. CARBON gives it the testing knowledge, workflow, persistent context, and evidence discipline to do that work more systematically.
Read the project before writing another test
Your project already contains clues about what matters. Source code. Specifications. Documentation. Existing tests. Recent changes. Previous failures. Things you have told the agent in the conversation.
CARBON brings that context into the plan. What does the product promise? What are the important user journeys? Which parts changed? Where could a small failure cause a large problem?
It looks at existing test coverage before generating more. A folder full of test files is not evidence that checkout works. A passing login test says little about what happens when an account loses permission halfway through editing a document.
The useful question is: which important behaviors have credible evidence, and which still need investigation?
This includes business value. Can the intended customer accomplish the actual job? Is the output useful? Does recovery preserve their work? A technically functioning interface can still fail the person using it.
Use the stack you already have
You should not have to replace your test framework to get better testing.
CARBON can direct the agent to generate and execute tests in the project's chosen framework and language: Playwright or Selenium for browser automation, Python and pytest for an API, or another stack the agent can actually run in that environment. Tell it your preference. Existing conventions and tools should shape the implementation.
It can also exercise the product directly through an isolated browser, inspect requests, and follow a user journey without first building a large automation suite.
The interesting cases are often sequences: save, reload, switch accounts, retry, lose the network, recover. Or have a persona try to accomplish something meaningful and notice where the experience becomes confusing or breaks.
If a dependency, credential, or environment is unavailable, that is an execution limit to report. It is not a passed test.
Investigate failures. Repair the right thing.
A failed test might reveal a product bug. It might also reveal a broken selector, bad test data, a timing assumption, or a test environment that never started.
Those require different fixes.
CARBON helps classify the failure, preserve a reproduction, and choose the next check. When you authorize repairs, the agent can update legacy automation as well as tests it just generated, then rerun the original case and relevant neighboring checks.
“Fixed the test” must never mean deleting the assertion that caught the bug. The expected behavior still needs a defensible reason. Product changes and consequential actions remain subject to your approval.
Watch the work, then inspect the evidence
CARBON opens a live HTML view alongside the conversation where the coding agent supports it. You can see what it is working on, why that check matters, what just happened, and what remains.
The resulting reports bring together findings, reproduction steps, screenshots and other available evidence, coverage gaps, and recommended follow-up work. Generated tests, executed tests, suspected problems, and demonstrated failures stay distinguishable.
The first run is bounded. It prioritizes a useful initial set rather
than promising to test the whole product forever. You can use
/carbon-more to continue into the deferred coverage.
What the confidence score means
The confidence score is an evidence-qualified assessment of the tested scope. It summarizes the strength and breadth of the available verification, interpreted alongside failures, important gaps, and the relevance and freshness of the evidence.
It is not a defect-free percentage. A score of 78 out of 100 does not mean there is a 78 percent chance the product is correct.
The explanation matters more than the number. Which behaviors were observed? Which risks remain? Was security investigated, or only functionality? Is the evidence still relevant after the latest change?
CARBON separates dimensions such as functionality, security and privacy, accessibility, performance, reliability, usability, data integrity, and operational readiness. An untested area does not inherit confidence from a different area that passed. If there is not enough evidence to justify a score, it should not manufacture one.
You retain the release decision. CARBON should make that decision better informed.
Start with one command
Install CARBON at testers.ai/carbon for a supported
coding agent such as Claude, Codex, or Cursor. Open a project and run
/carbon.
The goal is simple: make serious testing convenient enough that it becomes part of building, rather than the thing we hope someone else will do afterward.
— Jason Arbon, CEO testers.ai
