The Senior Developer, Staff and Principal Engineer

The senior developer is the person a team turns to when the specification is ambiguous, the change is risky or nobody remembers why the system does what it does. When AI generates the first draft of most changes, three things that the team has relied on the senior for become more important and harder at once. Review becomes the place where a change is first understood by anyone but its generator. Design decisions become the main constraint on what may be generated. Knowledge of why the system is as it is becomes the one input that no assistant can retrieve from the repository. This chapter concerns D2 Design, D4 Prove and D5 Steward as they fall on the person with the most context: what the senior's work consists of, why review capacity becomes the bottleneck of AI-assisted delivery, how a role charter protects professional judgement without making the senior a veto, how seniors are made when the entry-level work that made them is done first by machines, and what changes for staff and principal engineers whose scope spans teams.

A senior developer is an experienced individual contributor whom the organisation trusts with ambiguous work, review of risky changes and the mentoring of others. Staff and principal engineer name roles whose scope extends beyond one team, to design, standards and technical direction across several. Organisations draw these lines differently. The tech lead and the engineering manager are the subject of Chapter 15, and the junior developer of Chapter 13.

The senior's leverage: decisions that bound what is generated, review that is budgeted and protected, and context held by named people, with a pipeline that makes the next seniors

Figure 14.1: The senior's leverage. Decisions bound what is generated, review is limited by a recorded budget and protected by the role charter, context is held by named people, and the pipeline of seniors keeps the whole arrangement supplied.

The senior's work

Four jobs make up the senior's work, and they are worth separating because AI changes each differently. The senior reviews, mentors, takes technical decisions and keeps context. None of the four is mainly typing.

The reviewer

Michael Fagan's account of design and code inspections, published in 1976, described review as a defined process with roles, stages and data that the organisation used to improve the process itself (104, Fagan, 1976). Modern review is lighter. Alberto Bacchelli and Christian Bird observed, interviewed and surveyed developers and managers in Microsoft teams and classified hundreds of review comments. They found that finding defects remained the main stated motivation, but that review delivered less on it than expected and more on knowledge transfer, team awareness and the discovery of alternative solutions. Understanding the change was the central activity of the reviewer, and most of the strategies reviewers used for it were not supported by their tools (190, Bacchelli & Bird, 2013).

That finding carries a consequence for generated code, and the consequence is the chapter's own conclusion. If the central work of review is understanding the change, then a change whose author cannot explain it moves the whole burden of understanding to the reviewer. The author may have read the diff and accepted it, but reading is not the Understand test of the stewardship principle (Chapter 4), which asks that the owner can explain what the change does and why, and can reconstruct it without the tool that generated it. Where the author does not pass that test, the senior reviewer is the first and perhaps the only person who forms a view of the change. This is why the delegation profiles of both organisations keep review at the lowest rungs of the ladder (see the table in the section on degrees of delegation below).

The mentor

The mentor's job is to ask for the reasoning that the change does not show, in review comments and pairing. A preprint by Judy Hanwen Shen and Alex Tamkin on skill formation reported that developers who learned a new asynchronous programming library with AI assistance showed impaired conceptual understanding, code reading and debugging, and that the researchers identified six patterns of interaction, three of which involved cognitive engagement and preserved learning even with AI help. Developers who handed all the coding to the assistant gained some productivity and learned less (67, Shen & Tamkin, 2026). The study is a preprint that has not been peer reviewed, it concerns one library and one task, and the participants were learners; it does not show what happens to experienced developers over years. It does suggest what a mentor can look for, namely whether the junior engaged with the generated code or only accepted it, and Chapter 13 develops the apprenticeship that follows from it.

The technical decision-maker

Design is the function in which the senior's judgement has the longest reach, because a decision about an interface, a data boundary or a dependency constrains every later change, including the generated ones. The Architecture Decision Record (ADR) is the series' artefact for such decisions (Architecture as Code (Chapter 4)) (161, Nordqvist, 2025). Frederick Brooks argued that conceptual integrity is the most important consideration in system design, and that it comes from a design that reflects one coherent set of ideas (215, Brooks, 1995). Generation puts that argument under new strain. When three alternative implementations cost an afternoon instead of a fortnight, a team can produce locally reasonable solutions faster than anyone can reconcile them. The scarce activity moves from producing alternatives to choosing among them and to stating the constraints within which anything may be generated. In the language of this book, D2 Design becomes the function that bounds D3 Build, and the senior is usually the person who writes the bounds.

The keeper of context

Peter Naur argued in 1985 that a program is not its text. Programming, in his account, is the building of a theory held by the programmers: why the program is shaped as it is, how it relates to the world it serves and how it can be changed without breaking what it was built to do. The text and the documentation are products of the theory and cannot fully carry it, so that a program whose programmers have left can be revived only by a new team rebuilding the theory (181, Naur, 1985). The argument predates generative models and is an argument, not a measurement. It describes well what the senior on Nordvik Region's case platform holds after fourteen years of customisation, and what twelve COBOL and PL/I developers at Hansa Mutual hold about 6.5 million lines.

An assistant with retrieval over the repository finds text. It does not find reasons that were never written, and it cannot tell a deliberate oddity from an accident. The conclusion for the organisation is the book's own: the senior's context is an asset with a single point of failure, and it needs the same treatment as any other, which is a named deputy, written decisions where they can be written, and time for the work by which theory passes between people (pairing, review, incident work). Chapter 12 develops the code-ownership record (OWN-*) that makes the dependency visible.

What generation changes in the four jobs

Job What AI makes cheaper What AI does not make cheaper Risk if unmanaged
Reviewer Producing the change to be reviewed; drafting review comments Understanding a change whose author cannot explain it; judging fit with the system Review volume exceeds review capacity; approval becomes a formality
Mentor Explaining syntax and library use on demand Showing a junior what a good change looks like and why; noticing disengagement Juniors accept without engaging; seniors have no time to teach
Decision-maker Listing options; drafting an ADR Choosing under constraints that are not in the text; accepting the consequence Local solutions diverge; decisions are made by default in generated code
Keeper of context Summarising code; searching the repository The reasons that were never written; knowing what must not be changed Context sits in few heads; the keepers leave or are overloaded

What the evidence says about experienced developers

Two bodies of evidence need to be read together, and neither supports a simple claim about seniors. Joel Becker and colleagues ran a randomised trial with 16 experienced open-source developers, who averaged about five years of involvement in mature projects of their own, on 246 tasks assigned at random to allow or disallow early-2025 AI tools. Allowing AI increased completion time by 19 per cent. Before the tasks the developers predicted AI would cut their time by 24 per cent, and afterwards they estimated that it had cut it by 20 per cent (63, Becker et al., 2025). The sample is small, the tools were those of early 2025 and the setting is the developers' own long-lived repositories. In three field experiments at Microsoft, Accenture and a Fortune 100 company with 4,867 developers in all, Zheyuan Cui and colleagues reported a 26.08 per cent increase in completed tasks among those given an AI coding assistant, in the abstract of the working paper later published in Management Science; the authors describe each experiment as noisy (176, Cui et al., 2024). The measure is completed tasks, in other organisations, and not the quality of what was completed.

Both results are observable, and they do not contradict each other, because they measure different things in different settings. The conclusion for a senior-developer role is that nobody can assume the effect on seniors working in their own systems, and the Becker study shows that the developers' own impression of the effect was not a reliable guide. An organisation that wants to know what AI does to the work of its seniors measures it in its own repositories, with the evidence age that Chapter 20 attaches to every adoption claim, and does not rely on the seniors' self-report.

Leverage and the review bottleneck

Leverage, in this chapter, means the output of a team per unit of the senior's attention. A good design note, review checklist or boundary multiplies the work of everyone who follows it, and now also bounds what agents generate. The new drain is that generated changes arrive for review at a rate set by the generator, not the reviewer.

Where the bottleneck forms

In a team that generates more changes than before, the rate-limiting step is the one that cannot be generated away. Review is that step, because the reviewer's understanding of a change is the output that review exists to produce, and an assistant's comment does not substitute for it. The DevOps Research and Assessment (DORA) programme summarised its 2024 report by saying that, as AI adoption increased, it was accompanied by an estimated decrease in delivery throughput of 1.5 per cent and an estimated reduction in delivery stability of 7.2 per cent (221, Google Cloud, 2024). The report is a survey of practitioners, the figures are associations and not demonstrated effects, and the announcement does not state the survey size. It is observable that the survey associated higher AI adoption with lower delivery throughput and stability, not higher. The chapter takes the finding as a reason to look at review capacity, not as a measure of it.

Four mechanisms make the bottleneck worse than a simple count of pull requests suggests.

  1. Anchoring on the proposal. A reviewer who reads the generated change first is judging an answer, not forming one. A systematic review of automation bias found that users accepted incorrect advice from decision support that they might otherwise have rejected (43, Goddard et al., 2012), and an integrative review found that complacency and automation bias occur in naive and expert participants alike and are not prevented by training or instruction (57, Parasuraman & Manzey, 2010). An experiment on AI-assisted decisions found that designs that make the person think before the advice is shown (cognitive forcing functions) reduced overreliance (44, Buçinca et al., 2021).
  2. Vigilance on a mostly correct stream. Lisanne Bainbridge observed in 1983 that people asked to monitor a reliable automatic process are poorly suited to catching its rare failures (56, Bainbridge, 1983). A stream of generated changes that are mostly right is such a process, and a fatigued senior approves it faster the more often it has been right.
  3. Confidence in the author. In a study of security-relevant programming tasks, participants with an AI assistant wrote less secure code than those without, and were more likely to believe that their code was secure (34, Perry et al., 2023). An author who trusts the tool submits less examined work, and a reviewer who knows that the author used the tool has to decide how much of the examination to repeat.
  4. A second model is not a second opinion. Elliot Kim and colleagues evaluated over 350 language models and found substantial correlation in their errors, which were highly correlated even across architectures and providers for larger and more accurate models (35, Kim et al., 2025). The consequence is the independence principle of AI Purple (Chapter 15), that a loop closed by machines alone verifies nothing new (169, Nordqvist, 2026). An AI review comment can add a check; it cannot count as the human review. Both delegation profiles say so in terms (see below).

A further risk is internal to the role. A senior who spends the week reviewing and little time building may lose the working theory that Naur described, because the theory is maintained by changing the system. No study cited in this book measures this for developers; it is a risk that follows from Naur's argument and from skill-decay evidence in other domains, and the organisation should watch for it.

Controlling the bottleneck

The response is a set of design choices, not a call for seniors to work harder. Five control the volume, the quality and the fairness of review.

  1. Limit the inflow at the source. The mandate of a coding agent (Chapter 8) caps the number of open pull requests per human reviewer. When the budget is spent, the queue stops growing; agents wait.
  2. Make the change reviewable. The author states what the change is for, which parts were generated and by which tool at which mode, and what evidence was run. The specification record (SPC-*), the agent run record (RUN-*) and the provenance record (PRV-*) give the reviewer that statement without a conversation (Chapters 5, 8 and 10).
  3. Tier the review by consequence. Not every change needs a senior. The tiers follow the Level 4 prohibitions of the ladder: code in a security-critical or safety-critical path, a change to pipeline gates, a database migration with production data, and anything that changes the agent's own mandate, permissions or test oracle always reach a named developer who is competent in that area. The remainder are reviewed by peers, with the senior sampling.
  4. Put the reviewer's judgement first for a sample. For a share of changes, the reviewer writes down what they expect to see, or what they think the risk is, before reading any assistant comment, and compares afterwards. Daniel Kahneman, Olivier Sibony and Cass Sunstein recommend the same ordering for human judgement, with independent assessments made before they are discussed (88, Kahneman et al., 2021).
  5. Seed errors and measure review at team level. A known defect planted in a sample of changes measures how much review catches, a practice that The Transformed Security Architect (Chapter 14) described for the architect (166, Nordqvist, 2026). The measure belongs to the review process and its owner. Using it to rank named developers turns a quality measure into the algorithmic management that AI Boss (Chapter 8) described, in which a score becomes an argument in a pay or discipline conversation (167, Nordqvist, 2026).

The lever that makes the other five binding is the review budget: a named share of the senior's working time for review, changed only by a recorded decision. The budget makes the trade-off visible. If generation raises the number of changes needing senior review beyond what the budget covers, the organisation either raises the budget, which takes time from design and mentoring, or lowers the inflow, or accepts a longer queue. What it must not do is let the review quietly become shallower to absorb the volume.

Practical guide: Writing a senior developer charter with a professional-judgement clause and a review budget

Purpose. Give the senior role a written mandate, a budget for review and mentoring, and a protection for its judgement, in a role charter under version control.

Roles. The engineering manager or head of development owns the charter, and the senior developers it describes write the first draft with the owner. The tech lead, quality engineer and architect are consulted on review tiers, HR on appraisal and the data protection officer on records and metrics. Employee representatives are consulted or, where the law requires, negotiate or co-decide before adoption (see below).

Inputs. The job description; the delegation profile (DLG-*); the code-ownership records; the last three months of pull requests by tier, with the time reviewers spent (from the review records, never from keystroke or screen monitoring); the list of security-critical paths; the appraisal criteria; the agent mandates in force.

Steps.

  1. List the senior's jobs as the four above and estimate the hours each takes in a normal week from the review records and the team's own account.
  2. Count the review demand. Multiply the weekly changes that need senior review (by tier) by the average review time, and compare it with the seniors available. Do the arithmetic with the agents' expected inflow included.
  3. Set the review budget as a share of working time, and set the mentoring share beside it. Record the share, the date and who may change it.
  4. Write the decision rights: what the senior decides alone (for example the design of a change within the team's boundaries), what needs a second senior or the architect, and what goes to the engineering manager.
  5. Write the professional-judgement clause (next section), with its limits.
  6. Check targets and appraisal: remove any acceptance-rate, generated-line or usage target for a named person, and confirm that review metrics are reported by team.
  7. Consult, negotiate where required, adopt and record the decision as an AI Decision Record with a review date.
  8. Test at the first review: pick three holds, three recorded disagreements and three declined ownerships, and check that each was recorded, answered within the stated time and free of consequence for the senior.

Artefact. The role charter with its professional-judgement clause and review budget in version control, the AI Decision Record that adopted it and a short record of the first test.

Professional judgement

Professional judgement, for a senior developer, is the capacity to decide in a case the rules do not settle what the change, the design or the release requires, and to answer for it. AI Leader (Chapter 19) concluded for specialists in general that review should start from the reviewer's first judgement, be disclosed and budgeted, and never be delegated to a second model alone, and that a professional-judgement protection clause in the role charter gives the specialist the right to override and to record disagreement (174, Nordqvist, 2026). This chapter applies that conclusion to the developer and adds what is specific to software.

Why the charter and not a policy

A tool whose output is on every pull request, usually right and faster to accept than to contest creates a standing incentive to agree. It operates through the wish to clear the queue, through delivery targets and through the fear of holding a release for a concern that came to nothing. A "request changes" button for a person measured on throughput is a right in name.

The law draws the same distinction where it places duties on people. The AI Act requires that a high-risk AI system be designed and developed so that natural persons can effectively oversee it (Article 14(1)), and lists among the capacities that oversight measures must give those persons the ability to remain aware of automation bias (Article 14(4)(b)), to disregard, override or reverse the output (Article 14(4)(d)) and to interrupt the system through a stop procedure (Article 14(4)(e)). It requires deployers to assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support (Article 26(2)) (1, European Union, 2024). A code review is not the human oversight those articles regulate, and the senior developer is usually not the person assigned under Article 26(2). The design lesson applies all the same, and for the senior it applies twice. First, authority must exist in the organisation and not only in an interface. Second, when the organisation is a provider of a high-risk system, as Hansa Mutual is for its underwriting-support model for life and health products, the senior's design judgement is where Article 14(1) is met or missed. These are architectural implications, not legal advice.

The clause and its limits

A developer-specific clause has six parts, and the role charter in this chapter carries them as fields.

  • The right to hold. The senior may hold a change from merge, in a defined set of classes, when they cannot form a view of it, without prior approval. The hold is recorded with a reason, and it is time-boxed: a second senior, the architect or the tech lead answers within a stated number of working days.
  • The right to the explanation. The senior may require that the author explain a generated change without the tool, and may decline to approve until the author can. This is the Understand test applied at the gate.
  • The right to decline ownership. The senior is not the default owner of every change they have reviewed. Ownership is assigned in the code-ownership record, with the owner's agreement, a named deputy and a path to revert. A senior may decline to be named owner of a component they cannot understand or revert, and the decline is recorded and read by the engineering manager.
  • The right to record dissent. When the senior's concern is overruled, the concern and the reasons are recorded in the ADR or review record, and the decision-maker answers it in writing.
  • No use target in appraisal. No acceptance-rate target, generated-line target or tool-usage target is set for a named person, and review-derived measures are reported by team.
  • The right to unassisted work. A defined share of review is done without the assistant, as practice and as a check on the senior's own calibration.

The clause is not a veto and not immunity. A hold that is not answered in time lapses to the next decision-maker in the charter. A hold cannot override the security policy, block a change for reasons of taste or prevent a change that the law or a supervisor requires. Holds and disagreements are reviewed by peers, and a pattern of holds that other seniors regard as unfounded is a conversation about calibration. The hold-and-override record also gives the organisation an alert in both directions: a unit with no holds in a quarter may have stopped exercising judgement, and a unit with very many may have a tool or a process that does not fit the work.

Delegation ceilings are in the charter as well, and Level 4 is never available to any assistant for a change to the agent's own mandate, permissions, credentials, test oracle, review rules or pipeline gates, for code in a security-critical path without review by a named developer, or for a decision about a named person's employment, pay, performance rating or access to work.

Worked example: ROLE-NR-DEV-01

The following charter is the role charter of the senior developer on the case platform team at Nordvik Region. It is illustrative, it follows the delegation profile DLG-NR-DEV-01, and the shares and times are design choices that the Region's own first review would revisit.

# roles/development/senior-developer-case-platform.yaml (Nordvik Region, illustrative)
id: ROLE-NR-DEV-01
title: Senior developer, case platform
version: 1.0.0
effective: 2031-02-01
adopted_by: AIDR-1114
owner: head-of-applications-and-integration
consulted: [union-it-representative, central-work-environment-committee, regional-legal-counsel]
negotiated_in: MBA-NR-2030-03
delegation_profile: DLG-NR-DEV-01
decision_rights:
  decides_alone: [design-of-changes-within-team-boundaries, review-outcome-for-tier-1-and-2-changes]
  needs_second_senior: [change-to-benefits-rules, database-migration, change-to-pipeline-gate]
  goes_to_manager: [conflict-between-holds, change-to-review-budget]
review:
  budget_share_of_working_time: 0.25     # recorded decision; changed only by AIDR
  mentoring_share_of_working_time: 0.10
  first_judgement_before_ai_comment: sampled_one_in_five
  ai_review_comment_counts_as_approval: false
  named_developer_review_required: [security-critical-path, benefits-rules, pipeline-gates, agent-mandate-change]
  seeded_error_drill: quarterly
  metrics: reported_by_team_only          # never by named developer
professional_judgement:
  hold: {prior_approval: not_required, record: reason_in_review_record, answered_within_working_days: 3}
  explanation_without_tool: may_require
  ownership: may_decline_if_cannot_understand_or_revert   # recorded, read by manager
  dissent: {record_to: ADR_or_review_record, answered_in_writing: true}
  appraisal: {ai_use_targets: none, acceptance_rate_in_appraisal: prohibited}
  unassisted_share_of_reviews: 0.10
  limits: {holds_reviewed_by: peer-senior, security_policy_overridable: false}
delegation_ceilings:        # from DLG-NR-DEV-01; a ceiling is not a licence
  review: Level 0 Advisory
  design: Level 0 Advisory
  migrate: Level 0 Advisory
  document: Level 2 Supervised
  level_4: never_for_own_mandate_or_security_critical_path_without_named_review_or_named_person_decisions
review_cycle: {cadence_months: 6, triggers: [agent-introduced, pilot-extended, incident]}

The charter names no person; competence and appointment are separate records (CMP-*, Chapter 27).

Employee representation

A charter that changes duties, sets a review budget and states how review metrics are reported touches matters on which employee representatives have rights. Under the Swedish Co-determination Act, the employer must negotiate with the union before deciding on an important change in its activities or in the working or employment conditions of members (section 11) (12, Sveriges riksdag & Regeringskansliet, 1976). Nordvik Region therefore takes the charter into the negotiation MBA-NR-2030-03 on developer tooling and telemetry that Chapter 22 describes. At Hansa Mutual the Konzernbetriebsrat co-determines under section 87(1) no. 6 of the Betriebsverfassungsgesetz on the introduction and use of technical devices suited to monitoring the behaviour or performance of employees (9, Germany, n.d.), and the review-metric rules of the charter sit beside the developer annex KBV-IT-2024-DEV-01 that is drafted in autumn 2030. In both cases the implication is the same: a review metric that can be traced to a named person is monitoring, and the charter says that it is not collected that way.

The pipeline of seniors

Seniors are made by doing the work that juniors do, for long enough to see what goes wrong. Much of that work, the small fix, the test for an existing function, the first draft of a routine service, is what assistants do first and fastest. The risk, which Chapter 13 treats in full, is that the organisation saves the junior hour and removes the school in which the senior was made. Whether the entry rung will in fact thin is not settled; the Stanford Digital Economy Lab paper on employment effects of AI calls its findings descriptive and not causal (51, Brynjolfsson et al., 2025), and what follows is therefore a design response to a risk, not a forecast.

The senior carries most of that response, in three ways.

Teaching through review. The review of a junior's change is the main occasion on which the craft passes. The senior asks the junior to explain the change and its alternatives, reads the junior's own first reasoning before the generated reasoning, and marks what a good change in this system looks like. The charter above reserves a tenth of working time for it. The time is budgeted because teaching is the first thing a team under delivery pressure stops.

Practising without the aid. Experienced professionals lose unaided skill beside reliable automation. Casner and colleagues documented the decay of manual flying skills in the automated cockpit (64, Casner et al., 2014). In a retrospective, observational study across four centres in Poland, the adenoma detection rate of endoscopists fell from 28.4 per cent before to 22.4 per cent after routine exposure to AI assistance in colonoscopy, measured when they worked without it (65, Budzyń et al., 2025). Both are observable outside software, neither studied developers and the second is not a randomised trial. It is expected, not shown, that the same pattern can arise in review and design work, and the response costs little: a share of reviews done without the assistant, a periodic exercise in which the senior reads and explains a module cold, and a record of who can still do which task unaided. AI Operations (Chapter 26) set the same kind of manual-practice interval for operators (170, Nordqvist, 2026).

Succession. The keeper of context needs a successor before leaving, not at the farewell. Each code-ownership record names a deputy; the deputy reviews alongside the owner for a stated period; a component with no deputy is reported as a risk. For legacy estates the work is urgent: Hansa Mutual's COBOL and PL/I platform is maintained by twelve people, five of whom are within eight years of retirement, and Naur's account says that an explainer tool can help a newcomer read text but cannot hand over the theory. The pilot of the legacy-code explainer HM-DEV-003, at Level 0 Advisory with four of the twelve developers, is useful for reading, and its evidence should be judged on whether newcomers can later change the code unaided and not on whether they find it helpful.

Staff and principal engineers

Will Larson, writing from practice, described four archetypes of the staff-plus engineer: one who guides the approach of a team or a few teams, the Architect who owns the direction of a critical long-lived technical domain, the Solver who takes on hard problems until they are resolved, and the Right Hand who extends an executive's reach (131, Larson, 2020). The archetypes come from practitioner experience at technology companies and are not an empirical classification. They are useful here because AI affects each one differently.

  • The team-level staff engineer holds the same context and review load as a senior, across more teams, and is the most exposed to the bottleneck. The remedy is the budget and the tiers described above, applied across the teams, plus the authority to ask a team to throttle its agents.
  • The architect archetype protects conceptual integrity (Brooks) when generation makes local divergence cheap. Its output is constraints that agents and developers can both use: interface contracts, architecture fitness checks that run in the pipeline, ADRs and golden paths. Chapter 16 treats architects, platform engineers and site reliability engineers as roles in their own right, and the overlap is deliberate.
  • The solver takes the incidents and cross-cutting defects; the solver's context is the asset, and a rotation that spreads it is the response.
  • The right hand advises an executive, and is a source of judgement independent of the assistant that drafts the executive's papers (AI Leader, Chapter 19).

Three duties are specific to staff and principal roles.

Standards as executable artefacts. A standard that exists as a document is read by few and checked by none. A staff engineer who writes the standard for review of generated code, for the independent test oracle and for the provenance of dependencies does better to express it as a check that runs in the pipeline, a template in the golden path and a record format, and to keep the prose short. The standard must not become a gate that the staff engineer alone can open.

Cross-team verification patterns. The corollary of the stewardship principle, that the test oracle must be independent of the generator, is a pattern across teams. The staff engineer owns the pattern (who writes the oracle for a change, how independence is shown), the teams own its application, and the quality engineers (Chapter 17) own its measurement.

Keeping the hands in. A principal who has not changed the system in two years risks becoming a reviewer who has lost the theory, so the charter for staff roles includes a build share as well as a review share.

Across the degrees of delegation

The delegation profiles of the two organisations set the ceilings below for the work classes that most concern the senior (DLG-NR-DEV-01, adopted under AIDR-1101, and DLG-HM-DEV-01, adopted under AIDR-1153). A ceiling is the highest degree permitted; it is not a licence, and at Nordvik Region practice before the profile was Level 0 apart from ambient completion.

Work class Nordvik Region ceiling Hansa Mutual ceiling What the senior keeps
Design Level 0 Advisory Level 0 Advisory The decision and the ADR; options may be drafted by the tool
Review Level 0 Advisory: no AI comment counts as the human review Level 1 Assisted: an AI comment never counts as one of the two required human approvals The judgement; the first view for a sample; named review of the security-critical path
Generate Level 1 Assisted Level 2 Supervised outside the security-critical and payment paths; Level 1 inside them Review of every pull request an agent opens; the right to hold
Refactor Level 1 Assisted Level 2 Supervised Approval of the boundary within which refactoring is allowed
Migrate Level 0 Advisory (reading and summarising legacy code for a developer) Level 0 Advisory The theory of the system; the decision to migrate or not
Document Level 2 Supervised Level 2 Supervised The check that documentation reflects reasons, not only text
Dependency updates (patch level) No separate class in DLG-NR-DEV-01; within Refactor, Level 1 Assisted Level 3 Bounded (MND-HM-DEV-01), outside the security-critical and payment paths, after a human approval of the class The approval of the class, the approved list and the review of the exceptions

The usage modes matter as follows. Mode 0 Ambient AI, such as completion switched on by an IDE update, reaches the senior's work without a decision and should be recorded (Nordvik's AIDR-1102 did so retrospectively). In Mode 1 Conversational assistants and Mode 2 Embedded workplace assistants, the senior calibrates their own reliance and the team's. In Mode 3 Agentic work tools the senior is the reviewer of what the agent opened and the author of the bounds in which it works. In Mode 4 Built AI applications, such as Hansa Mutual's test-drafting assistant HM-DEV-002, the senior reads the evidence about the tool. Neither organisation runs a coding agent in Mode 5 Autonomous production agents, and the Level 4 prohibitions would keep a senior's review in place if one did.

Nordvik Region and Hansa Mutual

Nordvik Region. The Region's seniors carry legacy knowledge in few heads. Linnea Sjöberg, a senior developer on the case platform team who has worked in the Region for 17 years, holds the history of the case-management system SVC-NR-003, a customised vendor product of about 1.1 million lines whose vendor support ends in 2033, and she is one of the sceptical users of the Mode 2 pilot NR-DEV-001 of 12 developers. The pilot's reported acceptance rate of 31 per cent and its "about four hours saved a week", from a survey answered by 9 of the 12, are claims of the kind that the Becker study cautions against: they come from telemetry and self-report, not from a measurement of delivery time (AVR-NR-2030-01, Chapter 20). Review is by one colleague from the same team, there is no rule on who reviews generated code, and 31 per cent of the Region's 96 repositories have an owner who has left or changed team (OWN-NR-2030-00). ROLE-NR-DEV-01 (AIDR-1114, effective 2031-02-01 after negotiation in MBA-NR-2030-03) addresses these: a review budget of a quarter of working time, the rule that no AI comment counts as approval, named-developer review for the benefits rules, the right to hold and to decline ownership without a deputy, and a mentoring share for the junior developers Emil Nordgren and Frida Lund (Chapter 13). With so few seniors, the Region's constraint is capacity: it cannot tier review among many seniors, and its first lever is the cap on what the pilot tools may generate. The review budget is also the figure against which the agentic mode of the tender NR-2030-041 should be assessed (Chapter 18).

Hansa Mutual. The group's staff engineers set standards across product teams, and its seniors include those who hold the oldest context. Ralf Hauser, a senior COBOL and PL/I engineer on the policy administration platform SVC-HM-003 with 31 years in the group, is one of the five maintainers within eight years of retirement. The settlement incident of June 2029 (INC-HM-2029-0207) paid 312 claims twice after a change to the COBOL settlement module was approved by one reviewer who was also the only other person who knew the module; the post-incident review found that no owner could explain the change. That incident shows the other side of the bottleneck: when seniors are few, review can become a formality performed by the one person who shares the author's blind spots, and a second approval is not independent if the second approver is always the same colleague. ROLE-HM-DEV-01 (AIDR-1164) therefore adds to the clause an independence rule for the second approval, a named deputy for every component of the COBOL estate, the right to decline to be the sole approver of a change in a security-critical or payment path, and a build share. The review-metric rules sit beside the draft KBV-IT-2024-DEV-01, which bars per-developer reporting of tool telemetry and the use of acceptance rates in appraisal. Staff engineers in Group Application Development (an illustrative description, not a named role in the profile), working with Hansa Forge, express the group's review and oracle standards as checks in the golden path, and their risk is the one named above, that the standard becomes a gate that only they can open.

Nordvik Region Hansa Mutual
Senior capacity A handful of seniors across 18 developers Many seniors, but legacy context in 12 people
Main risk Capacity and context in few heads Non-independent second approval; retirement of context holders
Charter ROLE-NR-DEV-01 ROLE-HM-DEV-01
Representation Negotiation under the MBL pattern (MBA-NR-2030-03) Konzernbetriebsrat co-determination (KBV-IT-2024-DEV-01)

Outlook

Three statements about the future of the role carry labels. That seniors are reviewers of generated code is observable: both organisations' delegation profiles place the human review of AI-assisted change with experienced developers. That formal review budgets, hold rights and independence rules for second approval will appear in role charters and works agreements where coding agents are widely adopted is expected, because the Level 4 prohibitions of this book's ladder and the oversight logic of the AI Act point to review as the place where accountability sits. That senior roles will absorb most of development, with juniors and other roles shrinking to little, is speculation: no study cited here supports it, and Chapters 13 and 29 return to it.

Summary

The senior's work is four jobs, review, mentoring, technical decision and the keeping of context, and AI makes the first draft of change cheaper without making any of the four cheaper. The chapter concerns D2 Design, because the senior's decisions bound what is generated and conceptual integrity is what generation puts under strain; D4 Prove, because review is the step that cannot be generated away and becomes the bottleneck unless inflow, tiers and budget are designed; and D5 Steward, because the senior holds the theory of the system and the pipeline that makes the next seniors depends on the time they are given to teach.

The chapter's conclusions are these. A review budget, a named share of working time changed only by recorded decision, keeps review from quietly becoming shallower. An AI comment is never the human review, because model errors are correlated and independence is what review is for. The professional-judgement clause gives the senior the right to hold a change, to require an explanation without the tool, to decline ownership that fails the stewardship tests Name, Understand and Revert, and to record dissent; it is time-limited and reviewed by peers, so it is not a veto. Review metrics belong to the team, and a charter that touches them goes through negotiation or co-determination. The pipeline of seniors is protected by mentoring time, unassisted practice and named deputies.

Chapter 15 turns to the tech lead and the engineering manager, who carry the team that the senior serves, and who set the review rules, the pace and the metrics under which the senior's charter operates.

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. Federal Republic of Germany. Betriebsverfassungsgesetz (BetrVG), section 87 (Mitbestimmungsrechte). Federal Ministry of Justice, gesetze-im-internet.de. (9, Germany, n.d.)
  3. Sveriges riksdag. Lag (1976:580) om medbestämmande i arbetslivet (MBL), 10 to 12 §§. Svensk författningssamling. (12, Sveriges riksdag & Regeringskansliet, 1976)
  4. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6), 775-779. (56, Bainbridge, 1983)
  5. Becker, J., Rush, N., Barnes, E. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. (63, Becker et al., 2025)
  6. Brooks, F. P. (1995). The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition. Addison-Wesley Professional. (215, Brooks, 1995)
  7. Brynjolfsson, E., Chandar, B. & Chen, R. (2025). 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. 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)
  9. Buçinca, Z., Malaya, M. B. & Gajos, K. Z. (2021). To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI in AI-assisted Decision-making. Proceedings of the ACM on Human-Computer Interaction 5(CSCW1). (44, Buçinca et al., 2021)
  10. Casner, S. M., Geven, R. W., Recker, M. P. & Schooler, J. W. (2014). The Retention of Manual Flying Skills in the Automated Cockpit. Human Factors 56(8), 1506-1516. (64, Casner et al., 2014)
  11. 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)
  12. Fagan, M. E. (1976). Design and code inspections to reduce errors in program development. IBM Systems Journal 15(3), 182-211. (104, Fagan, 1976)
  13. Goddard, K., Roudsari, A. & Wyatt, J. C. (2012). Automation bias: a systematic review of frequency, effect mediators, and mitigators. Journal of the American Medical Informatics Association 19(1), 121-127. (43, Goddard et al., 2012)
  14. Kahneman, D., Sibony, O. & Sunstein, C. R. (2021). Noise: A Flaw in Human Judgment. Little, Brown Spark. (88, Kahneman et al., 2021)
  15. Kim, E., Garg, A., Peng, K. & Garg, N. (2025). Correlated Errors in Large Language Models. ICML 2025; arXiv:2506.07962. (35, Kim et al., 2025)
  16. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors 52(3), 381-410. (57, Parasuraman & Manzey, 2010)
  17. Perry, N., Srivastava, M., Kumar, D. & Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? ACM CCS '23; arXiv:2211.03622. (34, Perry et al., 2023)
  18. Shen, J. H. & Tamkin, A. (2026). How AI Impacts Skill Formation. arXiv:2601.20245 (preprint). (67, Shen & Tamkin, 2026)
  19. Nordqvist, G. (2025). Architecture as Code. The Architecture as Code Series, Book 1. (161, Nordqvist, 2025)
  20. Nordqvist, G. (2026). The Transformed Security Architect. The Architecture as Code Series, Book 6. (166, Nordqvist, 2026)
  21. Nordqvist, G. (2026). AI Boss. The Architecture as Code Series, Book 7. (167, Nordqvist, 2026)
  22. Nordqvist, G. (2026). AI Purple. The Architecture as Code Series, Book 9. (169, Nordqvist, 2026)
  23. Nordqvist, G. (2026). AI Operations. The Architecture as Code Series, Book 10. (170, Nordqvist, 2026)
  24. Nordqvist, G. (2026). AI Leader. The Architecture as Code Series, Book 11. (174, Nordqvist, 2026)
  25. Bacchelli, A. & Bird, C. (2013). Expectations, outcomes, and challenges of modern code review. ICSE 2013, 712-721. (190, Bacchelli & Bird, 2013)
  26. Larson, W. (2020). Staff engineer archetypes. lethain.com. (131, Larson, 2020)
  27. Naur, P. (1985). Programming as theory building. Microprocessing and Microprogramming 15(5), 253-261. (181, Naur, 1985)
  28. Google Cloud (2024). Announcing the 2024 DORA report. Google Cloud Blog. (221, Google Cloud, 2024)