Most development organisations that have bought AI coding tools can say how many seats they hold, and many can show an acceptance rate from the tool's own dashboard. Few can say what changed in the delivery of software as a result, for which work, and how they know. This chapter concerns D3 Build and D5 Steward. D3 Build is where the tools are used, in the editor, the pull request and the agent's run. D5 Steward is where the consequences land, in release, maintenance, incidents and the ownership of what was built. A claim about adoption in development is the place where the two meet: it is made about how code is written, and it is paid for in what has to be reviewed, tested, operated and reverted afterwards. The measures also depend on the other three functions, because the specification of D1 Frame and the independent oracle of D4 Prove are what make an outcome measurable at all.
The chapter argues that an adoption programme in development is led by treating every claim about adoption, productivity and quality as a claim in the sense of the series: it has a scope, a method, a date, a result and an expiry. It sets out how a programme is organised, what the established metric frameworks measure, why acceptance rate and lines of code mislead, what the productivity J-curve implies, how to run and stop an experiment, and what an adoption and value record looks like. The debate on whether AI makes developers more productive follows in four steps, and a verdict separates what is observable from what is expected and what is speculation.
The conclusions of the earlier volumes that carry this chapter are summarised so that it stands alone.
Primary topics explored
- What the earlier volumes settle
- Adoption is a programme with a portfolio
- What the metric frameworks measure
- Why acceptance rate and lines of code mislead
- The productivity J-curve
- Experiments inside the organisation
About AI Developer
AI Developer is Book 12 of The Transformed Architecture. It takes the developer as its subject and asks what happens when AI is used broadly in software development: the five developer functions (frame, design, build, prove, steward), the delegation ladder and the Level 4 prohibitions, the stewardship principle (name, understand, revert), verification as the scarce skill, the junior pipeline, adoption and productivity as claims that need evidence, regulation (the AI Act, the Cyber Resilience Act, the Product Liability Directive, NIS 2, DORA, the GDPR), ethics, intellectual property and sovereignty in the toolchain, and the developer as a person, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue, AI Purple, AI Operations and AI Leader.
developers at every level, tech leads and engineering managers, architects, platform engineers, site reliability engineers and testers, product owners and designers, leaders who decide on developer tooling, heads of public-sector IT and procurement, works councils and unions, educators, and supervisors and auditors.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 20: Measuring and Leading AI Adoption in Development in AI Developer gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Leading Change and Adoption” and is one of 37 drawn from the manuscript.