What Developers Did Before: Craft, Waterfall, Agile, DevOps and Open Source

Software development did not begin with AI, and neither did the argument about how developers should organise themselves. A developer, a tech lead or an engineering manager who asks what AI does to the role inherits seventy years of answers to an earlier question: how should people who make software, and answer for it, work together so that it is correct, changeable and still understood when its authors have gone? This chapter sets out those answers as the baseline for Chapters 5 to 12. It concerns all five developer functions, D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward, because every practice described here placed its weight on one or two of them, and AI moves that weight again.

The chapter makes one argument that the rest of the book relies on. Each practice in the lineage answered a scarcity: of skill, of the ability to reason about code, of predictability, of feedback, of ownership, of reusable parts, of attention. When AI makes one of these scarcities cheaper, the part of the role that existed to relieve it is the part that changes. The parts that answered a scarcity AI does not touch stay, and they weigh more. That reading is the book's own, drawn from the evidence below; it is not a finding of any single study, and the chapter says so where it matters.

Figure 2.1: The lineage of development practice, with the scarcity each answered.

Why start with the past

Three reasons make the history useful here, and completeness is not one of them. The first is that claims about AI and developers repeat older claims. Statements that a new tool will make programmers unnecessary, or that a method will make projects predictable, have been made before, and the earlier outcomes are evidence even where they are modest. Frederick Brooks, in the essay "No Silver Bullet" (1986), reprinted in the anniversary edition of The Mythical Man-Month, distinguished the essential difficulty of software, which lies in specifying, designing and testing a conceptual construct, from the accidental difficulty of representing it in a language on a machine, and argued that earlier breakthroughs such as high-level languages had removed accidental difficulty and that no single development would remove the essential kind (215, Brooks, 1995). That distinction returns in every section that follows, and in Chapter 4.

The second reason is that Chapters 5 to 12 describe each developer function "without AI first". They need a baseline that is more than a caricature. A reader who knows what the pull request was meant to achieve, what continuous integration was meant to prevent and what a dependency is a bet on will judge an agent's pull request better than one who knows only the tool.

The third reason is that the two organisations of this book are products of this history. Nordvik Region's teams grew out of a procurement tradition in which a vendor delivered a system against a requirements document; Hansa Mutual's product teams run agile delivery on an internal platform. Each carries inherited practices that AI will meet unchanged, and the sections below say which.

The treatment is selective. It follows the lineage that European enterprises and public authorities inherited, states for each practice what it answered and what it left out, and reports evidence where there is some. It does not repeat the history of operations in AI Operations, Chapter 2 (runbooks, ITIL, DevOps, SRE), or of leadership models in AI Leader, Chapter 2; it points to them (170, Nordqvist, 2026), (174, Nordqvist, 2026). It builds on two conclusions of the earlier volumes: that architectural decisions are kept as short, numbered, immutable records beside the code so that the rationale outlives the people who made it (Architecture as Code (Chapter 4)), and that system design mirrors the communication paths of the organisation that builds it, and that platform teams act as internal service providers (Architecture as Code (Chapter 17)) (161, Nordqvist, 2025), with Conway's observation (77, Conway, 1968).

A lineage of development practice

The craft tradition and automatic coding

The oldest practice is the one that needs least description. Software was written by individuals who held the knowledge of a system in their heads and passed it on by working beside a successor. The scarcity was skill, together with machine time: the work was expensive because few people could do it and the machines were slow and shared. The craft tradition has not gone. The senior developer who keeps a case system's history, and the junior who learns by reading that senior's reviews, are its present form, and Chapter 13 treats what happens to it when the junior's first tasks are generated.

What the craft tradition left unanswered was scale. Knowledge held in heads does not survive turnover, and a project of many people cannot be held in one head. Brooks's essays are the classic account of what happens when more people are added to a late project: the communication cost grows with the number of people, and the schedule does not shrink in proportion (215, Brooks, 1995). The rest of the lineage can be read as a series of attempts to make a large system tractable for people who do not share a head.

Structured programming

In March 1968 Edsger Dijkstra published a short letter arguing that the unrestrained go to statement should be abolished from higher-level programming languages, because it makes it hard to follow the progress of a program through its text (117, Dijkstra, 1968). The wider movement it started, structured programming, held that programs built from a few disciplined constructs (sequence, selection, repetition) can be read and reasoned about. The scarcity it answered was the ability to understand code: not to write it, but to know what it does.

This is the first appearance of a theme that grows. A practice that makes code easier to read is a practice that lowers the cost of D4 Prove and D5 Steward, because both depend on a person being able to read what is there. A tool that generates code at a pace that exceeds anyone's reading capacity reverses the gain unless something else restores it.

Waterfall

The sequential model, in which requirements, analysis, design, coding, testing and operations follow one another, is usually attributed to Winston Royce's 1970 paper on managing the development of large software systems (118, Royce, 1970). The lecture summaries and bibliographic records available for this chapter indicate that Royce presented the plain sequence as the simplest model and then argued that it is risky for large systems, because problems found late in testing force a return to design. They also list the five additions he recommended: put program design first, document the design, do the work twice, plan, control and monitor testing, and involve the customer. The chapter could not open the paper itself; this account of it is therefore stated with that limit, and the label "waterfall" is later than the paper.

What the model answered was predictability and control. A public authority that buys a system for a fixed price from a supplier needs a document that says what will be delivered, a point at which delivery is accepted and a record of who agreed to what. Procurement law and audit practice in Europe still lean on this shape. Nordvik Region's inherited case-management system SVC-NR-003 was bought and customised in this tradition, and a new tender, such as NR-2030-041 for development assistants, is an open procedure under public procurement law, which presupposes a specification of what is bought.

What it left unanswered was change. A requirement written before anyone has used the system is a hypothesis, and the sequential model finds out that it is wrong late. For D1 Frame this is the central lesson: the document is not the intent, and a specification that cannot be tested against use is a cost without a benefit.

Agile and Extreme Programming

Extreme Programming, described by Kent Beck in 1999, combined a set of engineering practices, among them automated tests written with the code, small and frequent releases, continuous integration, refactoring, pair programming and shared ownership of the code, with a stance towards change that treats it as the normal condition of a project (119, Beck, 1999). In February 2001 seventeen practitioners signed the Manifesto for Agile Software Development, which values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan, while stating that the items on the right still have value (83, Beck et al., 2001).

The scarcity these practices answered was feedback and tolerance of change. A two-week iteration, a demonstrable increment and a test suite that runs on every change shorten the time between a wrong assumption and its discovery. The practice that matters most to this book is the one that is easiest to overlook: the automated test written by the person who writes the code made change safe, and it also made the test a statement of intent. Chapter 9 returns to this when the test is written by the same generator as the code, which is why the stewardship principle of Chapter 4 requires the test oracle to be independent of the generator.

What agile practice left unanswered was durability. Documentation valued below working software is documentation that is not there when the team has moved on, and shared ownership of the code, in the sense that anyone may change anything, can become ownership by no one. Both reappear below as a feature of the two organisations' repositories.

DevOps and "you build it, you run it"

The next scarcity was production feedback. In an interview published in 2006, Amazon's chief technology officer Werner Vogels contrasted the traditional model, in which software is handed across a wall to an operations group, with the one Amazon used, summarised in the sentence "You build it, you run it" (120, Gray, 2006). The idea is that a team which carries the pager for its own service learns from its own failures and designs differently as a result. It is the ownership idea behind D5 Steward, and a later section returns to it.

Research from the DevOps Research and Assessment (DORA) programme turned delivery performance into something that can be reported. Its guide defines throughput through change lead time, deployment frequency and failed deployment recovery time, and instability through the change fail rate and the deployment rework rate, and it states that speed and stability are not trade-offs (220, DORA & Google Cloud (n.d.), n.d.). The programme reported four key metrics in its 2014-2023 formulation and lists five in its current guide; this book says so once, here, and uses "the key metrics" thereafter. The history of the metrics, and the ways in which they mislead, belong to AI Operations, Chapter 20 (170, Nordqvist, 2026).

DevOps answered the wall between building and running. It left unanswered the load that this places on a team: a product team that owns build, test, deploy and run must also master the toolchain that does these things, which is the problem the next practices address.

Open source and package ecosystems

From the 1990s onward, the largest change in what a developer writes was a change in what the developer does not write. Open-source libraries, frameworks and package registries made the common parts of a system available to everyone. The scarcity answered was the effort to write what has been written before. A modern service of a few thousand lines of the organisation's own code stands on tens or hundreds of thousands of lines it did not write and did not read.

Nadia Eghbal's report for the Ford Foundation describes the other side: much of the labour that maintains this shared infrastructure is carried by volunteers with little institutional support, and the report calls for stewardship rather than control of digital infrastructure (121, Eghbal, 2016). The consequence for a development organisation is a new scarcity, which is the ability to know what one depends on and to answer for it. A dependency is a decision, usually unrecorded, and every dependency that a coding agent proposes is a decision someone must be able to name. Chapter 10 treats the supply chain; Chapter 26 treats licences, maintainers and sovereignty.

Platform engineering

The last step in the lineage answers the load that DevOps created. A platform team builds an internal developer platform, with golden paths, a pipeline, a package proxy and scanning preconfigured, so that product teams do not rebuild the toolchain. Read through Conway's observation that system structure follows communication structure, this is a choice of organisational structure made to get the system the organisation wants (the book's reading, not a claim of Conway's) (77, Conway, 1968). The DORA programme's 2024 report states that using an internal developer platform improves individual productivity, team performance and organisational performance, and warns that it can also reduce change stability and throughput, so that implementation should aim at developer independence (216, Google Cloud, 2024). The report, published in October 2024, rests on a survey; the programme's page gives no magnitudes, and the book relies on the direction of the finding only, as an association.

The scarcity here is cognitive load, and the practice is the one that matters most when an organisation has to put guardrails around coding agents, since the platform is where a mandate, a sandbox and a package proxy can be enforced outside the agent. Chapters 8, 11 and 16 build on that.

What each practice answered

The table summarises the lineage. The last column states which developer function each practice placed its weight on, which is the book's own mapping.

Practice	Period	Scarcity it answered	What it left unanswered	Function most affected
Craft and apprenticeship	Before and alongside all below	Skill, machine time	Scale, turnover	D3 Build
Structured programming	From 1968	Ability to read and reason about code	Intent, change	D3 Build, D4 Prove
Sequential (waterfall)	From 1970	Predictability and control of large projects	Late discovery of wrong requirements	D1 Frame, D2 Design
Agile and Extreme Programming	1999 and 2001 onward	Feedback, tolerance of change	Durability of knowledge, ownership	D1 Frame, D4 Prove
DevOps	From the mid-2000s	Production feedback, the wall between build and run	Cognitive load on the team	D5 Steward
Open source and package ecosystems	From the 1990s	Effort to write common parts	Knowing and answering for what is depended on	D3 Build, D5 Steward
Platform engineering	Recent years	Cognitive load of the toolchain	Platform as a single point of dependence	D2 Design, D5 Steward

Two things follow. First, no practice replaced its predecessor. A team that runs two-week sprints still writes a requirements document when a tender requires it, still uses structured control flow and still depends on open source. Real teams are layered, and the layers have different ages. Second, every row states a scarcity of attention, understanding or responsibility, and none states a scarcity of keystrokes. That observation, which is the book's own conclusion, is why the next section matters.

Earlier automation of code

AI is not the first technology to write part of a developer's code. Four earlier steps changed what was cheap.

Compilers and assemblers translated a language closer to the problem into instructions for the machine. Frameworks and libraries supplied the common structure of an application. Integrated development environments added navigation, refactoring support, static analysis and completion of names and next lines. Low-code and form-builder products let a person who is not a developer assemble an application from components. This section is the author's reading of a familiar history and cites no study; it relies on Brooks's distinction (215, Brooks, 1995).

Each step made accidental difficulty cheaper. A compiler removed the work of writing machine instructions, and it did so deterministically: the same source gave the same output, and a developer who needed to know what the compiler had done could in principle find out. A framework removed the work of writing the same plumbing again, and the developer could read the framework. Completion saved keystrokes. None of these removed the work of deciding what the software should do, how it should be structured, whether it is correct, or who answers for it after release.

Generative AI differs from the earlier steps in two respects that the rest of the book works out. Its output is not deterministic in the way a compiler's is, so "the same input gives the same code" is no longer a guarantee. And its reach is wider: it can draft requirements, designs, tests, reviews and documentation as well as code, which means it enters the functions where the essential difficulty lies. Chapter 4 defines the delegation ladder and the stewardship principle that follow from this. The earlier steps are best read as a lesson in what the previous cheapness left behind: after each of them, the scarce part of the work moved up towards framing, design, proof and ownership. Whether the same happens now is a question for Chapters 3 and 29, and the evidence is not yet in; that statement is expected, at most, and no more.

Low-code deserves a separate note, because it is the earlier automation that already crossed the boundary between developers and non-developers. About 140 staff at Nordvik Region build forms and small applications with the low-code product FormFlow, in about 60 applications, 11 of which handle personal data; Hansa Mutual's citizen builders on its low-code platform number about 400. Chapter 19 treats what happens when AI is added to that population. The point for this chapter is that the question "who owns what a non-developer built" was already open before AI.

How developers spend their time

Any account of what AI changes has to start from what developers do. Two field studies give a partial answer, and both have limits that matter.

Meyer and colleagues monitored 20 professional developers at four companies in Canada, the United States and Switzerland with a logging application on their computers for an average of 11 full workdays, and collected self-reports of perceived productivity at 60-minute intervals (218, Meyer et al., 2017). In the logged time, the largest shares of the logged day went to coding (21.0 per cent), email (14.5 per cent) and work-related web browsing (11.4 per cent). Using the debugger, reviewing others' code and using version control accounted for 2.4 per cent of the time together. Collaborative activities with colleagues, customers or managers took 24.4 per cent. The authors found that work was highly fragmented, with frequent switches between activities, and that productivity is personal: the same pattern did not predict the same perceived productivity in different people. Their own limits are plain: a small sample, all on Windows, studied for about two weeks each, with only computer activity captured unless the participant reported otherwise.

Xia and colleagues studied 78 professional developers in seven projects over 3,148 working hours and report that developers spent about 58 per cent of their time on program comprehension activities, with senior developers spending a significantly smaller share than juniors (219, Xia et al., 2018). The figures rest on the published abstract, as reproduced in library catalogue records; the full text was not read, and the finding is cited at the level of the abstract.

The two studies measure different things, with different methods. One classifies logged activity into categories; the other attributes time to comprehension. Their figures do not add up and should not be put in one chart. Neither measures the value of the time spent, and the SPACE framework makes the general point that developer productivity has several dimensions and cannot be reduced to one activity measure (62, Forsgren et al., 2021). They are also from before generative coding tools were in use, which is the reason to use them here: they describe a baseline.

Three conclusions follow, and they are the book's own. First, writing code, the activity that completion and generation address most directly, was a minority of the logged day in the first study. A tool that makes this activity faster addresses a part of the day, and the claim that it makes the developer faster has to be tested on the whole of the work, which Chapter 3 and Chapter 20 do. Second, reading and understanding code is, on the second study's figure, a large share of the work, so a tool that increases the amount of code to be read increases the largest cost rather than reducing it, unless it also helps the reader. Third, reviewing, debugging and tracing, the activities of D4 Prove, took a small share of the logged time in the first study. If verification becomes the scarce skill, as Chapter 4 argues, the organisation is starting from a position where little time was allotted to it. These are inferences from baseline figures, not findings about AI.

You build it, you run it

The ownership idea behind DevOps is the part of the lineage that the stewardship principle of Chapter 4 generalises. A team that is paged for its service has an answer to the question "who owns this?" that does not depend on a document. The answer is whoever gets the call.

Where the practice is absent, ownership decays, and both organisations show it. At Nordvik Region an inventory of July 2030 found that 31 per cent of the 96 repositories had an owner who had left the Region or changed team (OWN-NR-2030-00). At Hansa Mutual an audit of August 2030 found that 14 of 410 services had no active owner, and the COBOL estate was owned by a department, "Policy Systems", not by a person (OWN-HM-2030-00). The pre-AI cost of this was already visible. In June 2029 a change to the COBOL settlement module for quarter-end was approved by one reviewer who was also the only other person who knew the module, and 312 claims were paid twice before the duplicates were recovered within two days (INC-HM-2029-0207, illustrative, no AI involved). The post-incident review found that the module had no owner who could explain the change.

The incident is a pre-AI case of what the stewardship principle tests. Nobody could be named as owner, nobody but the author understood the change, and no one had a rehearsed way to revert it. Chapter 4 calls these the tests Name, Understand and Revert. The point of recounting it here is that AI does not create this failure; it can make it more frequent if the volume of change rises faster than the number of people who own and understand it. That is expected where change volume rises without ownership, and Chapter 12 and Chapter 23 take it further. AI Operations, Chapters 2 and 20, treat how "you build it, you run it" meets operations and its metrics; this book does not repeat them.

A pre-AI role description and a charter-as-code

A role description is the written form of what an organisation believes a developer is for. The following is an illustrative pre-AI job description for a senior developer at Nordvik Region, of the kind the Region's HR function would have held in 2027. It is reconstructed for the book, not quoted from a real post.

Senior developer, case platform team. You will design, develop and test new functionality in the case-management platform, take responsibility for the quality of your code, take part in code reviews, support colleagues, and take part in the team's on-call rota. Requirements: ten years' experience of Java and SQL, experience of agile working, good communication.

Everything in the text is true, and almost nothing in it can be checked. It lists activities, not decision rights; it says "take responsibility" without saying for what, to whom, or with what authority to stop a release; it says nothing of how the developer should use tools that write code, because there were none to speak of, and it will not survive the arrival of agents unchanged. It is a document about a person.

A role charter as code, in the sense of The Transformed Security Architect, Chapter 4, is a versioned artefact in the repository with a mandate, accountabilities, decision rights and evidence, reviewed on a date and changed through a pull request (166, Nordqvist, 2026). Chapter 14 governs the adopted charter for the senior developer (version 1.0.0). The abbreviated form below is an early draft (version 0.1) that shows only what changes in kind. The identifiers follow the book's families; the content is illustrative.

role_charter:
  id: ROLE-NR-DEV-01
  title: Senior developer, case platform team
  version: "0.1"
  organisation: Nordvik Region, Applications and Integration
  accountable_to: Head of Applications and Integration
  status: draft, illustrative
  baseline: pre-AI description of 2027, rewritten as a charter
  purpose: >
    Keep the case platform correct, changeable and understood,
    and answer for what is released from it.
  accountabilities:
    - Owns named parts of the case platform (see the ownership record)
    - Reviews changes to those parts and names who may approve them
    - Holds the authority to stop a release of those parts
  decision_rights:
    may_decide:
      - Acceptance of a code change in owned parts
      - Rollback of a release of owned parts
    may_not_decide:
      - Delegation of a development work class to a tool
        (set by the delegation profile)
  evidence:
    - Ownership record entry for each owned repository
    - Review records for changes to owned parts
  review_due: "2031-03-23"

The comparison is the point. The description lists what the person does; the charter states what the person answers for and what the person may stop. The first can be satisfied by a developer who accepts everything an assistant offers; the second cannot, because it makes acceptance a named act. The delegation profile DLG-NR-DEV-01 (AIDR-1101) is the companion artefact, and Chapter 4 defines both.

Practical guide: classifying the practices a team has

Purpose. To establish, before any AI tool is introduced or extended, which practices a team actually runs, what each was meant to answer and how much of that answer still holds. The result is the baseline against which later chapters measure change.

Roles. The tech lead and engineering manager lead it. A senior developer, a tester or quality engineer, and a platform engineer contribute. A works-council or union representative may attend where the team's practices are to be recorded for use in an agreement (Chapter 22).

Inputs. The repository list and its ownership file; the pipeline definitions; the last two quarters of pull requests and incidents; the team's written working agreement, if any; and the role descriptions in force.

Steps.

1. List the practices the team runs, by what it does, not by what it calls itself: how work is specified, how it is designed, how it is reviewed, how it is tested, how it is released, who is paged.
2. Place each practice in the lineage of this chapter. A practice may belong to more than one layer.
3. For each, state the scarcity it answered, in the team's own words.
4. Mark how much of the answer still holds: in force and evidenced, in force and not evidenced, or lapsed. Evidence means a record, not a recollection.
5. Mark which developer function the practice serves, and which tools already touch it at Mode 0.
6. Record the result and its date, and set a review date.

Result. A practice inventory kept in the repository. The file below is an illustrative entry for one Nordvik Region team.

practice_inventory:
  team: Case platform team, Nordvik Region
  taken: "2030-10-14"
  review_due: "2031-04-14"
  practices:
    - name: Two-week sprints with demo
      lineage: agile
      scarcity_answered: feedback
      status: in force, evidenced by demo notes
      function: D1 Frame
    - name: One colleague reviews each pull request
      lineage: agile, structured programming
      scarcity_answered: ability to read and reason about code
      status: in force, not evidenced beyond the platform's merge log
      function: D4 Prove
      note: no rule on who reviews generated code
    - name: Pager for the case platform
      lineage: DevOps
      scarcity_answered: production feedback
      status: in force, owner of the rota is the platform team, not the case team
      function: D5 Steward
    - name: CODEOWNERS file per repository
      lineage: agile, DevOps
      scarcity_answered: ownership
      status: lapsed for 31 per cent of repositories
      function: D5 Steward

Across the usage modes and degrees of delegation

The pre-AI baseline is a column of Level 0 entries with a few exceptions, and the exceptions are the interesting part. Mode 0, ambient AI, did not arrive in a new tool; it arrived as a feature in tools the lineage had already put in place. The table marks, for each practice, where an ambient feature already sits and what the higher modes change; the chapters named in the last column take it from there.

Practice	Pre-AI baseline	Where Mode 0 already sits	What higher modes change
Structured programming, review	A person reads the code	Linters and review-tool suggestions; completion of the next line	Generated code and AI review comments at Mode 2 and above (Chapters 7 and 9)
Waterfall, specification	A person writes the specification	Drafting help in documents and ticket tools	Specification as the source of intent for agents (Chapter 5)
Agile, testing	The author writes the test	Test-name and assertion completion	Tests drafted by the generator that wrote the code (Chapter 9)
DevOps, release	The pipeline deploys; a person is paged	Summaries in the ticket and ITSM tools	Agents that open changes and propose rollbacks (Chapter 11)
Open source	A person chooses a dependency	Package suggestions in the editor	Dependencies chosen by an agent; hallucinated names (Chapter 10)
Platform engineering	A person writes the golden path	Infrastructure-code completion	Mandates and sandboxes enforced by the platform (Chapter 8)

On the delegation ladder, a compiler, a linter and a pipeline are deterministic automation that was never placed on the ladder at all, because a person can explain what they do. Generative tools are the first that need a place on it, which is why the ladder of Chapter 4 exists. No Level 4 appears in the baseline, and no Level 4 prohibition is engaged by a history chapter. The prohibitions in Chapter 4 are the ceiling for what follows.

Nordvik Region and Hansa Mutual

The two organisations stand at different points in the lineage, and the differences predict where AI will meet resistance.

Nordvik Region. The Region's in-house development is 18 developers in Applications and Integration, working in four product teams (the case platform team has eight people), and seven platform engineers, with about 22 consultant developers working inside the teams under framework agreement NR-2025-102. Its inherited estate is the waterfall tradition made durable: the case-management system SVC-NR-003 is a customised vendor product of about 1.1 million lines of Java and PL/SQL, maintained for fourteen years, with vendor support ending in 2033, and nine inherited sector systems from the 2024 reorganisation, one written mostly as stored procedures. Its newer work is agile: two-week sprints, weekly releases of the citizen portal SVC-NR-002, monthly releases of the case platform, and quarterly releases of the inherited systems. Its platform team offers two golden paths and a package proxy that serves only approved registries. It has no site reliability function, so "you build it, you run it" is in practice carried by the platform team and not by the product teams. About 140 staff build with FormFlow. Mode 0 arrived without a decision: the IDE vendor's update of March 2030 switched next-line completion on, and the CIO recorded the decision afterwards (AIDR-1102). The pre-AI baseline of this chapter is thus a baseline with an ambient feature already in it, and Chapter 3 returns to what is known of its effect.

Hansa Mutual. Group Application Development has about 480 employees, of whom about 290 are developers in about 62 delivery teams, with about 190 external developers, and an internal developer platform, Hansa Forge, run by a team of 24. It is agile and DevOps-shaped throughout the product estate: the claims core SVC-HM-001, the portal and broker interface SVC-HM-005, and a catalogue of 410 services with recorded ownership. Beside it stands the lineage's oldest layer: the policy administration platform SVC-HM-003, about 6.5 million lines of COBOL and PL/I written between 1989 and 2008, maintained by twelve developers whose average age is 54 (illustrative), five of them within eight years of retirement. That layer is craft: knowledge held by people, passed by working beside them, with ownership held by a department. Its second approver is often the author's only colleague, as the incident of June 2029 showed. Hansa Mutual's site reliability function of about 95 people and its change policy for DORA-critical functions place D5 firmly in an organised structure for the product estate and not for the mainframe. Here DORA means Regulation (EU) 2022/2554, which governs the group's ICT risk and third-party arrangements, and it is treated in Chapter 24.

Taken together: Nordvik Region has more waterfall and weaker ownership, Hansa Mutual has stronger product practice and an older craft layer that is closer to retirement. Both will meet AI on top of their oldest layer first, because that is where the backlog is, and both have that layer owned by a role, not by a person.

Observable, expected, speculation

The history in this chapter is observable: the papers, manifestos and reports cited exist and say what is reported. That each practice answered a scarcity is the book's own reading and is stated as such. The two time-use studies are observable and describe the periods before generative coding tools; the inferences drawn from them are conclusions, not findings. The statements that follow are labelled by outlook.

• Observable. Ownership decays where it is recorded as a role or a file and not as a person who can be called: 31 per cent of 96 repositories at Nordvik Region, 14 of 410 services at Hansa Mutual, as found in the audits of 2030.
• Expected. Where the volume of change rises without a rise in the number of people who own and understand it, the cost of lapsed ownership rises. The supporting trend is the pre-AI pattern above; the instrument is the stewardship principle of Chapter 4, not a decided law.
• Speculation. That AI will do to the scarcity of understanding what the compiler did to the scarcity of machine instructions. There is no evidence for it yet; the evidence of Chapter 3 points both ways.

Summary

Development practice followed a lineage in which each step answered a scarcity: the craft tradition, skill; structured programming, the ability to reason about code; the sequential model, predictability; agile and Extreme Programming, feedback and tolerance of change; DevOps, production feedback and ownership; open source, the effort to write common parts; and platform engineering, the cognitive load of the toolchain. No step replaced the one before; real teams are layered, and so are Nordvik Region and Hansa Mutual. Earlier automation of code, from compilers to completion, made accidental difficulty cheaper and left the essential difficulty of D1 Frame, D2 Design, D4 Prove and D5 Steward where it was.

The two field studies available as a baseline suggest that writing code was a minority of a developer's logged day and that reading and understanding code was a large share of it, while review and debugging took a small one. These are figures from before generative tools and from small, specific samples, and the inferences drawn here are the book's own. They frame the question of Chapter 3: what is claimed about AI and developers, on what evidence. The ownership idea of "you build it, you run it" is the root of the stewardship principle that Chapter 4 defines with its tests, Name, Understand and Revert, and the lapsed ownership found in both organisations is the first thing it tests.

A role description lists activities; a role charter as code states what a person answers for and may stop. The reader can act on this now: take the practice inventory of the practical guide for one team, mark what is evidenced and what has lapsed, and date it. Chapter 3 takes up the pressure that makes that baseline urgent, and Chapter 4 defines the developer loop in which the five functions, the delegation ladder and the stewardship principle are set out.

Sources

1. Brooks, F. P. (1995). The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition. Addison-Wesley Professional (first edition 1975). ISBN 978-0-201-83595-3. (215, Brooks, 1995)
2. Conway, M. E. (1968). How Do Committees Invent? Datamation, April 1968. (77, Conway, 1968)
3. Beck, K. et al. (2001). Manifesto for Agile Software Development. (83, Beck et al., 2001)
4. Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B. & Butler, J. (2021). The SPACE of Developer Productivity: There's more to it than you think. ACM Queue 19(1), 20-48. (62, Forsgren et al., 2021)
5. Google Cloud, DORA (2024). Accelerate State of DevOps Report 2024. (216, Google Cloud, 2024)
6. Dijkstra, E. W. (1968). Go To Statement Considered Harmful. Communications of the ACM 11(3), 147-148. (117, Dijkstra, 1968)
7. Royce, W. W. (1970). Managing the Development of Large Software Systems. Proceedings of IEEE WESCON. (118, Royce, 1970)
8. Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley. (119, Beck, 1999)
9. Gray, J. (2006). A Conversation with Werner Vogels. ACM Queue. (120, Gray, 2006)
10. Eghbal, N. (2016). Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure. Ford Foundation. (121, Eghbal, 2016)
11. Meyer, A. N., Barton, L. E., Murphy, G. C., Zimmermann, T. & Fritz, T. (2017). The Work Life of Developers: Activities, Switches and Perceived Productivity. IEEE Transactions on Software Engineering 43(12). (218, Meyer et al., 2017)
12. Xia, X., Bao, L., Lo, D., Xing, Z., Hassan, A. E. & Li, S. (2018). Measuring Program Comprehension: A Large-Scale Field Study with Professionals. IEEE Transactions on Software Engineering 44(10), 951-976. (219, Xia et al., 2018)
13. DORA, Google Cloud (n.d.). DORA's software delivery metrics: the four keys. (220, DORA & Google Cloud (n.d.), n.d.)
14. Nordqvist, G. (2025). Architecture as Code. The Architecture as Code Series, Book 1. (161, Nordqvist, 2025)
15. Nordqvist, G. (2026). The Transformed Security Architect. The Architecture as Code Series, Book 6. (166, Nordqvist, 2026)
16. Nordqvist, G. (2026). AI Operations. The Architecture as Code Series, Book 10. (170, Nordqvist, 2026)
17. Nordqvist, G. (2026). AI Leader. The Architecture as Code Series, Book 11. (174, Nordqvist, 2026)