Developers are said to be under pressure so often that the statement carries little information. This chapter breaks it into parts that can be graded. Five pressures act on the person who builds software: the push to adopt AI tools and the expectations about headcount that travel with it, the backlog and the legacy that the push meets, the demand for secure and traceable software, the duty that European law places on named parties, and adversaries who use the same tools. The chapter concerns all five developer functions, D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward, which Chapter 4 defines, and shows on which of them each pressure lands.
The chapter is also an exercise in restraint. Statements about developers under strain come from four kinds of source: measurements, surveys of self-selected respondents, studies run by vendors who sell the tools, and argument. Chapter 2 described the craft as it was before AI, with its own scarcities. This chapter asks what strains the role now, and it keeps what was measured apart from what developers, executives and vendors report. It builds on conclusions of the earlier volumes: that adversaries work at machine speed and that patch velocity is a measured service level (F35 and F36, AI Platform and Security, Chapter 18) (163, Nordqvist, 2026); that measures which reward closing items faster are gamed (F105, AI Blue, Chapter 20) (168, Nordqvist, 2026); that a claim about adoption, readiness or productivity carries scope, method, date, result and expiry (F160, AI Leader, Chapters 4 and 20) (174, Nordqvist, 2026); and that studies of AI and productivity disagree on the surface and agree underneath, because effects depend on the task, the person and the conditions, and perceived and measured effects can diverge (F161, AI Leader, Chapter 3) (174, Nordqvist, 2026). AI Operations, Chapter 3, did the same exercise for operators (170, Nordqvist, 2026); this chapter fits it to the people who write the code that operators run.
Two cautions follow. A measured result is a measurement of its sample: almost nothing measured in this chapter was measured on the developers of a Nordic regional authority or a German-headquartered mutual insurer, on their codebases and with their tools, and where a study concerns other developers the chapter says so and treats it as a mechanism. And a survey of developers measures what developers say, which is worth knowing and is not the same as what happens to their work. The chapter reports surveys under the name of their publisher so that the reader can weigh the interest behind them. Chapter 2 gave the baseline against which any of this is read; Chapter 20 returns to how an organisation measures its own adoption.
Primary topics explored
- Reading the evidence: four grades
- Adoption pressure
- What the productivity studies measured
- Backlog and legacy
- Security and supply-chain demand
- Regulatory duty
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 3: The Pressure on Developers: Productivity Claims, Adoption, Legacy and Accountability in AI Developer gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Developer Role in Question” and is one of 37 drawn from the manuscript.