The Pressure on Developers: Productivity Claims, Adoption, Legacy and Accountability

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.

Pressures on the developer: adoption and headcount, backlog and legacy, security and supply chain, duty and adversaries, the developer functions on which each lands, and the tests of the named developer

Figure 3.1: Five pressures land on the five developer functions, are graded as measured, surveyed, vendor or argued, and end at the named developer or team that must pass the tests Name, Understand and Revert.

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.

Reading the evidence: four grades

AI Threat, Chapter 4, set out an evidence ladder whose rungs are fiction, argument, laboratory demonstration, incident in the wild and pattern at scale (165, Nordqvist, 2026). Most claims about developers sit on the middle rungs, and the chapter adds a distinction that matters in software: who ran the study and what they sell. It therefore grades each claim in one of four ways.

Grade What it rests on Example in this chapter How far it carries
Measured A study with a stated sample and method, official text or a primary report The randomised field experiments; the randomised trial with experienced open-source developers; the text of the Cyber Resilience Act Applies to the sample, the task and the tool version tested; says nothing about another population without an argument
Surveyed Self-reported answers from a stated group of respondents The Stack Overflow Developer Survey; the DevOps Research and Assessment programme survey Describes what respondents report; sensitive to who answered and how the question was framed
Vendor A study or dataset produced by a company that sells a tool or a service in the area Veracode's report on generated code; GitClear's analysis of changed lines Read as a claim by an interested party; useful as a hypothesis, weak as a finding
Argued Reasoning from mechanism, with no measurement behind the specific claim The book's own claim that a faster generator moves the limit to review Only as strong as its premises, which the chapter states

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.

Adoption pressure

The first pressure is the plainest: AI tools are expected, and the expectation is wider than the evidence of benefit. Three sources press at once. Vendors sell licences and report usage. Executives read those reports and ask what the organisation is getting. Colleagues and candidates use the tools at home and at the previous employer, so that not offering them becomes a retention question. The chapter finds no independent measure of how strong executive pressure is, and says so; what it can grade is the use that results.

What developers report

The Stack Overflow Developer Survey of 2025 is the largest regular survey of developers. The 2025 edition reports over 49,000 responses from 177 countries and is a survey of self-selected respondents (217, Stack Overflow, 2025). On the page about AI, 84 per cent of respondents say they use or plan to use AI tools in their development process: 47.1 per cent use them daily, 17.7 per cent weekly, 13.7 per cent monthly or infrequently, and 5.3 per cent plan to start soon. Among professional developers, 50.6 per cent say they use them daily. The same survey reports that trust is lower than use: 32.7 per cent of all respondents trust the accuracy of AI output (3.1 per cent highly) and 45.7 per cent distrust it, and among professional developers the figures are 32.3 and 46.0 per cent. Two answers to a multiple-choice question about frustrations are telling: 66 per cent chose "AI solutions that are almost right, but not quite", and 45.2 per cent chose "Debugging AI-generated code is more time-consuming". These are surveyed claims. They describe self-selected respondents who chose to answer a developer survey, and the rounded percentages come from different bases, so the chapter does not add them together.

The DevOps Research and Assessment (DORA) programme's 2025 report draws on what Google Cloud describes as over 100 hours of qualitative data and survey responses from nearly 5,000 technology professionals. Its announcement states that 90 per cent of respondents report using AI at work and that more than 80 per cent believe it has increased their productivity (42, Harvey & DeBellis, 2025). The announcement also reports that 30 per cent have little or no trust in the code that AI generates. The programme is run by a vendor of cloud services and the figures are self-reported; they are surveyed claims, and the belief in higher productivity is a belief, which the next section sets against measurement.

Read together, the two surveys describe a tool that most developers use and a minority fully trust. That is a stable description of a technology adopted before its output is verified by its users, and it is the starting point of the book's argument that verification, not generation, is the scarce skill (Chapter 9).

Headcount expectations

Behind adoption sits a second expectation, not always stated: that tools that make developers faster should mean fewer developers, or the same number delivering more. The chapter separates three claims that are often fused. That an organisation plans to hire fewer developers is a fact about its plans, observable where it is recorded. That AI has reduced demand for developers is a causal claim that needs more than a plan. And that early-career developers are affected differently is an empirical question. The best-known measurement is a Stanford Digital Economy Lab working paper using administrative payroll data from ADP through June 2026, which finds that employment of workers aged 22 to 25 in AI-exposed occupations stands 19 per cent below where it would be had it kept pace with that of their less-exposed peers, that experienced workers show no comparable gap, and that the divergence persists when technology firms and computer occupations are excluded (51, Brynjolfsson et al., 2025). The authors call the facts early, descriptive indicators and not causal estimates, and note that the patterns attenuate when education is controlled for and that some of the divergent trends predate generative AI. The finding is measured, for American workers across exposed occupations and not for software developers alone, and descriptive. It is therefore not a finding that AI took developers' jobs, and Chapter 13 treats the junior pipeline with that limit in mind.

The chapter's own conclusion, labelled as such, is that the headcount expectation outruns the evidence in both directions: no measurement in this chapter shows that a team can safely be smaller because of a tool, and none shows that it cannot. Brooks's old observation that adding people to a late software project makes it later (215, Brooks, 1995) is a reminder that effort and output are not interchangeable in software, and it is a reason for caution about the opposite move: removing people because a tool is expected to replace their effort is a bet on a model of software work that the studies below do not establish.

What the productivity studies measured

Claims that a tool makes developers faster rest on a handful of studies, and they do not say the same thing. The chapter reports each with its population, task and conditions.

Study Population and task Reported result Grade and limit
Peng et al., 2023 (175, Peng et al., 2023) Recruited software developers asked to implement an HTTP server in JavaScript as quickly as possible, with and without an AI pair programmer The treated group finished 55.8 per cent faster; the abstract reports heterogeneous effects Measured. A single, self-contained task, set by the researchers, with the first generation of the tool
Cui et al., 2024 (176, Cui et al., 2024) Three randomised field experiments at Microsoft, Accenture and an anonymous Fortune 100 company, 4,867 developers The abstract reports a 26.08 per cent increase in completed tasks (standard error 10.3 per cent) and that each experiment is noisy Measured, in large employers. The chapter has read the abstract and not the full text; the measure is completed tasks, not delivered value
Becker et al., 2025 (63, Becker et al., 2025) A randomised trial with 16 experienced open-source developers working on 246 tasks in mature projects where they had on average about five years of experience Allowing AI tools increased completion time by 19 per cent; developers had forecast a 24 per cent reduction and afterwards estimated a 20 per cent reduction Measured. A small sample of experienced developers on familiar codebases with the tools of early 2025; the result is not a statement about other developers or later tools
DevOps Research and Assessment programme, 2025 (42, Harvey & DeBellis, 2025) Survey of nearly 5,000 technology professionals A positive relationship between AI adoption and delivery throughput and product performance, and a negative relationship with delivery stability; the announcement gives no effect sizes Surveyed. Association, not experiment; the announcement says that without robust control systems an increase in change volume leads to instability

The studies disagree on the surface. A task finished 55.8 per cent faster, 26 per cent more tasks completed and a task finished 19 per cent more slowly cannot all describe the same quantity for the same people. They agree underneath, as F161 predicts: the result depends on the task, the person and the conditions, and what developers believe about their own speed can diverge from what was measured. The most direct evidence of divergence is in the trial of experienced developers, where the forecast and the later estimate were a 24 and a 20 per cent reduction in completion time, and the measurement was a 19 per cent increase. The chapter draws no conclusion about any tool from this, because the tools have changed since the trial; it draws one about the claim. A figure of the kind "developers say they are faster" is not a figure of the kind "developers are faster", and an organisation that reports the first as the second has made an unsupported claim. The same applies to the DORA programme's finding that stability suffers where throughput rises without control systems: it is a warning about change volume, which D4 Prove and D5 Steward have to absorb, and the argued link to the review burden is developed in Chapter 9.

Nothing in this section is about the quality of the code that results, which is a separate question with its own, mostly vendor-produced, evidence (next sections). A tool that finishes tasks sooner and leaves code that is harder to maintain has moved cost from one function to another.

Backlog and legacy

The pressure to adopt meets an estate that was not built for it. Every organisation has a backlog of requested change and a body of code that it must keep running, and the two compete for the same people. Legacy is not an AI topic, but AI changes its position in two ways: it offers a way to read and move old code faster, which creates pressure to attempt migrations that were postponed, and it adds a stream of new code to an estate whose owners are already stretched. Chapter 12 treats modernisation and maintenance in detail; here the question is how legacy pushes on the role.

The evidence on code health under AI assistance is mostly vendor evidence. GitClear's report analyses 211 million changed lines of code authored between January 2020 and December 2024 in repositories owned by large technology companies and enterprises, using the vendor's own classification of changed lines (177, GitClear, 2025). On the report's page, lines classified as copy-pasted rose from 8.3 per cent of changed lines in 2021 to 12.3 per cent in 2024, and lines classified as moved, which the vendor links to refactoring and reuse, fell from 25 per cent to less than 10 per cent. The page states no publication date, does not describe the detection method or its thresholds, and its headline of a fourfold growth in clones does not match the percentages it gives. The chapter therefore reads the report as a vendor hypothesis: that generated code is added more readily than existing code is reused. It is a reason to look at the code health of one's own repositories (Chapter 12), not a finding about all of them.

What the chapter can say without a study is argued from the organisations' own records, and it is stark. Both example organisations keep more code than people who can explain it (see the subsection on the two organisations below). An inherited estate with low test coverage and owners who have left is a place where a faster generator increases the volume of change faster than the organisation's ability to prove it correct. The argued conclusion, the book's own, is that the backlog is not relieved by a faster generator unless the capacity to review, test and own grows with it. Where it does not, the backlog grows in a different place: in the review queue.

Security and supply-chain demand

The third pressure is the demand that software be secure and traceable, from customers, supervisors and the law, at the moment that a new source of insecure and unfamiliar code enters the repository. Chapter 10 treats the controls; this chapter grades the evidence for the pressure.

Three studies address the security of generated code, and they differ in kind. Pearce and colleagues generated 1,689 programs in 89 scenarios with GitHub Copilot in 2021 and found approximately 40 per cent of them vulnerable (228, Pearce et al., 2021). Perry and colleagues ran a user study at the ACM Conference on Computer and Communications Security in 2023 and found that participants with access to an AI assistant built on OpenAI's codex-davinci-002 model wrote significantly less secure code than those without, and were more likely to believe their code was secure; participants who trusted the assistant less and engaged more with their prompts produced fewer vulnerabilities (34, Perry et al., 2023). Veracode's October 2025 report states that code from over 100 large language models in Java, JavaScript, Python and C# introduced risky security flaws in 45 per cent of its tests (229, Veracode, 2025). The first two are laboratory demonstrations on models that have since been replaced. The third is vendor research, with a page that does not state the number of tasks. Taken together they support one cautious statement: in these studies, on these tasks and with these models, generated code contained security flaws at a rate that makes review and automated checking necessary. They do not support the statement that generated code is more or less secure than code written by developers of a given skill, because only the Perry study compared the two and it did so for a model of 2022.

The supply chain adds a second channel. A coding assistant that proposes a dependency, a build step or a configuration change operates on the organisation's trust boundary, and the frameworks for secure development, among them the NIST Secure Software Development Framework and its community profile for generative AI (232, Souppaya et al., 2022) (233, Booth et al., 2024), and the SLSA specification (231, OpenSSF, n.d.), describe the practices that customers and auditors increasingly ask for. The OWASP Top 10 for LLM applications lists supply chain and excessive agency among its risks (230, OWASP, 2025). The point for this chapter is that the demand for evidence of provenance and secure development grows at the same time as the volume of change.

Regulatory duty

Duty is the pressure with the firmest footing, because it is written down. The chapter previews the instruments; Chapter 24 maps them to duties. Each statement is attributed to the instrument and article and framed as an organisational and architectural implication, not as legal advice.

  • Regulation (EU) 2024/1689 (the AI Act). Article 26 sets out the obligations of deployers of high-risk AI systems (1, European Union, 2024). Article 4, as replaced by Regulation (EU) 2026/1744, requires providers and deployers to take measures to support the development of AI literacy of their staff and of others operating AI systems on their behalf, without a duty to guarantee any specific level for an individual (5, European Union, 2026). Implication: an organisation that gives developers AI tools has a duty of measures for the people who use them, and a deployer duty for any high-risk system its software supports.
  • Regulation (EU) 2024/2847 (the Cyber Resilience Act). Article 13(5) requires manufacturers to exercise due diligence when integrating components sourced from third parties, including open-source components that were not placed on the market commercially; Article 14(2)(a) sets an early warning for actively exploited vulnerabilities within 24 hours of the manufacturer becoming aware of it. Under Article 71(2), the Regulation applies from 11 December 2027, Article 14 from 11 September 2026 and Chapter IV from 11 June 2026 (242, European Union, 2024). Implication: whoever is a manufacturer of a product with digital elements needs to know what is in the product, including the parts a tool proposed. Whether an organisation is a manufacturer is a question for Chapter 24.
  • Directive (EU) 2024/2853 (the Product Liability Directive). Article 4(1) defines a product to include software; the Directive applies under Article 2(1) to products placed on the market or put into service after 9 December 2026, and Member States must transpose it by that date under Article 22(1). Under Article 8(1)(b), the manufacturer of a defective component integrated within the manufacturer's control can be liable (243, European Union, 2024). Implication: software defects are a liability question in a way that, for most software, they were not under the Directive it replaces.
  • Directive (EU) 2022/2555 (NIS 2). Article 21(2)(e) lists, among the measures that essential and important entities must take, security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure; Article 20(1) requires management bodies to approve the risk-management measures (3, European Union, 2022). Implication: secure development is a management-body matter, and a coding tool is part of development.
  • Regulation (EU) 2022/2554 (DORA). For financial entities, the ICT risk-management and third-party provisions reach the tools and suppliers that development depends on (2, European Union, 2022). In this book "DORA" always means this Regulation, not the research programme, which is written in full.

The common effect on the developer is that duties attach to named parties, not to tools. The earlier volumes reached the same conclusion for architects (F78, The Transformed Security Architect, Chapter 18) (166, Nordqvist, 2026): someone must turn each article into a control, and accountability cannot be delegated to a system. For developers that someone is the named developer or team that owns the change, which is what the stewardship principle of Chapter 4 formalises.

Adversaries with the same tools

The last pressure is the one the organisation does not choose. Defenders' tools are available to attackers, and the time between the disclosure of a weakness and its exploitation shrinks where the attacker can use a tool to search, adapt and repeat. The earlier volumes made this a design assumption (F35 and F36, AI Platform and Security, Chapter 18): patch velocity as a measured service level, and identity and approvals that resist synthetic media. For developers it means that the cost of leaving a known weakness in the estate rises, which is a pressure on D4 Prove and D5 Steward.

The chapter holds the evidence at its true rung. Anthropic published in November 2025 an account of activity it detected in mid-September 2025 in which, it reports, a threat actor used the provider's coding tool to perform 80 to 90 per cent of a campaign against roughly thirty global targets, with human intervention required only sporadically, and succeeded in a small number of cases. The provider also reports that the tool did not always work perfectly: it occasionally hallucinated credentials or claimed to have extracted secret information that was in fact publicly available (30, Anthropic, 2025). On the evidence ladder this is an incident in the wild, reported by the provider of the tool involved, covering only that provider's service, and the 80 to 90 per cent figure is the provider's estimate. It supports the statement that attackers use coding agents operationally. It does not support a claim about how often, or about the capability of attackers in general. The chapter describes what the account means for controls and not how it was done.

Accountability when a change goes wrong

Accountability pressure is older than AI, and two public incident reports show what it looks like when a change reaches many users. The chapter uses them as cases of release practice, not of AI. On 19 July 2024 CrowdStrike deployed a Rapid Response Content update to its Windows sensor at 04:09 UTC and reverted it at 05:27 UTC; the company attributes the failure to a bug in its content validator that let problematic content data pass validation, and states that it will deploy such content in stages, beginning with a canary deployment (28, CrowdStrike, 2024). In April 2022 an existing deletion script was run against 883 sites of Atlassian customers with identifiers of the wrong kind, which the deletion API accepted without checking; 775 customers were affected, all customers were restored by 18 April, and the report states that the outage spanned up to 14 days for a subset of them (76, Atlassian, 2022). In neither report is AI involved. In both, review and testing existed and did not catch the fault, because the check did not test what mattered, and recovery depended on someone who could undo the change.

These cases carry a lesson for this chapter. When a faster generator raises the number of changes, the number of occasions on which review and testing might miss what matters rises with it. The pressure on accountability is therefore a pressure on the gate and on the right to revert, and Chapter 23 returns to post-incident practice when AI wrote the change.

The evidence ladder for each claim

The table collects the claims of the chapter, the rung each sits on and the limit that follows. A reader who looks things up can use it as a register.

Pressure Claim Grade and rung Source Limit
Adoption 84 per cent of respondents use or plan to use AI tools; about a third trust the accuracy of the output Surveyed (217, Stack Overflow, 2025) Self-selected respondents; trust is self-reported
Adoption More than 80 per cent of respondents believe AI has increased their productivity Surveyed (42, Harvey & DeBellis, 2025) Belief, not measurement
Adoption Tasks finished 55.8 per cent faster; 26.08 per cent more tasks completed Measured, laboratory and field (175, Peng et al., 2023) (176, Cui et al., 2024) One task; abstract only for the field experiments
Adoption Experienced developers took 19 per cent longer with tools allowed Measured, field trial (63, Becker et al., 2025) 16 developers, early-2025 tools
Headcount Early-career employment in exposed occupations 19 per cent below trend Measured, descriptive (51, Brynjolfsson et al., 2025) US payroll data; not causal
Legacy Cloned lines up, moved lines down Vendor (177, GitClear, 2025) Undated page; undisclosed method
Security About 40, and 45, per cent of tests or programs with flaws Laboratory and vendor (228, Pearce et al., 2021) (229, Veracode, 2025) Models replaced; vendor method not given
Security Less secure code with an assistant, and more confidence Measured, user study (34, Perry et al., 2023) Model of 2022
Duty Articles and dates of the CRA, PLD, NIS 2, AI Act Measured, text of the instrument (242, European Union, 2024) (243, European Union, 2024) (3, European Union, 2022) (1, European Union, 2024) Applicability is a question for Chapter 24
Adversaries A coding agent performed most of a campaign Incident in the wild, provider-reported (30, Anthropic, 2025) One provider's view of its own service
Accountability Validator bug and a script run with wrong identifiers Measured, primary reports (28, CrowdStrike, 2024) (76, Atlassian, 2022) Not about AI

What the pressures have in common

Four things recur across the pressures. First, they arrive together: a developer in an organisation that has rolled out an assistant is asked to adopt it, to clear a backlog, to prove the result secure and traceable, and to answer to a regulator, in the same sprint. Second, they push on verification. Adoption raises the volume of change; legacy lowers the organisation's ability to check it; the law and the adversary raise the price of missing a defect. All three land on D4 Prove and D5 Steward, the functions in which the scarce skill is verification. Third, almost every figure that is cited in these discussions is a survey result, a vendor result or a result on a different population, and the measured evidence is narrow. Fourth, the pressures are not an argument against the tools. They are an argument that the organisation, and not the tool, must carry the burden of showing what has changed.

The book's own conclusion, drawn here for the whole of Part I, is that the strain on the role is a strain on the capacity to prove and to own, not on the capacity to produce. Part II follows the five functions with that conclusion in view.

Practical guide: mapping a developer's week by activity, load and AI contribution

Purpose. Show where a developer's hours go, where load and interruption fall, and where an AI tool touches the work under the delegation profile in force, so that a claim about the effect of a tool can be placed on the part of the week it could affect.

Roles. The developer, whose map it is and who owns it; the tech lead, who compares maps across the team; the engineering manager, who may see only team-level results; and, where telemetry is involved, the works council or union representative, who agrees the rules before any instrument is used.

Inputs. The developer's calendar and repository history for one sprint; the delegation profile (DLG-*) for the team; the list of tools and the usage mode of each. The map is estimated by the developer. It is not built from covert monitoring, and a team that wants instrumented data agrees it with the representatives first (Chapter 22).

Steps.

  1. List the activities of the sprint under the headings read and understand code, write code and tests, review colleagues' changes, specify and clarify, release, document, meet and coordinate, support and incidents, and learning.
  2. Estimate the hours of each, and the hours that were interrupted (broken by a request that was not planned).
  3. For each activity, enter the usage mode in which a tool could take part and the degree of delegation the profile allows for the work class concerned.
  4. Mark the hours with no tool touchpoint. Mark the hours with a touchpoint where the profile allows Level 0 Advisory only.
  5. Compare the maps of the team at team level, never per named person, and state the evidence age of the estimate.

Artefact. A work-and-load map, kept in the team's repository with the sprint it describes and reviewed with the delegation profile.

The map below is illustrative. It follows a senior developer of Nordvik Region's case platform team across one two-week sprint in October 2030, under DLG-NR-DEV-01 (AIDR-1101), and is an estimate by the developer, not an instrumented measurement.

work_and_load_map:
  holder: Linnea Sjöberg
  role: ROLE-NR-DEV-01
  team: case platform team
  sprint: 2030-10-06 to 2030-10-17
  basis: estimate by the holder from calendar and repository history
  evidence_age_days: 0
  delegation_profile: DLG-NR-DEV-01
  hours_total: 80
  activities:
    - name: read and understand existing code
      hours: 16
      interrupted_hours: 5
      work_class: migrate
      delegation_level: Level 0 Advisory
      tool_touchpoint: true
    - name: write code and tests
      hours: 14
      interrupted_hours: 3
      work_class: generate
      delegation_level: Level 1 Assisted
      tool_touchpoint: true
    - name: review colleagues changes
      hours: 8
      interrupted_hours: 1
      work_class: review
      delegation_level: Level 0 Advisory
      tool_touchpoint: false
    - name: specify and clarify with product owner
      hours: 6
      interrupted_hours: 1
      work_class: specify
      delegation_level: Level 0 Advisory
      tool_touchpoint: false
    - name: release and deployment work
      hours: 5
      interrupted_hours: 1
      work_class: deploy
      delegation_level: Level 0 Advisory
      tool_touchpoint: false
    - name: documentation
      hours: 3
      interrupted_hours: 0
      work_class: document
      delegation_level: Level 2 Supervised
      tool_touchpoint: true
    - name: modernisation assessment preparation
      hours: 6
      interrupted_hours: 1
      work_class: design
      delegation_level: Level 0 Advisory
      tool_touchpoint: false
    - name: meetings and coordination
      hours: 10
      interrupted_hours: 0
      work_class: none
      tool_touchpoint: false
    - name: support, incidents and consultant questions
      hours: 8
      interrupted_hours: 8
      work_class: operate
      delegation_level: Level 0 Advisory
      tool_touchpoint: false
    - name: learning and unplanned work
      hours: 4
      interrupted_hours: 2
      work_class: none
      tool_touchpoint: false
  summary:
    hours_with_touchpoint: 33
    hours_without_touchpoint: 47
    interrupted_hours: 22
    note: touchpoint means an activity in which the profile lets a tool take part and the holder expected to use one; Level 0 Advisory elsewhere is available on request and is not counted; it does not mean that the tool was used or helped

Reading the map: 33 of the 80 hours have a place where a tool of Mode 2 could take part, and in 16 of those the profile allows an advisory reading of legacy code only. The map says nothing yet about whether the tool helped; it says where a claim about help could apply. A claim that the pilot made the developer "a third faster" would have to apply to the 14 hours of code writing, the 3 of documentation and the 16 of reading code, and could not by that route change the 22 hours of interruption or the 47 hours with no touchpoint. This is the book's own arithmetic, not a measurement, and it is why Chapter 20 asks what was measured on which hours.

Across the usage modes

Mode What presses Highest degree of delegation allowed in the two organisations at the start of the year What the pressure asks of the named developer
Mode 0 Ambient AI Completion enabled by an IDE update, without a decision; no record of use Nordvik: Level 1 Assisted for completion; Hansa: not recorded Name the feature, record the decision afterwards (Nordvik did, as AIDR-1102)
Mode 1 Conversational assistants Pasting code and data into a chat; secrets in prompts Level 0 Advisory Approved tool only; no credentials or special-category data
Mode 2 Embedded workplace assistants Licence-seat and acceptance-rate reporting; IDE assistants Nordvik: Level 1 Assisted for generate, refactor and test drafts, Level 2 Supervised for document; Hansa: Level 2 Supervised for generate outside security-critical and payment paths Understand what was accepted; report measured, not quoted, figures
Mode 3 Agentic work tools Volume of pull requests; dependency proposals Nordvik: platform team only, drafting, never applying; Hansa: Level 2 Supervised, with one Level 3 Bounded class (patch-level dependency updates, MND-HM-DEV-01) Name the owner of the agent's mandate; the agent never merges to the protected branch
Mode 4 AI applications built for developers Test-drafting and legacy-explanation tools Nordvik: none; Hansa: Level 1 Assisted (HM-DEV-002), Level 0 Advisory (HM-DEV-003, planned) The oracle for a change written by someone other than its author
Mode 5 Autonomous production agents The temptation to extend the operations agent to code Nordvik: none; Hansa: no coding agent merges or deploys alone Level 4 is never used for a production change without a gate the change cannot alter

The Level 4 prohibitions apply across the table. They are not a finding of this chapter but a rule of the book: Level 4 Autonomous is never used for a change to production without a gate that the change itself cannot alter, for code in a security-critical or safety-critical path without human review by a named developer, for a change to the agent's own mandate, permissions, credentials, test oracles, review rules or pipeline gates, for an irreversible action on production data, or for a decision about a named person's employment, pay, performance rating or access to work. Pressure to adopt is not a reason to move a row of the table.

Nordvik Region and Hansa Mutual

Both organisations show the pressures in a form that can be checked against records.

Nordvik Region. The Applications and Integration unit has 31 people, of whom 18 are developers, and about 25 employees write code as their main work, with about 22 consultant developers working inside its teams under framework agreement NR-2025-102 and supplier teams whose code the Region does not review. Adoption pressure came through the IDE vendor's update of March 2030, which switched on completion before any decision was recorded (AIDR-1102), and through the note of April 2030 to the executive committee that described the pilot NR-DEV-001 of 12 developers as "a third faster". The note rested on IDE telemetry of a 31 per cent acceptance rate and a survey answered by 9 of the 12; nobody had measured delivery time (AVR-NR-2030-01). Under the default expiry of 90 days for usage and 180 days for value, the usage figures had expired by July 2030 and the value claim lapses in October 2030. Backlog and legacy press harder: 1.1 million lines of Java and PL/SQL in the case system SVC-NR-003 with vendor support ending in 2033, nine inherited systems, a regression pack for only the portal and the benefits workflow, and 31 per cent of 96 repositories with an owner who has left or changed team (OWN-NR-2030-00). The 2030 budget line of EUR 1.2 million for assessment of modernisation is unallocated. Supply-chain pressure showed in the incident of March 2030 (INC-NR-2030-0071, illustrative), in which a consultant pasted a test-database connection string into an unapproved public assistant; the platform team rotated the credential within 40 minutes, and the framework agreement had no clause on AI tools. Duty is public-law: public procurement for the tender NR-2030-041, public-access and archives rules for code and design documents, and open questions on the Cyber Resilience Act for published components. Representation is by negotiation before an important change under the Swedish pattern (MBA-NR-2030-03, Chapter 22).

Hansa Mutual. Group Application Development has about 480 employees, of whom about 290 are developers, and about 190 external developers work in its teams, mostly from the nearshore partner Wiślana Software. Adoption pressure is visible in the figure that reached the group CIO's report to the executive board in February 2030: 42 per cent of committed lines in the claims product line were "AI-assisted", counting accepted suggestions as a share of lines; a sample of 40 merged pull requests in August 2030 found 27 per cent of lines traceable to an accepted suggestion, with no measure of whether they stayed (AVR-HM-2030-01). The first figure is seven months old at the start of the year and past its 90-day expiry. Legacy presses through the policy administration platform SVC-HM-003, with about 6.5 million lines of COBOL and PL/I maintained by twelve people, five of whom are within eight years of retirement, and through the duplicated settlements of June 2029 (INC-HM-2029-0207, illustrative, no AI involved), in which the only other reviewer was the one person who knew the module. Supply-chain pressure showed in the dependency name that did not exist in the registry, proposed by a coding agent and refused by the Hansa Forge package proxy (FND-HM-2030-0012, illustrative), after two earlier proposals of the same kind that nobody had been told about. Duty is financial-sector: DORA's change and third-party rules, the register of information for the assistant contract HM-PROC-AIDEV-2029-01, and the open question whether the mobile claims app and the broker plug-in are products with digital elements under the Cyber Resilience Act. Representation is by co-determination under BetrVG §87(1) no. 6, with the developer annex KBV-IT-2024-DEV-01 drafted in autumn 2030.

The two cases differ in scale, in law and in the shape of their legacy, and agree on the pattern the chapter set out: an adoption claim with no evidence age that has reached a senior body, a measured figure lower than the claim or no measured figure, legacy that outlives its authors, bought capacity whose contracts do not mention AI, and a duty that attaches to named parties.

Outlook: observable, expected, speculation

The labels follow AI Governance, Chapter 22 (162, Nordqvist, 2026). The author's own projections are kept to Chapters 29 and 33.

  • Observable. Most developers in the large surveys use AI tools and a minority fully trust the output (217, Stack Overflow, 2025) (42, Harvey & DeBellis, 2025). Measured effects on completion time differ by task and developer (175, Peng et al., 2023) (176, Cui et al., 2024) (63, Becker et al., 2025). Employment of the youngest workers in exposed occupations is below trend in one dataset, descriptively (51, Brynjolfsson et al., 2025). Duties and dates of the instruments are fixed in their text.
  • Expected. Product liability for software applies to products placed on the market after 9 December 2026, and the Cyber Resilience Act applies from 11 December 2027, which are decided instruments and therefore a stated basis for expecting customers and auditors to ask for evidence of secure development and of component provenance. Pressure on D4 Prove and D5 Steward is expected to rise with the volume of generated change wherever review and test capacity do not.
  • Speculation. Any statement that headcount in development will fall by a stated share because of a tool is speculation as long as no measurement ties a smaller team to equal or better delivery. The same holds for the opposite statement.

Summary

Five pressures act on developers: adoption and the expectations about headcount that accompany it, the backlog and legacy it meets, the demand for secure and traceable software, the duty that law places on named parties, and adversaries who use the same tools. The chapter graded the evidence for each as measured, surveyed, vendor or argued, and found that the measured evidence is narrow and varies by task, person and tool, that perceived and measured speed can diverge, that the evidence on code health and security is largely vendor evidence or concerns models that have been replaced, and that the duties are the firmest ground because they are written down.

The pressures concern all five developer functions. Adoption lands on D3 Build and, through the volume of change, on D4 Prove. Legacy and the backlog land on D5 Steward and on D2 Design, where migration choices are made. Security and supply-chain demand land on D4 Prove, duty on D5 Steward, and the problem of stating what is wanted, D1 Frame, absorbs requests that arrive faster than they can be understood. The common effect, and the book's own conclusion for Part I, is that the strain on the role is a strain on the capacity to prove and to own more than on the capacity to produce.

For Nordvik Region and Hansa Mutual the practical consequence is the same: replace the quoted figure with a measured one and give it an evidence age, find the owners that have left, and make the named developer's tests of Name, Understand and Revert the condition for any move up the ladder. Chapter 4 defines the developer loop, the delegation ladder and the stewardship principle that these pressures make necessary. What a reader can do now is draw the work-and-load map for one sprint of one team, before the next claim about a tool is repeated upward.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
  2. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
  3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
  4. CrowdStrike (2024). External Technical Root Cause Analysis: Channel File 291, and Falcon Content Update Preliminary Post Incident Review. (28, CrowdStrike, 2024)
  5. Perry, N., Srivastava, M., Kumar, D. and Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? ACM CCS '23; arXiv:2211.03622. (34, Perry et al., 2023)
  6. Harvey, N. and DeBellis, D. (2025). Announcing the 2025 DORA report: State of AI-assisted Software Development. Google Cloud Blog, 23 September 2025. (42, Harvey & DeBellis, 2025)
  7. Brynjolfsson, E., Chandar, B. and Chen, R. (2025, revised 2026). Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence. Stanford Digital Economy Lab. (51, Brynjolfsson et al., 2025)
  8. Atlassian (2022). Post-Incident Review on the Atlassian April 2022 outage. (76, Atlassian, 2022)
  9. Nordqvist, G. (2026). AI Governance. The Architecture as Code Series, Book 2. (162, Nordqvist, 2026)
  10. Nordqvist, G. (2026). AI Platform and Security. The Architecture as Code Series, Book 3. (163, Nordqvist, 2026)
  11. Nordqvist, G. (2026). AI Threat. The Architecture as Code Series, Book 5. (165, Nordqvist, 2026)
  12. Nordqvist, G. (2026). The Transformed Security Architect. The Architecture as Code Series, Book 6. (166, Nordqvist, 2026)
  13. Nordqvist, G. (2026). AI Blue. The Architecture as Code Series, Book 8. (168, Nordqvist, 2026)
  14. Nordqvist, G. (2026). AI Operations. The Architecture as Code Series, Book 10. (170, Nordqvist, 2026)
  15. Nordqvist, G. (2026). AI Leader. The Architecture as Code Series, Book 11. (174, Nordqvist, 2026)
  16. Peng, S., Kalliamvakou, E., Cihon, P. and Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590. (175, Peng et al., 2023)
  17. Cui, Z. (K.), Demirer, M., Jaffe, S., Musolff, L., Peng, S. and Salz, T. (2024). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. SSRN 4945566. (176, Cui et al., 2024)
  18. GitClear (2025). AI Copilot Code Quality: 2025 Look Back at 12 Months of Data. (177, GitClear, 2025)
  19. Brooks, F. P. (1995). The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition. Addison-Wesley Professional. (215, Brooks, 1995)
  20. Stack Overflow (2025). 2025 Stack Overflow Developer Survey. (217, Stack Overflow, 2025)
  21. Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B. and Karri, R. (2021). Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions. arXiv:2108.09293. (228, Pearce et al., 2021)
  22. Veracode (2025). October 2025 Update: GenAI Code Security Report. (229, Veracode, 2025)
  23. OWASP Gen AI Security Project (2025). OWASP Top 10 for LLM Applications 2025. (230, OWASP, 2025)
  24. Open Source Security Foundation and Linux Foundation. SLSA specification. (231, OpenSSF, n.d.)
  25. Souppaya, M., Scarfone, K. and Dodson, D. (2022). Secure Software Development Framework (SSDF) Version 1.1. NIST SP 800-218. (232, Souppaya et al., 2022)
  26. Booth, H. et al. (2024). Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile. NIST SP 800-218A. (233, Booth et al., 2024)
  27. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 (Cyber Resilience Act). Official Journal of the European Union, 20 November 2024. (242, European Union, 2024)
  28. European Parliament and Council of the European Union. Directive (EU) 2024/2853 on liability for defective products. Official Journal of the European Union, 18 November 2024. (243, European Union, 2024)
  29. Becker, J., Rush, N., Barnes, E. and Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR; arXiv:2507.09089. (63, Becker et al., 2025)
  30. Anthropic (2025). Disrupting the first reported AI-orchestrated cyber espionage campaign. 13 November 2025. (30, Anthropic, 2025)
  31. European Parliament and Council of the European Union. Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). Official Journal of the European Union, 24 July 2026. (5, European Union, 2026)