The Enterprise AI Coding Playbook: A 30/60/90 Roadmap

You are the CTO of a company with several hundred engineers. Your board has asked what you are doing about AI coding tools. You know the answer is not “banning them” and you know it is not “letting everyone do whatever they want.” It is somewhere specific in the middle, and the question is how to get there in a quarter without losing the next quarter to implementation.

This post is the roadmap. Ninety days, divided into three thirty-day phases, each with named owners, concrete deliverables, and exit criteria before the next phase starts. Every deliverable below links to a dedicated post — this page is the plan; those posts are the artifacts.

If you are not a CTO, this page is also your orientation map for the ten-post cluster it links to. Read it to understand which artifact answers which question; read the specialized posts to do the work.

The Shape of the Ninety Days

• Days 0–30: Evaluate. Select the tool. Get the contract right. Stand up the governance scaffolding.
• Days 31–60: Pilot. One team rolls out. Controls, measurement, and training get exercised against reality.
• Days 61–90: Scale and harden. Expand to the full org with the tuned controls. Produce the evidence pack that survives your first audit.

The phases are sequential — expanding to the whole engineering org before the pilot has surfaced the controls gaps produces a mess that takes two quarters to unwind. Respect the order.

Days 0–30: Evaluate

Goal at the end of day 30: A tool selected, a contract signed, and the governance scaffolding in place for one team to start using it on day 31.

Workstreams

Workstream	Owner	Deliverable	Reference
Bakeoff	VP Eng or tech lead	Ranked scorecard of 2–3 candidate tools across 10 weighted criteria	Evaluation scorecard
Contract	Procurement + Legal	Executed MSA with DPA, BAA (if applicable), and 14 clauses from the red-line list	Procurement checklist
Risk assessment	CISO	10-row risk register with inherent and residual scores, signed by exec committee	Risk assessment template
Business case	VP Eng	One-page business case approved by CFO	Executive buy-in one-pager
Governance policy	CISO + Legal	Internal AI Coding Tools Standard, version 1.0, published to policy library	Policy template

Exit criteria for day 30

• Tool selected and contract executed.
• Policy document published and linked from the engineering handbook.
• Risk assessment on file with the CISO.
• Pilot team identified, informed, and scheduled.

If any of these are not complete on day 30, do not begin the pilot. The pilot is what proves the scaffolding; the scaffolding cannot be built during the pilot.

Days 31–60: Pilot

Goal at the end of day 60: One team has used the tool under the full control stack, surfaced the gaps, tuned the parameters, and produced a baseline for the productivity measurement that will justify renewal.

Pilot team selection

Pick a team that is:

• Mid-sized (8–15 engineers) — large enough to produce statistical signal, small enough to change course quickly.
• Representative of the broader team’s stack, not an outlier (not your ML research group, not your legacy COBOL team).
• Led by someone who is open to AI tooling but not evangelical. Evangelical leads produce rosy pilot data that doesn’t generalize.

Workstreams

Workstream	Owner	Deliverable	Reference
Technical rollout	Platform team	Provisioning via SSO, commit-msg hook installed, CI checks for provenance + SAST running	Provenance trailer spec, SAST ruleset
Training	Enablement + pilot lead	Full team completed AI Coding Safety Module; pilot lead trained on gating decisions	Governance policy §9
Measurement	Pilot lead + Eng metrics team	Baseline captured for weekly shipping rate, defect rate, token usage per seat	Dashboard widgets
Gating calibration	AppSec + pilot lead	CI/CD gating tree tuned for pilot team’s rule FP rates	Gating decision tree
Incident review	CISO	At least one full incident response drill including provenance-triage step	Provenance trailer spec

What to measure during the pilot

Don’t try to measure productivity directly in 30 days — the noise overwhelms the signal. Instead, measure things that will support the productivity measurement later:

• Trailer coverage %. Target 95%+ by day 60. Lower indicates hook/CI gaps that would be exposed at scale.
• SAST finding rate per 1,000 AI-assisted commits. Establish the baseline; this becomes your renewal metric.
• Gating override rate. Target under 5%. Higher indicates gating is miscalibrated (too strict) or not taken seriously (too lenient).
• Training completion %. Target 100% of the pilot team.
• Self-reported developer friction. Weekly 5-minute survey — “did the tool help you this week? did the controls slow you down?” Qualitative but fast.

Do not report productivity uplift yet. The CFO will ask; the honest answer is “measurement infrastructure in place, 30 days of baseline captured, uplift reporting begins day 91.” That answer is more credible than a premature number.

Exit criteria for day 60

• Trailer coverage ≥95% on pilot team.
• Gating override rate under 5%.
• At least one incident drill executed end-to-end, including post-incident triage using provenance data.
• Pilot lead has produced a one-page “lessons learned” document flagging the controls gaps.

Days 61–90: Scale and Harden

Goal at the end of day 90: The tool is available to the full engineering org under the tuned control stack. The first quarterly evidence pack is ready for the audit committee.

Workstreams

Workstream	Owner	Deliverable	Reference
Rollout expansion	VP Eng + Platform team	Provisioning complete for all in-scope engineers; all onboarded via SSO	Team rollout guide
Controls tuning	AppSec	SAST ruleset updated with pilot-surfaced patterns; gating thresholds set	SAST ruleset
Training at scale	Enablement	100% of in-scope engineers completed training within 30 days of access	Governance policy §9
Measurement dashboard	Eng metrics team	Live dashboard for leadership: trailer coverage, SAST findings, override rate, usage	Dashboard widgets
Audit evidence pack	Compliance	Mapping from each internal control to each framework row (SOC 2, HIPAA, GDPR, etc.)	Compliance mapping
First 90-day review	CTO + CFO	Business case review against the 90-day tripwires set at approval	Business case

Exit criteria for day 90

• Full in-scope engineer population onboarded, trained, within seat and token budgets.
• Controls dashboard live and reviewed weekly by eng leadership.
• Audit evidence pack compiled and reviewed by CISO and external auditor (if one is engaged).
• Productivity measurement infrastructure in place (uplift number comes at day 180, not day 90).
• 90-day tripwires reviewed by CFO; renewal decision made on data rather than forecast.

What This Roadmap Assumes

The plan above works for an org with:

• 100–1000 engineers (larger needs more parallel pilots; smaller can compress phases).
• An existing SOC 2 or equivalent security posture (adding AI governance to an immature security program means fixing the program first).
• At least one team that can be dedicated to pilot without grinding the business to a halt.
• A CTO with the authority to block shadow IT — a policy no one enforces is worse than no policy.

If any of those assumptions don’t hold, the roadmap compresses, expands, or requires a dependency to be fixed first. In particular: do not roll out AI tooling at enterprise scale on top of a security program that can’t yet handle existing change-management auditably. AI is an amplifier; it amplifies immaturity.

The Cluster Map

The ten posts below — plus this one as the eleventh — make up the full enterprise AI coding playbook. Read in this order if starting from scratch:

Phase 0: Before the roadmap

1. Business case template — get budget approved
2. Risk assessment template — understand what you’re taking on

Phase 1: Select and contract 3. Evaluation scorecard — pick the tool 4. Procurement contract checklist — sign the right contract

Phase 2: Stand up governance 5. Governance policy template — publish the internal standard 6. Compliance mapping — know which regulation each clause feeds

Phase 3: Implement the controls 7. Provenance trailer spec — the evidentiary floor 8. SAST ruleset — the preventive layer 9. CI/CD gating decision tree — the merge-time control

Phase 4: Operate and measure 10. Team rollout guide — expansion 11. Token/usage analytics — the measurement layer

Each post is written to be read standalone. This pillar page is the map you return to when you’ve gone deep into one artifact and want to remember where it sits in the whole.

What’s Not in Scope

• Individual developer productivity advice — see the posts on token tracking, session analytics, and acceptance rate.
• Adoption psychology — the soft side of rollout is covered in developer resistance, motivating adoption, and helping traditional developers.
• Product-side AI use — if your product embeds AI (not just your engineering team using AI), different obligations under the EU AI Act and other regulations apply; that is a separate playbook.

The roadmap above is specifically the engineering-organization rollout. Most of the failure modes come from organizations treating AI coding tooling like a Slack deployment — procure it, email the team, move on. It’s more like rolling out a new compliance program with the productivity upside of a new developer tool. Treat it accordingly, and you end the ninety days with the upside captured and the downside visible and managed.