# AI Coding Adoption Playbook

## Goal

Move an engineering team from scattered AI coding usage to a measured operating loop that improves delivery across planning, coding, review, testing, incidents, and release.

Format: Operating playbook

Canonical page: https://2066labs.com/playbooks/ai-coding-adoption

## What this playbook does

- AI coding adoption is an operating-system change for engineering, not a tool rollout.
- The useful pattern is to map the SDLC, prove new workflows with alpha teams, package what works, and scale only the behaviors that move backlog without breaking quality.

- Step 1: Set the operating constraints
- Step 2: Map the SDLC before choosing tools
- Step 3: Make proof packages the operating loop
- Step 4: Pick alpha teams and real work
- Step 5: Build the context pack and agent chain
- Step 6: Redesign planning and review around prototypes, intent, and evidence
- Step 7: Fix the delivery system that AI exposes
- Step 8: Measure backlog moved, quality, dev days, and friction
- Step 9: Scale only packaged behavior that survives review
- Step 10: Use the templates
- Where 2066 Labs helps

## Step 1: Set the operating constraints

Start with constraints that make this an operating change rather than generic tool enablement.

| Item | Details |
| --- | --- |
| Target idea-to-release | - Set the target as 3x idea-to-release improvement, not faster typing.<br>- Break the delivery lifecycle into explicit blocks before assigning agents.<br>- Give agents a maintained context pack with the organization's architecture rules, security requirements, coding standards, and review expectations.<br>- Build an agent chain: product request to requirements, requirements to stories, stories to implementation, implementation to quality and architecture review.<br>- Use proof packages with alpha teams, then turn the winners into release packages for the broader organization. |
| Prove with small pods | - Use small pods for hard delivery work, especially when the work spans replatforming, M&A integration, or large backlog shifts.<br>- Do not assume software generation is the remaining bottleneck; human debate, handoffs, CI, and build systems can dominate.<br>- Expect code review, CI, and build infrastructure to break first when code throughput increases.<br>- Have engineering leaders inspect and work the backlog directly so they understand what can now be collapsed, automated, or removed.<br>- Let the pod prove a new delivery pattern on real product work before asking the rest of the organization to copy it. |
| Treat bottlenecks as movable | - Treat coding as only one part of the system; alignment and review can become the primary bottlenecks.<br>- Move discussions toward live prototypes instead of abstract debate.<br>- For AI-produced code, review intent, behavior, evidence, and risk rather than reading every generated line the old way.<br>- Use agents outside the editor: feature-flag cleanup, accessibility issues, alert triage, incident analysis, and repeatable maintenance work.<br>- Test and tune the workflow separately for old monoliths, newer services, mature products, early products, expert teams, and teams still learning agents. |

## Step 2: Map the SDLC before choosing tools

The first diagnostic is not which tool people like. It is where work actually slows down between idea and release.

| Item | Details |
| --- | --- |
| Lifecycle blocks | - Research.<br>- Design.<br>- Requirements.<br>- Planning.<br>- Implementation.<br>- Code review.<br>- Testing and CI.<br>- Release.<br>- Incident response.<br>- Compliance and operational management.<br>- Meetings and cross-functional alignment. |
| Bottleneck questions | - Where are humans waiting, debating, or repeating work?<br>- Where does AI already help but downstream systems cannot absorb the output?<br>- Where does product or design intent arrive too late for engineering to use well?<br>- Where do reviews restate standards that could have been supplied before generation?<br>- Where do CI, build, or release systems block otherwise completed work? |
| Decision output | - One SDLC time map.<br>- One ranked bottleneck list.<br>- One workflow to improve first.<br>- One team that owns the first proof package.<br>- One measurement set for flow, output, quality, and friction. |

## Step 3: Make proof packages the operating loop

The proof-package to release-package loop is the operating system of the rollout. It should happen before broad enablement.

| Item | Details |
| --- | --- |
| Hypothesis | - Name the workflow change.<br>- Name the SDLC block it should improve.<br>- State what should move: backlog, review time, CI recovery, release confidence, incident response, or quality.<br>- Name the risks reviewers and leaders should watch.<br>- Pick the alpha team and live work that will test it. |
| Proof package | - Context pack.<br>- Prompts or agent instructions.<br>- Workflow steps.<br>- Before-and-after evidence.<br>- Failures, surprises, and review notes.<br>- Metrics snapshot.<br>- Recommendation to keep, change, or stop. |
| Release package | - A cleaned version another team can run.<br>- Setup instructions.<br>- Context files and standards.<br>- Agent instructions.<br>- Review rules.<br>- Measurement fields.<br>- Known limits.<br>- Owner for updates. |

## Step 4: Pick alpha teams and real work

Adoption improves faster when small teams prove patterns on actual product work.

| Item | Details |
| --- | --- |
| Team shape | - Start with a small pod of roughly five or six people.<br>- Include a strong technical lead.<br>- Pull in product and design when the workflow depends on product decisions, prototypes, or UI changes.<br>- Use teams with enough ownership to change how work gets done.<br>- Give the pod access to the approved tools, models, repositories, environments, and budget it needs. |
| Work selection | - Choose real roadmap, backlog, migration, replatforming, compliance, maintenance, or quality work.<br>- Prefer work with visible before-and-after proof.<br>- Include work that touches review, CI, release, and stakeholder alignment.<br>- Avoid toy demos that do not test the real delivery system. |
| Operating rule | - The pod is not testing a tool in isolation.<br>- The pod is proving a new way to deliver useful software.<br>- The pod must produce reusable proof, not only completed code.<br>- Engineers, product, design, and leaders should inspect the work directly enough to learn what changed. |

## Step 5: Build the context pack and agent chain

Agents perform better when they receive the organization's rules before they generate work, instead of learning those rules through review corrections afterward.

| Item | Details |
| --- | --- |
| Context pack | - Architecture rules.<br>- Security requirements.<br>- Code style and testing standards.<br>- Service ownership and dependency maps.<br>- Release and rollback expectations.<br>- Product requirements.<br>- Design intent.<br>- Known customer constraints.<br>- Acceptance criteria. |
| Agent chain | - PRD or request agent turns loose asks into structured requirements.<br>- Story agent breaks requirements into scoped implementation units.<br>- Coding agent implements the scoped work.<br>- Quality agent checks tests, edge cases, and acceptance criteria.<br>- Architecture agent checks system fit and standards.<br>- Incident or operations agent helps explain alerts, failures, and likely causes. |
| Acceptance standard | - The agent should generate work that starts closer to the organization's desired answer.<br>- Reviews should catch exceptions and judgment calls, not restate basic standards.<br>- Repeated review failures should become context pack updates.<br>- Every agent in the chain should have a named owner, input, output, and review point. |

## Step 6: Redesign planning and review around prototypes, intent, and evidence

When code generation accelerates, planning and review need to change. Otherwise the organization just moves the bottleneck.

| Item | Details |
| --- | --- |
| Prototype-first planning | - Start important product discussions from a live prototype when possible.<br>- Use competing prototypes to clarify tradeoffs instead of extending abstract debate.<br>- Let product and design generate small experience changes for engineering review.<br>- Keep ownership clear even when roles become more fluid. |
| AI-produced-code review | - Review the intent behind the change.<br>- Review the demo or running behavior.<br>- Review tests, failure cases, and rollback plan.<br>- Review consistency with the context pack.<br>- Focus human attention on architecture, security, product correctness, and risk. |
| AI review | - Run AI review on code produced by humans and agents.<br>- Ask review agents to explain risk, missing tests, unclear intent, and standards drift.<br>- Use AI review to support human judgment, not to remove accountability.<br>- Feed repeated review misses back into the context pack and release package. |

## Step 7: Fix the delivery system that AI exposes

AI adoption exposes weak systems. Treat those failures as part of the rollout, not as side effects.

| Item | Details |
| --- | --- |
| Review overload | - Code volume can overwhelm human reviewers.<br>- Designers, PMs, and agents may generate more changes than engineers can consume.<br>- Line-by-line review becomes less reliable as generated output grows.<br>- Move review toward intent, behavior, tests, risk, and acceptance evidence. |
| CI and build bottlenecks | - CI and build systems can become the new constraint when code throughput increases.<br>- Track build duration, failure rate, flaky tests, queue time, and release blockers.<br>- Treat CI and build improvements as adoption work.<br>- Do not scale a workflow that produces more completed work than the delivery system can validate. |
| Adoption traps | - Teams copy tools without changing planning, review, or release behavior.<br>- Saved coding time gets absorbed by meetings, rework, or quality cleanup instead of producing more useful output.<br>- Old codebases, monoliths, and integration-heavy systems respond differently from newer products.<br>- Agents create false confidence in incidents or architecture decisions without enough human review.<br>- Leaders mistake activity metrics for business impact. |

## Step 8: Measure backlog moved, quality, dev days, and friction

The key warning is simple: saved coding time does not automatically become more output. Measure the conversion.

| Item | Details |
| --- | --- |
| Efficiency | - PR velocity.<br>- Issue cycle time.<br>- Review time.<br>- Release velocity.<br>- Compliance tickets completed by agents.<br>- Incident diagnosis time.<br>- Dev days saved or redirected. |
| Output | - Backlog moved by product area.<br>- Roadmap scope delivered.<br>- Customer-facing outcomes shipped.<br>- Operational toil removed.<br>- Work completed by smaller pods without lowering standards.<br>- Work that was previously blocked by staffing, integration, or coordination. |
| Quality and friction | - Defect rate.<br>- Rollback rate.<br>- Security and architecture review results.<br>- CI failure rate and build time.<br>- Engineer satisfaction.<br>- New friction created by AI.<br>- Whether active agent managers improve over time compared with non-users or light users. |

## Step 9: Scale only packaged behavior that survives review

Do not roll out AI coding by giving everyone tools and hoping usage spreads. Copy only workflows that have been packaged with setup steps, context, agent instructions, review rules, metrics, and known limits.

| Item | Details |
| --- | --- |
| Promote | - The workflow moved meaningful backlog.<br>- Quality stayed acceptable or improved.<br>- Review burden is manageable.<br>- CI and build systems can absorb the throughput.<br>- Another team can run the release package without the original alpha team present. |
| Revise | - The workflow works only for one codebase or one expert operator.<br>- Generated code creates review or CI overload.<br>- The context pack is missing standards.<br>- The proof package shows promise but does not yet have enough evidence.<br>- The measured gains are activity gains, not backlog or quality gains. |
| Stop | - The workflow increases code volume without useful output.<br>- The workflow hides risk from reviewers.<br>- The workflow depends on unsafe data or access patterns.<br>- The workflow makes incident response or release confidence worse.<br>- The team cannot explain what changed or why it should be copied. |

## Step 10: Use the templates

Use these templates as the minimum artifacts for the operating loop.

| Item | Details |
| --- | --- |
| SDLC time map | - Lifecycle block.<br>- Current time or effort share.<br>- Current bottleneck.<br>- AI role today.<br>- Target AI role.<br>- Human review point.<br>- Metric to watch. |
| Agent map | - Agent name.<br>- SDLC block.<br>- Input.<br>- Output.<br>- Context required.<br>- Allowed actions.<br>- Human approval point.<br>- Failure mode. |
| Context pack spec | - Architecture rules.<br>- Security requirements.<br>- Code style and testing standards.<br>- Product requirements.<br>- Design intent.<br>- Service ownership.<br>- Release and rollback rules.<br>- Known failure modes. |
| AI-produced-code review checklist | - Intent is clear.<br>- Demo or running behavior matches the request.<br>- Tests cover expected and failure paths.<br>- Rollback path exists.<br>- Architecture and security standards are met.<br>- The change matches the context pack.<br>- Review notes update the context pack when needed. |
| Proof package | - Hypothesis.<br>- Alpha team.<br>- Live work selected.<br>- Context pack used.<br>- Agent instructions.<br>- Workflow steps.<br>- Before-and-after metrics.<br>- Failures and surprises.<br>- Recommendation. |
| Release package | - Reusable workflow.<br>- Setup instructions.<br>- Required context files.<br>- Agent prompts or instructions.<br>- Review rules.<br>- Measurement fields.<br>- Known limits.<br>- Owner. |
| Metrics dashboard | - Backlog moved.<br>- Dev days saved or redirected.<br>- Issue cycle time.<br>- PR throughput.<br>- Review time.<br>- CI and build health.<br>- Defects and rollbacks.<br>- Engineer friction and satisfaction.<br>- Patterns promoted, revised, or stopped. |

## Where 2066 Labs helps

Use this playbook internally when the engineering owner, alpha team, and metrics are clear. Bring it to 2066 Labs when the work needs diagnosis, rollout design, templates, and proof across live workflows.

| Situation | How 2066 Labs helps |
| --- | --- |
| Bring us in when | - AI coding usage is spreading but the organization cannot prove what changed.<br>- Coding got faster but alignment, review, CI, build, incidents, or release became the bottleneck.<br>- Teams are copying tools without changing planning, review, or measurement.<br>- Leadership needs a credible model for dev days, backlog moved, quality, and friction.<br>- You need alpha teams, proof packages, release packages, context packs, review rules, and metrics designed around real work. |
| What we build with you | - SDLC time map.<br>- Organization-specific agent map.<br>- Alpha-team rollout plan.<br>- Context pack spec.<br>- Agent workflow instructions for planning, coding, review, incidents, and release.<br>- AI-produced-code review checklist.<br>- Proof package and release package.<br>- Metrics dashboard for backlog moved, quality, dev days, and friction.<br>- Review, CI, build, and adoption failure-mode backlog. |
| Simple next step | - Bring one engineering workflow, one alpha team, and the metrics you currently use to explain delivery.<br>- 2066 Labs will map the bottlenecks and identify the first proof package to build. |

## Reference

[Cursor panel on enterprise AI coding adoption](https://www.youtube.com/watch?v=aF-rolD9W7I)