The Future of the Developer: Fewer, More or Different?

Every earlier chapter described development as it is now, or as it can be built now. This chapter looks ahead, and with Chapter 33 it is the only place in the book where the author states his own projections. It concerns all five developer functions: D1 Frame, because the specification may become the artefact that people spend most of their time on; D2 Design, because the constraints that bound a fleet of agents are a design problem; D3 Build, because the share of code written by people is the figure most often quoted and least often measured; D4 Prove, because verification capacity, not generation capacity, sets the pace of an agent-heavy team; and D5 Steward, because the future of the role is decided where somebody must be named for software that is in production.

The question in the title has three answers, and each is held by serious people. Fewer means fewer posts with the title developer. More means that cheaper software is demanded in larger quantities, so that total employment grows. Different means that the number matters less than the content of the work and the route by which people come to do it. The chapter sets out a horizon register, examines six trajectories, stages the debate in four steps, states the author's projections with the thresholds that would change them, and ends with a verdict and a practice the reader can start.

Trajectories of the developer to 2036: six trajectories, each with its label, the horizon register that records them, the named steward and the thresholds that feed back into the projections

Figure 29.1: Trajectories of the developer to 2036 with labels.

What this chapter builds on

Four conclusions from earlier volumes set the method. AI Governance (Chapter 22) governs an outlook as a horizon register: each trend is labelled observable, expected or speculation; observable trends justify commitment, expected ones preparation and speculative ones reversibility; and the register is valuable because it can be wrong in a reviewable way (162, Nordqvist, 2026). AI Threat (Chapter 4) supplies the habit of asking which rung of an evidence ladder a claim stands on, from fiction and argument to laboratory demonstration, incident in the wild and pattern at scale (165, Nordqvist, 2026). AI Operations (Chapter 27) gave a labelled projection for operations with five thresholds that would change it (170, Nordqvist, 2026). AI Leader (Chapter 29) did the same for leadership roles and separated the author's judgement from the book's findings (174, Nordqvist, 2026).

This chapter applies that form to the person who owns the software the earlier volumes presuppose. It relies on the stewardship principle of Chapter 4: AI may draft, generate, refactor and, within a mandate, execute, but may not own, and a named developer or team must pass the tests Name, Understand and Revert, with a test oracle independent of the generator. If the number of developers falls while the number of changes rises, those tests keep the remaining people able to answer.

How to read the labels

Three labels are used, as in AI Governance (Chapter 22). Observable means happening now and documented in a source the chapter cites. Expected means supported by a stated trend or by a decided legal instrument. Speculation means plausible but unevidenced. A fourth marking applies in this chapter only: author's projection means that the statement is the author's own judgement, beyond the evidence, and it carries one of the three labels as well. A projection labelled expected claims that a stated trend or instrument supports it; a projection labelled speculation claims only plausibility. The reader can disagree with the author and still use the register.

Two cautions apply. Most of the quantitative evidence about AI and work comes from the United States and from 2023 to 2026, and a Nordic regional authority and a German mutual insurer differ in law, bargaining and the shape of the work. And evidence expires (Chapter 4): every source below was read in November 2026, and the organisations in this book read it again in 2031, so the register records the age of each piece of evidence and every review renews the oldest first. The forecasting record is a further reason for modesty: Tetlock's study of expert judgement is the standard reference for the finding that confident long-range expert predictions often do little better than simple baselines (79, Tetlock, 2005). The register therefore states a trigger, an event that would change a label, rather than a date on which the future is supposed to arrive.

A horizon register for developer roles

A horizon register is a list of trends, not a forecast. Each entry states the trend in one sentence, its label, the developer functions it concerns, the evidence and its age, the trigger that would change the label, the posture the organisation takes (commit, prepare or keep reversible), an owner and a date of review. It separates what the organisation knows from what it believes.

The register of Nordvik Region, as the head of Applications and Integration proposed it to the regional executive committee in the first report required by AIDR-1100, shows the form. It is an artefact for version control, owned by a named person, and short on purpose.

register: HZN-NR-2031-01
title: Horizon register for developer roles, Nordvik Region
owner: Gunilla Roos            # head of Applications and Integration
approved_by: AIDR-1129
reviewed: 2031-05-12
next_review: 2031-11-30
labels: [observable, expected, speculation]
trends:
  - id: T1
    trend: Hiring of early-career staff falls in occupations where AI substitutes for tasks
    label: observable
    functions: [D3 Build, D5 Steward]
    evidence: "Brynjolfsson, Chandar and Chen, ADP payroll data, US, to June 2026; ages 22-25, descriptive"
    evidence_age_months: 59
    scope_limit: "United States; Danish register data to 2024 show no earnings or hours effect (Humlum and Vestergaard)"
    trigger: "Applications and Integration receives fewer than two junior placements in the 2031 intake"
    posture: commit
    owner: ROLE-NR-DEV-01
  - id: T2
    trend: Consultant capacity (22 developers under NR-2025-102) is bought differently as AI tools spread
    label: speculation
    functions: [D3 Build, D4 Prove]
    evidence: "none measured for Europe; the Region's own contract has no clause on AI tools"
    evidence_age_months: 0
    trigger: "Two of three framework suppliers offer fixed-price delivery priced on AI-assisted effort"
    posture: keep_reversible
    owner: Gunilla Roos
  - id: T3
    trend: Software the Region places on the market is treated as a product in law
    label: expected
    functions: [D5 Steward]
    evidence: "Directive (EU) 2024/2853 Art. 4(1), applies after 2026-12-09; Regulation (EU) 2024/2847 Art. 71, applies 2027-12-11"
    trigger: "Regional legal counsel concludes the published e-service components are within scope"
    posture: prepare
    owner: Maria Åkesson
  - id: T4
    trend: One steward answers for many agent-authored changes
    label: speculation
    functions: [D4 Prove, D5 Steward]
    evidence: "Mode 3 limited to the platform team; no coding agent in Applications and Integration"
    trigger: "A mandate MND-NR-DEV-* is proposed that lets an agent open changes without a human reading each"
    posture: keep_reversible
    owner: Maja Lindqvist
thresholds_that_would_change_the_projection: [1, 2, 3, 4, 5]

The identifiers follow the book's families (HZN-* for horizon registers, ROLE-* for role charters, AIDR-1129 for the approving record). Entry T1 is labelled observable because a source documents it, and its scope_limit says where the source does not reach. The evidence_age_months field is the value the review reads first: the evidence is from June 2026, the register from May 2031. Entry T2 is labelled speculation because this book found no measurement of how AI changes the buying of development capacity in Europe, and its posture is reversibility, which is what AI Governance prescribes for that label.

Employment and demand

The numbers answer a narrower question than the one asked. This section sets out what they show and what they do not.

What the data show

Observable: the stock of ICT specialists in the EU has grown. Eurostat reports more than 10 million ICT specialists employed in the EU in 2025, 5.0 per cent of total employment, and growth of 59.4 per cent between 2015 and 2025 against 9.8 per cent for total employment (73, Eurostat, 2026). ICT specialists are a wider group than developers, and the series ends in 2025, only partly in the period of broad AI use.

Expected: official projections still show growth. The United States Bureau of Labor Statistics projects employment of software developers, quality assurance analysts and testers to grow by 10 per cent from 2025 to 2035, or 185,400 jobs from a base of 1,905,400, and lists continued expansion of software development for AI among the drivers (72, U.S. Bureau of Labor Statistics, 2026). The label is expected because a statistical agency's model supports it, and the limit is that it is a projection for one country, made with the information of 2025.

Observable: employment of the youngest workers in AI-exposed occupations is lower than that of their peers. Brynjolfsson, Chandar and Chen use payroll data from ADP covering millions of United States workers through June 2026 and report that employment of workers aged 22 to 25 in AI-exposed occupations is 19 per cent below where it would have been had it kept pace with less-exposed occupations, that experienced workers show no comparable gap, that the divergence has widened since it was first documented in August 2025, and that it works mainly through reduced hiring, not through separations. They find declines concentrated where AI use mainly substitutes for human tasks and flat or rising employment where it mainly complements them. They also state the limits: the findings are descriptive, not causal; the pattern persists when technology firms and computer occupations are excluded, weakens when education is controlled for, and is larger in the ADP sample than in national survey benchmarks. They find no evidence of widespread job displacement across the economy (51, Brynjolfsson et al., 2025). A working paper on résumé and job-posting data for about 65 million workers at more than 280,000 United States firms reports a related pattern: in firms that adopt generative AI, junior employment falls relative to non-adopters through slower hiring while senior employment is largely unchanged, with adoption inferred from job postings (69, Hosseini & Lichtinger, 2025). Chapter 13 treats both studies at length.

Observable: a European register study finds no effect on earnings or hours. Humlum and Vestergaard link surveys on chatbot adoption to Danish administrative records and report precise null effects on earnings and recorded hours, ruling out effects larger than 2 per cent two years after the launch of ChatGPT (53, Humlum & Vestergaard, 2025). It covers occupations exposed to chatbots, not developers specifically, and it describes the first two years.

Observable: adoption is widespread and the experience is mixed. In the 2025 Stack Overflow survey, 84 per cent of respondents were using or planning to use AI tools, 51 per cent of professional developers used them daily, 46 per cent distrusted the accuracy of the output against 33 per cent who trusted it, and 66 per cent named "almost right, but not quite" as their most frequent frustration. The survey has over 49,000 respondents and is self-selected (217, Stack Overflow, 2025). In the EU as a whole, 20.0 per cent of enterprises with ten or more employees used AI technologies in 2025, against 13.5 per cent in 2024 (80, Eurostat, 2025).

What the data do not show

None of these sources measures the number of developers in a European organisation in 2036. The Eurostat series is broad and ends before the period of interest, the United States figure is a model, the payroll studies are American, and the Danish study is not about developers. Exposure studies estimate which tasks a language model could affect, not how many jobs will be lost (116, Eloundou et al., 2024). Acemoglu and Restrepo explain why totals are hard to read: automation displaces workers from tasks and new tasks reinstate labour, so the net effect depends on the balance (94, Acemoglu & Restrepo, 2019).

The European policy target is a different kind of number. Decision (EU) 2022/2481 sets as a target for 2030 that at least 20 million ICT specialists are employed in the Union (22, European Union, 2022). It is an ambition, not a forecast. The author's own arithmetic shows its distance from the trend: 59.4 per cent growth over ten years is about 4.8 per cent a year, and five more years at that rate would lift a figure just above 10 million to about 12.6 million. That extrapolation of one series is labelled speculation; it says only that 20 million by 2030 needs a different rate from the one observed. The entry route is the part of the question that has evidence, the total has argument, and the 2036 composition has neither.

Agent-heavy teams

An agent-heavy team is one in which a large share of the changes is drafted by agents, with developers who frame, review and answer for them. Chapters 8 and 9 treated one team. The future question is scale: how many changes can one steward answer for?

Observable: the capability of agents on software tasks is growing on a measured scale. METR measured the length of software tasks, in the time they take human experts, that frontier models complete with 50 per cent success, and found that this horizon has been doubling roughly every seven months since 2019, with the best model at the time of the paper at about 50 minutes. The authors state that the trend may have accelerated in 2024 and that their projection of month-long tasks within five years holds only if the results generalise to real-world software tasks (78, Kwa et al., 2025). The measurement is observable on that task set. The extrapolation to enterprise work is speculation, and the paper says so.

Observable: productivity evidence is contested, which is why scale is uncertain. A randomised trial with 16 experienced developers on 246 tasks in mature open-source repositories found that they took 19 per cent longer with AI allowed (63, Becker et al., 2025); the same group reported in February 2026 that its follow-up study had too few participants and tasks for a reliable estimate, because developers declined to work without AI or withheld tasks, and changed its design (186, METR, 2026). Field experiments with 4,867 developers at three companies reported a pooled 26.08 per cent increase in completed tasks (standard error 10.3 per cent; code quality not observed) (176, Cui et al., 2024). The 2025 report of the DevOps Research and Assessment (DORA) programme, from about 5,000 technology professionals, found that 90 per cent use AI at work, that adoption now relates positively to delivery throughput and negatively to delivery stability, and that more than 80 per cent believe it raised their productivity, a self-reported belief (42, Harvey & DeBellis, 2025). Telemetry from more than 10,000 developers found that teams with high adoption merged 98 per cent more pull requests while review time rose 91 per cent and pull request size rose 154 per cent, with no significant link to company-level throughput; it reports correlations and comes from a vendor (225, Faros Research, 2025).

Read together, these sources support a conclusion of the book's own. When generation gets cheaper, the constraint moves to what did not: review, the oracle and the owner. Chapter 9 gave the arithmetic for one team: 32 review hours a week at 45 minutes a diff is about 42 diffs a week, and at 60 diffs each gets about 32 minutes. A team can generate 60 diffs without adding a person and cannot review them without adding hours or thinning the review. The size of an agent-heavy team is bounded by the number of changes a steward can pass the three tests for, not by the number an agent can draft.

The stewardship tests at scale

Each test of Chapter 4 has a characteristic failure that more changes make more likely. Name fails when ownership records point to people who have left: 31 per cent of Nordvik's 96 repositories (OWN-NR-2030-00), and 14 of Hansa Mutual's 410 services plus a COBOL estate owned by a department (OWN-HM-2030-00). Understand fails when the approver cannot explain the change; INC-HM-2029-0207 showed it before any AI was involved, when one reviewer, the only other person who knew the module, approved a change that paid 312 claims twice. Revert fails when the rollback was never tested. The independence principle of AI Purple (Chapter 15) is the structural answer: what verifies a change must be independent of what produced it (169, Nordqvist, 2026). In an agent-heavy team that is an oracle written by someone other than the generator, owned by a named person and kept outside the agent's mandate (Chapter 9).

Specification as the main artefact

If agents write more of the code, the artefact that carries the intent moves from the code to what precedes it. Toolkits that put the specification first already exist. A vendor describes one as a workflow of specify, plan, tasks and implement; the source describes the workflow and does not evaluate its outcomes (122, Delimarsky, 2025). That is as far as the evidence reaches: the tools exist, and no measurement in this book shows that they improve results.

Two statements follow, with different labels. Expected, as the author's projection: the specification, the verification plan and the oracle will be reviewed as artefacts in their own right for routine change, because they are what a human can read in the time that is left. Chapter 5 described the specification record and Chapter 9 the verification plan. Speculation: that code becomes a disposable intermediate, regenerated from the specification whenever it is needed. The second statement meets three obstacles. Code in production carries behaviour that no specification states, such as the customisations Linnea Sjöberg is recording as ADRs for the case-management system (Chapter 12). Regeneration without a stable oracle cannot prove that behaviour is preserved. And Revert needs a known good state, which a regenerated artefact lacks until it has been proved.

The consequence for the role is a shift of effort towards D1 Frame and D4 Prove. An ambiguous specification gives the generator room to produce something plausible and wrong, and the person who can write the acceptance criteria that exclude it is a developer with domain knowledge. The scarce skill is the one Chapter 4 named: verification, not generation.

Regulation, offshoring and open source

Three forces bear on the shape of the role from outside the team.

Regulation

Expected: software is becoming a product in law, and the dates are decided. Directive (EU) 2024/2853 defines a product to include software (Article 4(1)) and applies to products placed on the market or put into service after 9 December 2026 (243, European Union, 2024). Regulation (EU) 2024/2847, the Cyber Resilience Act, applies from 11 December 2027, with Article 14 from 11 September 2026 and Chapter IV from 11 June 2026 (Article 71) (242, European Union, 2024). Chapter 24 examines which of the two organisations' software falls within scope. The implication here is architectural: both instruments presuppose a party who can be named for the software, and they make the stewardship record a document that a regulator or a court can ask for. What remains open is who holds the role, not whether somebody must.

Offshoring and the shape of supply

Speculation: AI changes the economics of buying development capacity, and this book found no measurement of the direction for Europe. The two organisations buy capacity: about 22 consultant developers at Nordvik Region under framework agreement NR-2025-102, and about 190 external developers at Hansa Mutual, 110 of them from the nearshore partner Wiślana Software. The Region's framework agreement had no clause on AI tools, Hansa Mutual's had at most partial ones, and the Region's incident INC-NR-2030-0071 began with a consultant using an unapproved tool. Two arguments point in opposite directions: that AI narrows the cost difference between locations, so that less work is sent away, and that a supplier who uses AI well can offer lower prices, so that more is sent. The author has no evidence for either, and a register that records the trigger (suppliers pricing delivery on AI-assisted effort) is more useful than a view. What an organisation can decide now is that the contract names the tools, the mandate and the review that applies to supplier code (Chapter 18 for the public sector).

Open source

Speculation: the maintainers of open-source components are a bottleneck that AI can strain or relieve. The Cyber Resilience Act's recitals distinguish products that are not monetised from commercial supply, and describe open-source software stewards as legal persons who provide sustained support for the development of products intended for commercial activities (recitals 18 and 19) (242, European Union, 2024). Nordvik Region has published the code of its e-service components under an open licence since 2027, so whether it is a steward is a real question for it. The effect of AI on maintainers, through more contributions to review or better tools to review them, is not measured in any source this book verified. Chapter 26 treats licensing, provenance and sovereignty.

Education and the route to senior

Observable: the route by which people become senior developers is the part of the future most at risk. The studies above converge on the entry level, and an experiment on learning points the same way. Shen and Tamkin had developers learn a new asynchronous programming library with or without AI assistance, and reported that AI use weakened conceptual understanding, code reading and debugging, with no significant efficiency gain on average. Of six interaction patterns, three preserved learning even with AI in use, and participants who delegated the coding entirely learned less (67, Shen & Tamkin, 2026). It is a preprint with a specific task. In another field, an observational study in four Polish centres found that endoscopists' adenoma detection rate fell from 28.4 to 22.4 per cent when they worked without AI after a period of using it, a retrospective, observational result among 19 experienced endoscopists, which shows an association and is a reminder that skill may decay (65, Budzyń et al., 2025).

The implication is the book's own conclusion from Chapter 13: the senior who can verify an agent's change in 2036 is the junior being trained in 2031. The apprenticeship plans APR-NR-2030-01 and APR-HM-2030-01 exist for that reason, with deliberate periods without the tool. Whether university curricula follow, this book can say nothing with evidence; it verified no curriculum document and records the question as open.

The debate

The question "fewer, more or different?" is staged in four steps. The positions are stated at their strongest and the labels are applied after the evidence, not before it.

The case for concern

The case for concern says that fewer developers will be needed, and that even if the total holds, the structure that produces experienced developers will not. It rests on four arguments.

The first is the direction of the entry-level data: a gap of 19 per cent for workers aged 22 to 25 that has widened for a year and operates through hiring (51, Brynjolfsson et al., 2025), and a second dataset showing the same for firms that adopt generative AI (69, Hosseini & Lichtinger, 2025). The first people to feel a change in a labour market are the people who would have been hired next.

The second is the capability trend. If the length of the tasks agents complete doubles about every seven months, part of the work that fills a junior's first years will be done by an agent before the junior has learned it (78, Kwa et al., 2025).

The third is learning. If unstructured use of assistants weakens the understanding that verification needs (67, Shen & Tamkin, 2026), a generation of developers will have produced much and understood little, and the organisation will find out when a system such as the COBOL platform at Hansa Mutual loses its last person who can explain it.

The fourth has a local edge. A claim of "a third faster" (Nordvik) or "42 per cent AI-assisted" (Hansa) is easily turned into a head-count argument by a reader who does not see the evidence age. The concern is that numbers will be used to cut posts before they are proved, and that the cut will fall on the roles that look least productive: juniors, reviewers and the stewards of old systems.

The case for calm

The case for calm says that total demand is not falling, that the data on young workers are not yet causal, and that the work moves to places where people are needed more.

Employment of ICT specialists in the EU grew by 59.4 per cent in ten years (73, Eurostat, 2026), a United States agency projects 10 per cent growth to 2035 for the developer occupation (72, U.S. Bureau of Labor Statistics, 2026), and the European register study finds no effect above 2 per cent on earnings or hours (53, Humlum & Vestergaard, 2025). The authors of the ADP study find no widespread displacement and call their findings descriptive. The productivity measurements are mixed enough (the 19 per cent slowdown in the METR trial, the stability penalty in the DORA 2025 report, the 91 per cent rise in review time in the Faros telemetry) that rapid, general replacement is not what they describe (63, Becker et al., 2025); (42, Harvey & DeBellis, 2025); (225, Faros Research, 2025).

The calm position adds an argument, not a measurement: if software becomes cheaper to produce, more of it will be demanded. The framework of Acemoglu and Restrepo says the result depends on whether new tasks reinstate labour (94, Acemoglu & Restrepo, 2019), and new law is creating such tasks: product liability and cybersecurity duties for software that people must hold (242, European Union, 2024); (243, European Union, 2024). On this view the steward of software over time (Chapters 4 and 12) is a role that regulation creates.

Where the positions meet

Both sides accept more than the debate suggests. The entry-level data are descriptive, American and recent, and not yet shown to be causal. Total employment of developers has not fallen in the data available. The productivity measurements disagree, partly about method: a sample of 16 developers, a vendor's telemetry, a survey of self-reported benefit. Verification capacity limits how much generated change an organisation can safely absorb. And how people become senior is a design question, not a fact of nature: the apprenticeship plan, the share of work done without the tool and the time for mentoring are decisions.

The difference lies in the weight given to the entry level. The concerned side treats it as the earliest signal of a larger change, the calm side as a sector adjusting to a hiring cycle that predated the technology. Neither can be refuted with today's data. The register can state what would settle it: employment of ICT specialists by age band over several years, the two organisations' intake figures, and outcome data on how fast juniors trained with and without the tool reach independent review.

What can be done

The actions follow from the common ground and do not depend on who is right.

  • Developers: keep a record of what you can verify without the tool, and ask for a period of unassisted work in the first year. Name the components you can explain, and name the deputy.
  • Tech leads: write the stewardship record for every component your team changes with an agent (owner, deputy, oracle, revert test), and refuse a mandate whose oracle the agent can edit (Chapters 8, 9 and 12).
  • Engineering managers and heads of development: hold the junior intake. Treat an apprenticeship plan like APR-HM-2030-01 as an investment with a review date, and do not cite an adoption figure without its method and evidence age (Chapter 20).
  • Leaders: require a horizon register with triggers before a head-count decision that cites AI, and let the trigger, not the forecast, decide.
  • Works councils and unions: ask for the register and the intake data in the negotiation, and for telemetry that is reported by team and never by named developer (Chapter 22).
  • Educators and apprenticeship schemes: ask employers for the tasks juniors actually do in their first year, and teach the verification of generated change as a skill in its own right.

Verdict

The verdict is stated by label.

Observable: hiring of the youngest workers in AI-exposed occupations has fallen relative to their peers in the United States, and the pressure is on the entry route. Adoption is broad, trust is limited, and the productivity evidence is contested. Regulation that presupposes a named party for software is decided and has dates.

Expected: the total number of people in software roles in the EU in 2036 will not be lower than in 2025 on the evidence of a decade of growth and an official projection, but the work will be weighted more to framing, verification and stewardship (D1, D4 and D5) than to typing code. That expectation carries a wide margin, and the register's triggers are there to find out early if it is wrong.

Speculation: a figure for the size of a development organisation in 2036, whether specifications replace code as the main artefact, whether offshoring grows or shrinks, and the effect on open-source maintainers.

The best single answer to the title is therefore different, with a qualification. Whether there are fewer or more is not known and may differ between sectors and sizes of organisation. What can be influenced is what the organisation does about the entry route and the stewardship record. Those two choices, the deliberate apprenticeship and the named steward, are the part of the future that Nordvik Region and Hansa Mutual decide for themselves.

The author's projections

The five projections below are the author's judgement. Each carries a label, and each is paired with a threshold, an observation that would make the author change it. They are the book's one set of projections for the role, and Chapter 33 draws on them.

P1 (expected): the work moves towards D1, D4 and D5, and total employment in software roles in the EU holds. The reasoning: a decade of growth, an official projection and new legal duties that need people to hold them. Threshold 1: Eurostat's series for ICT specialists falls in two consecutive years, or a statistical agency revises its projection for developers to a decline.

P2 (expected): the entry route survives where organisations build it deliberately, and thins where they do not. The reasoning: the entry-level studies and the learning study point to a risk that the organisation can reduce by design. Threshold 2: a multi-year outcome study shows that juniors trained mostly with the tool reach independent review as fast as juniors trained with deliberate unassisted periods. That would remove the case for the design choice.

P3 (speculation): some units will run with a small number of named stewards answering for a large number of agent-authored changes, in well-covered services, within the Level 3 Bounded class. The reasoning: the measured growth of agent capability and the existing class at Hansa Mutual (patch-level dependency updates under MND-HM-DEV-01). Threshold 3: an organisation publishes twelve months of data on such a unit, with change failure, rework and incident rates compared with a conventional team. Until then, the ratio is a hypothesis.

P4 (speculation): the specification, the verification plan and the oracle become the primary reviewed artefacts for routine change, and code is read mainly at boundaries and in security-critical and safety-critical paths. The reasoning: review time is the constraint, and humans read what they can in the time that is left. Threshold 4: evidence that review of specifications finds fewer defects per hour than review of code, or that the oracle cannot be made independent of the generator in practice.

P5 (expected): the named steward persists, because the law names a party and the stewardship tests describe what that party must be able to do. The reasoning: Directive (EU) 2024/2853 and Regulation (EU) 2024/2847 apply from dates already decided, and the stewardship record is the evidence that a manufacturer or a defendant would need. Threshold 5: an amendment or a ruling that lets an AI system hold the duty, or that excuses a party from it because an agent produced the change.

The Level 4 prohibitions are not a projection. They are the ceiling this book recommends, and no threshold above would lift them without a change in what can be verified and stopped from outside the system.

Practical guide: keep a horizon register

Purpose. Replace the forecast with labelled trends, triggers and owners that can be wrong in a reviewable way.

Roles. The head of development or a tech lead owns the register; the architect reviews the evidence; the engineering manager supplies the organisation's own figures; the works-council or union representative receives it; the data protection officer checks that nothing refers to a named developer; legal counsel reviews entries that cite law.

Inputs. The organisation's intake, ownership and incident records; the adoption and value records (AVR-*) with their evidence age; the sources cited here, read again.

Steps. 1. Write one sentence per trend, with its label, the developer functions it concerns and the evidence with its age in months. 2. State the scope limit: country, period, occupation. 3. Write the trigger as an event observable in the organisation's own data. 4. Choose the posture: commit for observable, prepare for expected, keep reversible for speculation. 5. Name the owner and a review date no more than six months ahead; at each review renew the oldest evidence first.

Result. A HZN-* register in version control, approved by an AIDR and sent to the representative body.

Across the degrees of delegation

The outlook assumes the ladder and its ceiling. The table shows, for each level, what the projections in this chapter assume about it and how they are labelled.

Level What the outlook assumes Label Who answers
Level 0 Advisory Remains the right level for specify, design, review and migrate wherever there is no independent oracle (Nordvik's inherited case systems; the COBOL estate) Expected The developer who asked
Level 1 Assisted Suggestions that a developer accepts; the level at which most of the pressure on the entry route arises Observable The developer, by Name and Understand
Level 2 Supervised Agents open changes that a named developer reviews; review hours set the limit on how many Observable at Hansa Mutual, speculation at scale The reviewer and the steward
Level 3 Bounded A small number of classes (patch-level dependency updates) merged by the pipeline under a standing approval; P3 concerns widening this Observable for one class, speculation beyond The approver of the class, the owner of the mandate
Level 4 Autonomous Not used for a change to production without a gate the change cannot alter, for security-critical or safety-critical code 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 Not a projection: a ceiling Nobody may delegate it

Nordvik Region and Hansa Mutual

Nordvik Region. The Region has about 25 people who write code as their main work (18 developers and seven platform engineers), two juniors and about 22 consultants. Its horizon register HZN-NR-2031-01 (AIDR-1129) is the instrument of the first report to the regional executive committee that AIDR-1100 required. The trend of most consequence is the entry route (T1): with two juniors, one missed placement is a large proportion, and the case for keeping APR-NR-2030-01 rests on the argument of this chapter, not on a measured gain. Its legal entry (T3) is the one with a date: the published e-service components may fall within the Cyber Resilience Act as an open-source steward, and regional legal counsel Maria Åkesson holds that question. The Region has no Mode 5 agent and agent use is limited to the platform team, so on agent-heavy teams (T4) it keeps the option reversible and watches the platform team's records.

Hansa Mutual. The group has about 290 developers, about 190 external developers and 62 delivery teams, so the question of scale arises here first. Its register HZN-HM-2031-01 (AIDR-1179) is shown below. Its distinctive entry is the age of the COBOL maintainers: five of the twelve people who maintain the 6.5 million lines of the policy administration platform are within eight years of retirement, so the horizon for the legacy estate is a matter of the organisation's own data. The legacy-code explainer HM-DEV-003 may help a successor read the code; it stays at Level 0 Advisory and is not an oracle for any change it explains. The group's coding agents never merge to the protected branch, and the one Level 3 Bounded class (patch-level dependency updates under MND-HM-DEV-01) is its evidence base for P3.

register: HZN-HM-2031-01
title: Horizon register for developer roles, Hansa Mutual
owner: Dr. Philipp Reinhardt   # head of Group Application Development
approved_by: AIDR-1179
reviewed: 2031-04-22
next_review: 2031-10-31
labels: [observable, expected, speculation]
trends:
  - id: T1
    trend: Five of twelve COBOL and PL/I maintainers reach retirement age within eight years
    label: observable
    functions: [D5 Steward]
    evidence: "Group Application Development staffing review, 2030-09; estate listed by named owner and deputy (AIDR-1162)"
    evidence_age_months: 7
    trigger: "A second maintainer gives notice before a deputy is recorded for the settlement module"
    posture: commit
    owner: ROLE-HM-DEV-01
  - id: T2
    trend: Agent-authored changes grow faster than review hours
    label: speculation
    functions: [D4 Prove, D5 Steward]
    evidence: "Mode 3 agents used by about 120 engineers; no coding agent merges alone"
    trigger: "Median review time per pull request in a team falls below 20 minutes for two quarters"
    posture: keep_reversible
    owner: ROLE-HM-TCL-01
  - id: T3
    trend: The mobile claims app and broker plug-in are products with digital elements
    label: expected
    functions: [D5 Steward]
    evidence: "Regulation (EU) 2024/2847 Art. 71, applies 2027-12-11; scope for Hansa assessed in Chapter 24"
    trigger: "General counsel concludes that the group is a manufacturer in the sense of the Regulation"
    posture: prepare
    owner: Ulf Zimmermann
thresholds_that_would_change_the_projection: [1, 3, 5]

The two registers differ where the organisations differ: Nordvik's concern is the number of juniors it can afford to place, Hansa's is the number of maintainers who will be gone. Both reach the same instrument, a labelled trend with a trigger in the organisation's own data, which is the practice the chapter recommends.

Summary

This chapter asked whether there will be fewer, more or different developers, and it concerned all five developer functions. D1 Frame and D4 Prove gain weight if specifications and oracles become the artefacts people review; D3 Build is where the share of human work is least certain; D2 Design sets the constraints and ceilings that bound agent-heavy teams; and D5 Steward is the function that regulation and the stewardship tests make most durable.

The evidence supports a limited set of statements. Observable: employment of the youngest workers in AI-exposed occupations is lower than that of their peers in the United States, through reduced hiring; adoption by developers is broad, trust limited and productivity evidence contested; the Cyber Resilience Act and the Product Liability Directive are decided and dated. Expected: total employment in software roles in the EU holds to 2036, with a shift in the content of the work. Speculation: the size of a development organisation in 2036, specifications replacing code, the direction of offshoring and the effect on open-source maintainers. The best single answer to the title is different, with the entry route and the named steward as the two things an organisation can influence.

Each of the author's five projections has a threshold that would change it, and the horizon register is the instrument for finding out early. A reader can start with one practice: write down the four or five trends that matter to the organisation, label each, give it a trigger in the organisation's own data and put a date on the review.

Chapter 30 turns from outlook to experience: case studies and anti-patterns from the cases the book has built, including the ones in which a claim was ahead of its evidence.

Sources

  1. Acemoglu, D. & Restrepo, P. (2019). Automation and New Tasks: How Technology Displaces and Reinstates Labor. Journal of Economic Perspectives 33(2), 3-30. (94, Acemoglu & Restrepo, 2019)
  2. Becker, J., Rush, N., Barnes, E. & 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)
  3. Brynjolfsson, E., Chandar, B. & Chen, R. (2025, revised 12 August 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)
  4. Budzyń, K., Romańczyk, M. et al. (2025). Endoscopist deskilling risk after exposure to artificial intelligence in colonoscopy. The Lancet Gastroenterology & Hepatology 10, 896-903. (65, Budzyń et al., 2025)
  5. Cui, Z. (K.), Demirer, M., Jaffe, S., Musolff, L., Peng, S. & 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)
  6. Delimarsky, D. (2025). Spec-driven development with AI: Get started with a new open source toolkit. GitHub Blog, 2 September 2025. (122, Delimarsky, 2025)
  7. Directive (EU) 2024/2853 of 23 October 2024 on liability for defective products. Official Journal of the European Union, 18 November 2024. (243, European Union, 2024)
  8. Eloundou, T., Manning, S., Mishkin, P. & Rock, D. (2024). GPTs are GPTs: Labor market impact potential of LLMs. Science 384(6702), 1306-1308. (116, Eloundou et al., 2024)
  9. Eurostat (2025). 20% of EU enterprises use AI technologies. European Commission, 11 December 2025. (80, Eurostat, 2025)
  10. Eurostat (2026). ICT specialists in employment. Statistics Explained, European Commission. (73, Eurostat, 2026)
  11. European Parliament and Council of the European Union (2022). Decision (EU) 2022/2481 establishing the Digital Decade Policy Programme 2030, Article 4(1). (22, European Union, 2022)
  12. Faros Research (2025). The AI Productivity Paradox Report 2025. Faros AI, 23 July 2025. (225, Faros Research, 2025)
  13. Harvey, N. & DeBellis, D. (2025). Announcing the 2025 DORA report: State of AI-assisted Software Development. Google Cloud Blog, 23 September 2025. (42, Harvey & DeBellis, 2025)
  14. Hosseini, S. M. & Lichtinger, G. (2025). Generative AI as Seniority-Biased Technological Change: Evidence from U.S. Résumé and Job Posting Data. SSRN 5425555. (69, Hosseini & Lichtinger, 2025)
  15. Humlum, A. & Vestergaard, E. (2025). Still Waters, Rapid Currents: Early Labor Market Transformation under Generative AI. NBER Working Paper 33777. (53, Humlum & Vestergaard, 2025)
  16. Kwa, T., West, B., Becker, J. et al. (2025). Measuring AI Ability to Complete Long Tasks. METR; arXiv:2503.14499. (78, Kwa et al., 2025)
  17. METR (2026). We are Changing our Developer Productivity Experiment Design. METR blog, 24 February 2026. (186, METR, 2026)
  18. Nordqvist, G. (2026). AI Governance. The Architecture as Code Series, Book 2. (162, Nordqvist, 2026)
  19. Nordqvist, G. (2026). AI Threat. The Architecture as Code Series, Book 5. (165, Nordqvist, 2026)
  20. Nordqvist, G. (2026). AI Purple. The Architecture as Code Series, Book 9. (169, Nordqvist, 2026)
  21. Nordqvist, G. (2026). AI Operations. The Architecture as Code Series, Book 10. (170, Nordqvist, 2026)
  22. Nordqvist, G. (2026). AI Leader. The Architecture as Code Series, Book 11. (174, Nordqvist, 2026)
  23. Regulation (EU) 2024/2847 (Cyber Resilience Act) of 23 October 2024. Official Journal of the European Union, 20 November 2024. (242, European Union, 2024)
  24. Shen, J. H. & Tamkin, A. (2026). How AI Impacts Skill Formation. arXiv:2601.20245. (67, Shen & Tamkin, 2026)
  25. Stack Overflow (2025). 2025 Stack Overflow Developer Survey. (217, Stack Overflow, 2025)
  26. Tetlock, P. E. (2005). Expert Political Judgment: How Good Is It? How Can We Know? Princeton University Press. (79, Tetlock, 2005)
  27. U.S. Bureau of Labor Statistics (2026). Occupational Outlook Handbook: Software Developers, Quality Assurance Analysts, and Testers. (72, U.S. Bureau of Labor Statistics, 2026)