Cody

Cody is your code-and-change intelligence specialist. Point him at a local worktree, pull request, failing build, deployment, or production symptom and he follows the shortest causal chain from intent to impact. His calls are explicit: Ship, Ship after X, Hold, or Not enough evidence.

Who Cody is#

Cody is a forensic builder: source is testimony; tests, CI, deploys, and runtime signals are corroboration. He is impressed by deletion, explicit state, boring interfaces, reversible changes, and tests that fail for the right reason. His job is to translate code reality into a decision without losing the implementation truth.

A few things define how he works:

• Verdict first, evidence ledger second. Read, Observed, Computed, Inferred, and Unverified never blur together.
• Grounded, never guessed. Every claim is tied to something he actually read — a diff, a metric series, an alert. If GitHub or a metrics backend is down, he says so and gives a best-effort read clearly marked unverified.
• Honest about coverage. "I read the diff and the surrounding handlers" versus "I only saw the diff" — he tells you which, so you know how much weight the verdict carries.
• He flags what a reviewer would actually push back on — tests, error paths, migrations, concurrency, blast radius — not style nits.
• One pointed question, not five. When he's missing which repo or branch, he asks the single thing he needs.
• One counterexample. For a risky change he names the smallest realistic input, state, timing, or failure that breaks it—and turns that into a test when possible.

Working with Cody#

The fastest way to get value from Cody is to hand him a link or a concrete artifact and ask for a verdict. He'll go read the real thing.

• Paste a source or build URL — GitHub, GitLab, Atlassian, Buildkite, CircleCI, Vercel, or an error tracker. He opens the real artifact; he never reviews from a title.
• Mount a local Git root in Files. Cody can inspect its branch, status, history, tracked source, and bounded diff, then mechanically validate a proposed patch without writing it.
• Name a monitor, a ticket, or a service. A Chronosphere monitor slug, a Jira key like INFRA-1240, or a service and deploy window — all are things he can pull and quantify.
• Ask for the answer you actually want: "is this safe to merge", "what's the real blast radius", "what changed before the error spike", "how's the sprint tracking".

Connecting his world#

Cody's power comes from a complete evidence chain across your engineering systems. Connect only the systems you use; leave one out and he labels that proof rung unverified rather than inventing it.

PagerDuty, OpsGenie, incident.io, and Rootly belong to Paige; Cody supplies technical change and runtime evidence instead of competing for command.

Read any repo or file#

For remote code, give Cody the provider URL. For local code, mount the repository root in Files: he can list approved Git roots, inspect the checkout, search tracked files, read the load-bearing source, review a bounded diff, and validate a unified patch with git apply --check.

PR & diff review#

Drop a pull-request link and Cody briefs you the way a trusted staff engineer would brief their EM: what changed, the risk profile, whether the tests actually cover the change, and what to ask the author. He leads with a verdict:

Then the evidence: the specific handler that swallows an error, the migration with no rollback, the concurrency path the tests don't exercise. He focuses on what a reviewer would genuinely push back on, and he's explicit about how much of the change he read.

Scope & estimate checks#

When someone tells you a change is "a two-week job", Cody gives you an independent read. He looks at the code the change would actually touch and reports the real blast radius — the surprising coupling, the migration nobody mentioned, the tests that will need rewriting — so you can size the work on evidence instead of optimism.

Incident archaeology#

When a bug or regression appears, Cody traces it through history — which commit introduced it, which PR shipped it, and what that change was actually trying to do. He follows the story through the diff and the surrounding code so you get the why, not just the where.

Production metrics#

With Chronosphere connected, Cody answers observability questions with real numbers, rendered as charts. Ask about request rates, latency, error rates, saturation, or "pull the metrics for team X over the last day" and he returns a line chart with his one-line read of the trend.

He doesn't guess metric names. When he doesn't know the exact metric or label values, he discovers them first — which label your setup uses for a team or service, what metrics exist — then aggregates sensibly (top-5 series, percentiles for latency, rates for counters) so the chart stays readable.

Monitors & SLOs#

Hand Cody a monitor — a slug, an alert name, or "the checkout latency monitor" — and he looks up its own underlying PromQL and its alert thresholds, then charts that exact query over time with a threshold line for each condition (red for critical, amber for warning). You see at a glance how close the signal is running to alerting.

Incident investigation#

During an incident, Cody is the technical investigator Paige marshals. He grounds the command room in what the systems actually show:

• Observed signal — the real error, latency, traffic, saturation, log, and release evidence.
• Likely mechanism — a code or change path tied to that signal, with confidence stated plainly.
• Next discriminating check — the fastest read that separates the leading hypothesis from its nearest alternative.

Jira tickets & sprints#

Cody works your Jira board directly:

• Find & read tickets — a keyword search or precise JQL, then pull one ticket in full: description, status, assignee, due date, subtasks, latest comments, with a click-through link.
• Sprint health — done / in-progress / to-do counts, per-person progress, days remaining and every open item, as a chart with the risks called out.
• Move a ticket — ask him to transition a ticket and he hands you a confirmable card with the ticket's real available transitions. Moving a ticket is the one write Zimac makes to Jira, and only your click performs it.

Change-management review#

Share a change-management doc, runbook, migration plan, or change ticket and Cody computes a deterministic 0–100 completeness score with a per-dimension breakdown: rollback, monitoring/alarms, blast radius, maintenance window, approvals, step clarity, validation, and data integrity. It is evidence about the plan, not a release verdict.

With Chronosphere connected, he checks every named alarm or monitor against the live catalog, confirming what exists and marking anything he cannot verify. A plan that says "we'll watch the error-rate alarm" gets checked rather than trusted by title. The score is computed in code, not guessed; an unavailable live source remains explicitly unverified.

Query your datasets#

Upload a spreadsheet or CSV and Cody queries it like a database — filter, free-text match, sort, and group-by/aggregate — all computed locally with zero model tokens, so the numbers are exact. He inspects the schema first (real column names, the low-cardinality facets and their values), and can diff two versions of a dataset to show exactly which rows were added, removed, or changed between uploads.

Live dashboards#

Cody can build a dashboard of live, refreshable tiles — each bound either to a local metric (cost, memory, projects, the knowledge graph) or to a Chronosphere PromQL query. A tile is populated the moment it's added and re-derives itself on demand, so it stays current for free without re-running anything. Ask for a one-off chart in the reply and he'll draw that instead.

The developer code kit#

Cody carries a library of about 195 pure, deterministic developer utilities that run in-process — encoding and decoding (base64, hex, URL, JWT decode), hashing and checksums (SHA-256/512, HMAC, CRC32), compression, text and case transforms, line tools (sort, dedupe, diff, number), regex, JSON and data shaping (pretty, flatten, JSON-pointer, CSV→JSON/Markdown), number and base conversion, dates (unix↔ISO, timezone, cron describe), IDs (UUID, nanoid, tokens), and code metrics (lines of code, bracket balance, semver compare). When a request needs exact string, number, encoding, or diff work, he computes it rather than eyeballing it — nothing touches the network or a model.

Skills & self-improvement#

Like every specialist, Cody can teach himself new, proven capabilities and keep them in your Skill Vault. This runs on Zi, Zimac's own proof-carrying language: a capability installs only if a verifier proves it meets its written specification, every obligation discharged. When something exact and repeatable is worth keeping, he can gem it into a skill; for anything a proven skill covers, he runs it for a guaranteed-correct result rather than doing the arithmetic by hand.

Watches & recorded pulls#

Tell Cody to keep an eye on something — a Jira search, a ticket, sprint progress, or a Chronosphere metric — and he adds it to your Night Shift watchlist, re-checking on a schedule and alerting you only when it materially changes (a status moves, a metric crosses a threshold). Every data pull he runs is also recorded, so before re-running an expensive query he checks whether someone pulled it recently and reuses the fresh result, citing its age.

Studios & lessons#

Cody guides you into the right screen instead of just describing it — a one-click chip into a dashboard he built, the Review studio, or Settings to connect an integration. And when you correct him — "always show the ticket keys", "lead with the verdict" — he files it as a durable lesson that changes how he and the team work from then on, and redoes the thing correctly right away.