Use cases

Three places where the copy-paste tax hurts most.

Make the abstract concrete. Show what Codencer changes, with real commands and real artifacts, for each of the three buyer segments.

Scenario 01 — Solo operator

Who this is for: A solo dev or a small consultancy juggling multiple AI coding tools across multiple client projects, accountable for code quality and clean handoff.

The pain

You run Claude Code on one project, Codex on another, Antigravity on a third. Across attempts, you cannot prove what each tool changed, what tests passed, what the diff looked like, what you accepted. When a client asks "show me the trail", you reconstruct from chat logs and git blame.

The Codencer view

Every attempt becomes a run with structured artifacts. The diff, the test output, the validations — all recorded, all queryable, all replayable. The chat is no longer the source of truth. The run is.

What it looks like

# minimal TaskSpec
task:
  name: refactor-payment-handler
  workspace: ~/projects/clientA
  executor: codex
  goal: |
    Refactor the payment handler to extract retry logic into a separate
    module. Add tests for the retry path. Keep the existing public API stable.
  validators:
    - go test ./...
    - golangci-lint run

The proof

make build
./scripts/smoke_test_v1.sh
make smoke

Three minutes, three commands, green or red.

Quickstart

Scenario 02 — Platform team

Who this is for: An engineering lead at a 20–200 engineer company. Your team has shadow AI today — Claude Code, Codex, Copilot, Cursor — installed by individuals, with no shared run truth and no audit posture.

The pain

You inherit shadow AI. Different teams use different tools. No one can answer "did the AI change this file" with confidence. You cannot prove to security or compliance that AI-driven changes follow your policy. You cannot point an external audit at a single source of truth.

The Codencer view

Codencer becomes the system of record across whatever AI tools your engineers chose. Each tool's adapter feeds the same state model. The audit log is the same shape regardless of which planner started the run. SSO, SCIM, RBAC are on the roadmap (v0.6, v0.7, v1.0). The local-first execution model means code never leaves your network.

What it looks like

# self-host relay topology
[ engineer's planner ]
   ↓
[ your relay ] (runs on your infrastructure, audits everything)
   ↓
[ each engineer's local connector + daemon ]
   ↓
[ each engineer's local executor ]

The proof

PLANNER_TOKEN=<planner-token> make self-host-smoke-mcp

Read the security & audit chapter Email me to discuss a pilot

Scenario 03 — Regulated industry

Who this is for: A platform or security lead in financial services, healthcare, defense-adjacent. Procurement says: code never leaves our network, every change is audited, the vendor cannot retain prompts or outputs.

The pain

Off-the-shelf AI coding tools fail your procurement review. The vendor has access to source. The vendor retains prompts. The audit trail is a chat transcript, not a structured record. Your security team cannot answer "what did this tool actually do" without the engineer's screenshare.

The Codencer view

Local-first execution: the code stays on your machines. Self-hosted relay: the audit log stays on your infrastructure. No inference inside Codencer — the bridge does not retain or train on your data, by design. Apache 2.0 license: your legal can read every line.

What it looks like

# self-host cloud control plane
[ your relay control plane ] (your VPC, your SSO/SCIM)
   ↓
[ tenant runtime ] (per-team isolation)
   ↓
[ engineer's local daemon ] (their machine, their network)
   ↓
[ executor + repo ]

# every action emits a structured audit event
{
  "event": "attempt.completed",
  "run_id": "...",
  "step_id": "...",
  "attempt_id": "...",
  "actor": "alice@acme.com",
  "executor": "claude-code",
  "result": "passed",
  "artifacts": [...],
  "ts": "2026-04-27T..."
}

The proof

make build-cloud
make verify-beta-docker

Read the security & audit chapter Email me to discuss a pilot