CTO Path
Who it's for
CTOs and heads of engineering setting policy for how the org uses coding agents — not learning to prompt, deciding what is allowed to be automated and what remains human-owned.
Prerequisites
- Authority over engineering standards, review policy, and tooling budget
- One pilot team willing to run the operating model for a sprint
- Existing delivery metrics you trust (or willingness to define crude ones)
Ordered modules
- Start Here — the operating loop this manual defends
- Responsibility Split — what never delegates cleanly
- What Not to Delegate — policy fodder
- Docs as Agent Memory — repo as the org's agent memory
- Quality Gates — CI and process gates that scale past heroics
- Reviewing AI PRs — review load will dominate; design for it
- Coordination — when teams go parallel
- Failure Catalog — org-visible failure modes to train on
- Case Studies index — pick two closest to your portfolio
- Engineering Manager path — what your EMs must own day-to-day
Exercises
- Draft a one-page agent policy: allowed tools, required artifacts (spec, CLAUDE.md), merge rules, and banned automations (prod credentials, force-push, etc.).
- Instrument one pilot team for two weeks: % PRs agent-authored, review cycle time, revert rate, incidents with agent-touched code.
- Run a tabletop: "agent merges plausible auth bypass" — which gate should have caught it? Fix the gap in writing.
- Choose templates the org standardizes on; link them from the eng handbook.
Capstone
Publish an internal RFC: agent operating model, responsibility split, mandatory quality gates, pilot results, and a 90-day rollout. Include explicit non-goals (what you will not automate yet).
Expected outcome
You can defend a concrete policy — not "use AI more" — with gates, ownership, and metrics, and your EMs know what "good" looks like without you in every PR.
Related
- Learning Paths — role curricula
- Architecture Erosion — org-scale failure mode
- Internal Platform case study — platform-shaped adoption
- Production Readiness checklist