# CARBON: AI testing inside your development workflow

An 11-slide introduction for internal teams. Allow 15–20 minutes plus discussion. Slides 1–6 explain the harness, team roles, workflow, specialist perspectives and quality map. Slide 7 is an optional prepared walkthrough. Slide 8 introduces example commands. Slide 9 describes daily use. Slide 10 presents optional Iceberg QA support. Slide 11 closes with install information and contact details.

## Slide 1

OPENING. CARBON brings a repeatable AI testing workflow and specialist perspectives into compatible coding agents. Testers.ai builds the harness. The team retains product intent, risk decisions and release ownership. This concise presentation covers the workflow, commands and optional expert help.

## Slide 2

The coding agent supplies the model and execution environment. CARBON adds risk-based workflows, specialist perspectives and durable evidence. Your team defines acceptable behavior and owns release decisions. Compatible host, runtime and permissions are required. A local harness can still send context to the host model provider.

## Slide 3

Developers use reproducible findings and retest fixes. Testers steer exploration. Business analysts clarify ambiguous expectations. Architecture colleagues examine service interactions. Delivery colleagues coordinate owners and blockers. Leaders evaluate risk and adoption value. Adjust SA and PC labels to local role names.

## Slide 4

CARBON examines intent, code and existing tests, prioritizes risks, exercises relevant behavior and records evidence. It can create or adapt checks to the available tools. Continue with the next meaningful gap or verify a repair. Repairs and intrusive actions require appropriate authorization. Confidence summarizes the investigated scope, not proof that the entire product is correct.

## Slide 5

These are AI testing sub-agents, not human staff profiles. Their perspectives cover security, privacy, accessibility, performance, usability and issues associated with AI-generated code. Findings still need reproducible evidence. Available tools and configuration affect what the agent can verify.

## Slide 6

This is an existing Brewtown Coffee demo capture. Explain the explored pages, screenshots, observed results and proposed checks. Distinguish observed evidence from untested suggestions. A screenshot is not proof that a complete user journey passes. Controls depend on the installed capabilities.

## Slide 7

OPTIONAL DEMO. Prepare an approved host and disposable synthetic project. Run /carbon-demo, follow with a focused /carbon-issues investigation and use /carbon-map to explain what was explored. Show one reproducible finding and a useful next check. Keep a saved result as a clearly labeled fallback.

## Slide 8

Eight examples show the breadth of CARBON without separating commercial editions. /carbon performs a broad assessment. Focused security, privacy and accessibility commands investigate their domains. /carbon-issues hunts bugs, /carbon-auto supports a bounded authorized test-fix-retest loop, /carbon-map visualizes evidence and /carbon-confidence evaluates scoped readiness.

## Slide 9

Use CARBON on a specific change with clear scope. Bring existing tests and intent into the investigation, exercise relevant risks, review evidence and retain useful checks. Durable context helps future work, but stale evidence needs revalidation after changes. The team authorizes repairs and owns decisions.

## Slide 10

Iceberg QA is an optional services and training partner. Its human AI QA experts can broaden coverage with CARBON and complementary tools, and coach the team through setup, live investigations and evidence review. Agree service scope and tool access separately. CARBON does not require an Iceberg QA engagement.

## Slide 11

Install information is at https://testers.ai/carbon/. Pick an important journey and an approved target for the first investigation. Optional Iceberg QA testing and training contacts: Jason Arbon at jason.arbon@icebergqa.com and Philip Lew at philip.lew@icebergqa.com.