Most organizations begin with the wrong question: which coding agent should we buy? The tool matters, but the evidence points elsewhere. DORA's 2025 research describes AI mainly as an amplifier that magnifies an organization's existing strengths and weaknesses. It also finds that the greatest returns come from a strategic focus on the underlying organizational system, not from the tools themselves. dora
That finding changes the adoption problem. If agents amplify what a team already is, a team with unclear requirements, flaky tests, and weak review habits will produce unclear, flaky, weakly reviewed changes faster. A team with explicit conventions, reliable verification, and disciplined review gets more from the same tool.
The adoption task is therefore to build an environment where agent work is scoped, observable, verified, and accountable. This article walks through that idea in five parts: the human role, the rollout, the repository, the controls, and the measurement. It draws on the twenty-five sources above.
Part 1: People decide what, agents decide how
Anthropic analyzed about 400,000 interactive Claude Code sessions from October 2025 to April 2026 and found a clear division of labor. People decide what to build, and the agent decides how to build it. That is a useful default. It also shows where mistakes are costly: a weak "what" cannot be repaired by a strong "how". anthropic
Addy Osmani frames this as management. His orchestration guide treats delegation, task briefs, monitoring, verification, and integration as the practical work of running agents. Martin Fowler's analysis describes how human responsibility shifts. Engineers inspect fewer individual outputs and put more effort into the specifications, checks, and guidance around the agent. addyosmani
IBM's description of agentic engineering is a good outline of the workflow. Work is broken into tasks, assigned, orchestrated, reviewed, and iterated, with human engineers validating correctness, security, performance, maintainability, and alignment with requirements. The same source says teams need training in system design, not only prompting. ibm
Part 2: Roll out deliberately
Anthropic's rollout playbook recommends starting with a pilot group of 20–50 developers already comfortable with AI-assisted tools. It then suggests building internal expertise, creating custom commands for organizational workflows, and documenting standards in context files. It also recommends a dedicated channel for sharing practices and problems. To scale, it recommends internal champions and a kick-off hackathon instead of a phased rollout that leaves teams waiting their turn. resources.anthropic
My deck's 30/60/90-day plan is a more conservative proposal of my own, not a published benchmark. For a regulated or enterprise setting, choosing a smaller first team is a reasonable adaptation. The principle that holds across sources is to prove the workflow before widening access.
The GitHub and Anthropic guides agree on what makes a good first task. It should be well scoped, with clear acceptance criteria and a way to verify the result. Anthropic also recommends separating research and planning from implementation, so the agent does not solve the wrong problem. For larger features, it suggests having Claude interview the engineer and write a spec first. docs.github
Part 3: Make the repository legible
Agents work from what they can read. OpenAI's harness-engineering account describes repository-based knowledge, a concise entry-point file, and architecture enforcement as central to working with Codex at scale. The practical lesson is to keep the knowledge an agent needs in the repository, versioned and reviewable, not in someone's chat history. github
Instruction files help, with limits. HumanLayer argues that shared instructions should stay focused, with task-specific knowledge moved into separate, discoverable documents. One community collection suggests keeping a CLAUDE.md under 200 lines, though that is a heuristic from the community, not a standard. Anthropic's guidance says to run /init to generate a starter file and refine it over time. Cursor's rules documentation shows the same idea for team-wide and repository-scoped guidance. code.claude
The most useful content in these files is the exact test, build, and lint commands, architecture constraints, and team conventions that a linter does not enforce. Cursor's guide adds that persistent context and canonical examples are most valuable when an agent keeps repeating the same mistake. Compound Engineering turns this into a loop. Each cycle of planning, building, and reviewing ends by capturing lessons for the next one. github
Part 4: Enforce, don't just instruct
This is the point where adoption programs most often fail. Birgitta Böckeler's framework separates proactive guidance from feedback checks, and deterministic controls from AI-based judgment. An instruction asks an agent to follow a rule. A required check makes violations fail. beri
Security shows the gap clearly. Fowler's VibeSec article argues that prompt-level security instructions need deterministic backing, such as secret scanning, static analysis, and infrastructure validation. GitHub's responsible-use documentation covers execution isolation, constrained permissions, security scanning, and approval boundaries. It also says agent output still needs review and testing. A common configuration for local agents is deny-by-default with a tight allowlist and explicit denies for risky operations such as network calls. docs.github
Stripe's production case shows what isolation looks like at scale. Its system uses isolated development environments and a hybrid of deterministic and agentic steps, with unattended runs followed by human review. GitHub Agentic Workflows takes a similar approach for repository automation. It defines tasks in Markdown with configurable permissions, tools, sandboxing, and controlled outputs, while keeping deterministic CI/CD. stripe
Review is the other control point. Osmani argues that a change should arrive with verification evidence, and that human review keeps responsibility for intent, risk, and ownership. Anthropic's guidance on rollouts says the same from the tool side: use test-driven development to give the agent guardrails and clear success criteria. One team playbook adds a simple rule: never let an agent be the sole gate on a merge to protected paths. addyosmani
Part 5: Measure what the system delivers
The temptation is to count output: pull requests, lines, prompts. Anthropic's playbook explicitly points to measuring ROI beyond vanity metrics. DORA's ROI report offers a framework for managing the initial productivity dip of a rollout and for defending the budget afterwards. I recommend counting accepted changes and the total human effort around them, including planning, supervision, review, and correction. resources.anthropic
Be careful with industry statistics. One 2026 guide cites adoption figures and Gartner projections, but those describe adoption, not the return a given team will see. Stripe's weekly merge figure shows that a mature system can work at scale. It is not a forecast for a different organization. coderio
Part 6: Keep the counterweights
Two sources prevent the enthusiasm from becoming an assumption. HumanLayer's critique argues that harnesses alone do not guarantee long-term codebase quality or shared understanding, and that human steering remains necessary. Fowler's "What Is Code?" argues that clear abstractions, types, and tests make the code itself part of the agent's context and constraints. Both support the same conclusion: agents reward good engineering and expose weak engineering. github
Parallel work needs the same caution. Simon Willison's subagent pattern shows how delegation into fresh context windows can separate exploration from implementation. Osmani's guide is a reminder that parallel runs still need agreed boundaries and a single integration owner. simonwillison
Below is a ranked top-25 reading list, followed by an article that draws on it. The ranking is my own editorial judgment. I weighted practical usefulness for a team, how directly each source is about the source type (official guidance and first-hand case studies over commentary), and coverage across the topics a team has to settle. It is a curated list, not an exhaustive survey.
Top 25 reading list
| # | Material | Type | Best used for |
|---|---|---|---|
| 1 | Scaling Agentic Coding Across Your Organization, Anthropic | Official rollout playbook | Pilot, champions, enablement, ROI resources.anthropic |
| 2 | Your AI coding agents need a manager, Addy Osmani | Practitioner guide | Delegation and supervision addyosmani |
| 3 | DORA: State of AI-assisted Software Development 2025 | Research report | The organizational-system view dora |
| 4 | Best practices for using GitHub Copilot to work on tasks | Official guide | Task scoping docs.github |
| 5 | Best practices for Claude Code, Anthropic | Official guide | Plan-first workflow, context files code.claude |
| 6 | Harness engineering, OpenAI | First-hand case study | Repository knowledge, enforceable constraints github |
| 7 | Harness engineering for coding agent users, Böckeler | Architectural analysis | Guidance versus controls beri |
| 8 | Minions: Stripe's coding agents, Part 2 | Production case study | Isolation, hybrid workflows stripe |
| 9 | Compound Engineering, Every | Open-source workflow | Plan, build, review, learn loop github |
| 10 | Humans and Agents in Software Engineering Loops | Engineering analysis | Human responsibility martinfowler |
| 11 | AI writes code faster. Your job is still to prove it works | Review guide | Evidence-based acceptance addyosmani |
| 12 | Application card: GitHub Copilot Agents | Official responsible-use guidance | Execution controls, limits docs.github |
| 13 | The VibeSec Reckoning | Security analysis | Deterministic security checks martinfowler |
| 14 | How Claude Code is used in practice, Anthropic | Usage research | Human–agent division of labor anthropic |
| 15 | What is Agentic Engineering?, IBM | Vendor explainer | Governance and skills framing ibm |
| 16 | Best practices for coding with agents, Cursor | Official guide | Context, rules, iteration cursor |
| 17 | Rules, Cursor documentation | Official documentation | Shared, version-controlled rules cursor |
| 18 | Writing a good CLAUDE.md, HumanLayer | Practitioner guide | Concise instruction files humanlayer |
| 19 | My LLM coding workflow going into 2026, Osmani | Practitioner guide | Incremental workflow github |
| 20 | GitHub Agentic Workflows | Open-source implementation | Event-driven automation github |
| 21 | Subagents, Simon Willison | Practitioner pattern | Context separation simonwillison |
| 22 | BMad Method | Community methodology | Structured planning bmadcode |
| 23 | Agentic Coding Playbook, Wilmes | Community playbook | Explore–plan–code–verify github |
| 24 | Why Software Factories Fail, HumanLayer | Practitioner critique | Limits of automation-first thinking github |
| 25 | What Is Code?, Fowler | Engineering analysis | Maintainability as context martinfowler |
Near misses: The Agentic AI Engineering Team Playbook covers roles, RACI, and a 90-day rollout, but it is a vendor-style blog. DORA's ROI of AI-assisted Software Development report is worth reading for budget conversations. digitalapplied
Top comments (0)