WCAG specialist focused on criterion-level evidence across perceivable, operable, understandable, and robust behavior, without overstating automated scan results as conformance.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
Compatibility specialist focused on browser, device, viewport, operating-system, assistive-technology, and support-matrix evidence, with explicit coverage gaps rather than assumed portability.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
Performance specialist focused on user-visible latency, Core Web Vitals, payload and request cost, caching, API timing, scalability, mobile constraints, memory, and leaks.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
Content and UX-writing specialist focused on page identity, clear copy, information architecture, credibility, navigation, status communication, readability, and content quality.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
Forms specialist focused on input contracts, validation, boundaries, state, submission, recovery, data quality, conversion barriers, and accessible interaction.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
First-impression and conversion specialist focused on value clarity, trust, navigation, calls to action, responsive composition, dead ends, and page credibility.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
Checkout and payment specialist focused on order accuracy, address and payment input, trust, retry safety, pricing truth, completion, and conversion-blocking failures.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
AI
Virtual AI tester
Priya
Shopping Cart Tester
Shopping-cart specialist focused on line-item state, quantities, promotions, totals, inventory changes, persistence, accessibility, and safe transition to checkout.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
AI
Virtual AI tester
Mateo
Pricing Page Tester
Pricing and subscription specialist focused on plan clarity, comparison, currency and locale, hidden conditions, billing cadence, conversion paths, and truthful claims.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
AI-generated-code specialist focused on logic, boundaries, null and empty states, failure handling, API use, security, privacy, tests, code smells, state, and misleading AI shortcuts.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
Useful activity and cost data without invented savings.
Jason Arbon CEO, testers.ai
/carbon-stats
AIJasonAI Code ReviewAIArjunData Integrity
How many tests did the agent create? How many did it execute? Which
findings were actually fixed?
Those are different numbers. A useful dashboard keeps them
different.
/carbon-stats brings together CARBON's recorded
activity: commands and frequency, test creation and execution, findings,
verified fixes, and available evidence. It helps you understand how the
harness is being used and where the effort is going.
“Found” is not “fixed”
Imagine a run reports three issues. The agent later edits two files.
That does not establish two fixes. A fix needs a retest tied to the
original finding.
Likewise, a hundred generated test definitions are not a hundred
executed tests. A screenshot count is not a coverage claim. Useful stats
preserve the connection between activity and evidence rather than
flattening everything into a productivity score.
Token, model, and cost information should appear when attributable
measurements are available. Subscription sessions do not always expose
that information. An invented token count is not more helpful than
leaving the metric out.
Savings need a baseline
/carbon-stats summarize this project's activity, command frequency, verified fixes, and measured costs
Time and dollar savings can be estimated against an explicit
human-work baseline, with the assumptions visible. They should not be
advertised as measured results just because a task sounds expensive.
The dashboard is about activity and economics. It is not a shipping
verdict, and one local project's command count does not establish
worldwide adoption.
AI testing deserves scrutiny of its own. Show the work, show what
changed, and show the numbers you can actually support.
Install CARBON at testers.ai/carbon for a supported
coding agent such as Claude, Codex, or Cursor.
