The Tech Lead and the Engineering Manager

The tech lead and the engineering manager are the two roles through which every decision about AI in development reaches a team. A delegation profile sets ceilings, procurement buys the tools and the works council negotiates the terms, but it is the lead who sets the rules for the pull request on a Tuesday and the manager who is asked, in the planning round, whether the team can be smaller. This chapter concerns three of the five developer functions defined in Chapter 4. D1 Frame is the lead's duty to keep intent ahead of generation. D3 Build is the team's rules for making software with assistants and agents: what may be generated, under which mandate, with what disclosure. D5 Steward is the team's answer to who owns what, who can stop a change and what evidence goes upward. The chapter asks what the tech lead owns that the tools do not, which measures help and which mislead, how pairing and onboarding change, how headcount is discussed with evidence, and what a team working agreement and weekly rhythm look like.

The team's operating loop: a delegation profile sets the ceiling, a team working agreement is applied in a weekly rhythm of framing, building, review and stewardship, measures are read in pairs each month, and the agreement is reviewed each quarter, with a stop path and the representatives outside the pipeline

Figure 15.1: The team's operating loop: agreement, rhythm and review.

Two jobs in one team

The tech lead's job

A tech lead is a developer who is accountable for the technical direction of a team's software. Software Engineering at Google draws the line between the two roles in a sentence: a manager is a leader of people, whereas a tech lead leads technology efforts, and on small and new teams a single person often does both as a tech lead manager, although the chapter's author prefers two specialists where the team can afford them (132, Fitzpatrick, 2020). The description predates generative AI and still holds; what changes is where the lead's attention goes.

Four things stay with the lead because no tool in the two organisations holds them.

Intent. An assistant generates from what it is given. The lead owns the order of events: acceptance criteria, scope and the list of what the team is not building are written before generation, because a change whose intent was written after the code has an oracle fitted to the code (Chapter 5 treats the specification record SPC-*).

The rules under which generated code enters the codebase. Who reviews, how many approvals are needed, whether the author discloses that a tool wrote or refactored a file, which paths need a named reviewer, which files agents may not edit. The ceilings come from a delegation profile DLG-* that someone above the team owns. The team may narrow a ceiling and may not raise one. That rule is the book's own, taken from the pattern of AI Leader, where lowering a degree of delegation is immediate and raising it is the decision of a named authority (AI Leader, Chapters 4 and 8) (174, Nordqvist, 2026).

The picture of the system. The Understand test asks that the owner of a change can explain what it does and why, and reconstruct it without the tool that generated it. In most teams the lead is the person who can explain how the parts fit, which is also the lead's exposure. At Hansa Mutual the duplicated settlements of June 2029 (INC-HM-2029-0207, illustrative) came from a change to a COBOL module that was approved by the only other person who knew the module, and the post-incident review concluded that the module had no owner who could explain the change (Chapter 12 returns to the case). A lead who is the only understander of a system has made the team's Understand test depend on one person's holiday. The lead therefore names deputies, rotates the review of parts that only the lead has read, and treats a missing deputy as a finding. Chapter 14 treats the related bottleneck risk for senior developers.

The stop. The Revert test asks that the owner has the authority, access and time to stop, roll back or fix a change outside the pipeline that shipped it. At team level it is the lead's right to lower a ceiling, switch an agent's mandate off or hold a merge without asking anyone, and to record that it was done. The right must work when the pipeline does not and carry no penalty for use.

Name, Understand and Revert are tests for a change, not a description of the lead's personal liability. The lead's job is to make them passable for every change in the team's repositories: an owner recorded in the code-ownership record OWN-*, a review that tests whether the author understands the change, and Revert rights with time to use them. A lead who becomes the named owner of everything has not passed the Name test but has become what Elish called a moral crumple zone, the human nearest the system who absorbs responsibility for outcomes that the design made hard to control (49, Elish, 2019) (AI Leader, Chapter 12 reaches the same conclusion for answerability). The lead owns the rules and the picture; owners own the changes.

One prohibition applies to the lead's own work. Level 4 is never used for a change to the agent's own mandate, permissions, credentials, test oracles, review rules or pipeline gates. The files that hold the team's review rules, the agent instruction file of a repository, the ownership file and the pipeline definition are therefore changed by people and reviewed by people. No assistant opens the pull request that loosens the rule that reviews its pull requests.

The engineering manager's job

The same chapter of Software Engineering at Google describes an engineering manager as responsible for the performance, productivity and happiness of every person on the team (132, Fitzpatrick, 2020). Three tasks follow: people, outcomes and headcount.

People means coaching, career, fairness, wellbeing and the conversations that no tool should hold. The evidence for the weight of this task comes from technology firms and not from AI studies. Using personnel data from one large high-technology firm, Hoffman and Tadelis found that survey-measured people-management skills were strongly associated with lower employee turnover, with research designs that, the authors argue, support a causal reading, while the same skills did not consistently improve most other outcomes (99, Hoffman & Tadelis, 2021). Garvin's account of Google's Project Oxygen reports that managers mattered, with lower turnover and higher satisfaction on the teams of high-scoring managers (140, Garvin, 2013). Neither study concerns AI; the book's inference is that the part of the manager's work that AI does not take is the part with the firmest evidence.

Outcomes means delivery, quality and security results at team level, and the duty to say what those figures cannot show. Headcount means the case for more or fewer people in a team and has its own section below.

A decision about a named person's employment, pay, performance rating or access to work is never delegated at Level 4. Both delegation profiles state that the people class is not delegated (DLG-NR-DEV-01, DLG-HM-DEV-01), and AI Boss concluded that every management function that carries consequences for a person has a named human decider who can be identified, contested and held to account (AI Boss, Chapters 4 and 33) (167, Nordqvist, 2026).

The earlier volumes settled much about the manager's layer, and this chapter does not repeat it. AI Leader concluded that AI unbundles the tasks of the middle manager whose inputs are text and records, coordinating, reporting and first-line answering, to at most Level 2 Supervised, and leaves coaching, judgement in exceptions and representation with a named person (AI Leader, Chapter 16). It added that coaching with data opens a conversation and never closes it, and that the figures of agents and the figures of people are kept apart (AI Leader, Chapter 17) (174, Nordqvist, 2026). AI Boss treats scores, monitoring and the chilling effect of both (AI Boss, Chapters 8 and 13), oversight that is real and not rubber-stamped (Chapter 26) and the manager as accountable leader of people and conductor of agents (Chapter 29). AI Operations treats on-call, toil and wellbeing for the operating half of "you build it, you run it" (AI Operations, Chapter 25) (170, Nordqvist, 2026). What is specific to developers is that the people managed often know the tools better than the manager, that evidence about them lives in repositories and telemetry that works agreements restrict, and that executives ask headcount questions with productivity studies in hand.

Where one person holds both roles

At Nordvik Region the tech leads also manage. Anders Falk leads the integration and data team of six and is its day-to-day manager. At Hansa Mutual the roles are separate: of about 290 developers, about 45 are tech leads, and the 20 engineering managers carry spans of 20 to 25, which is about three delivery teams each.

Each arrangement has a typical failure. Where one person holds both roles, the person who approves a developer's code also holds the conversation about the developer's year. The risk is that the developer has a reason to stop saying that a generated change looks wrong. Team psychological safety, the shared belief that the team is safe for interpersonal risk-taking, was associated with learning behaviour in Edmondson's study of 51 work teams in one manufacturing company (50, Edmondson, 1999); no comparable study of teams reviewing generated code was found, and the application here is the book's own step. Four design choices reduce the risk: review comments are not appraisal material; a second reader outside the team sees any people decision before it is taken; review rotates so that the lead is not the only gate; and the agreement states which measures are never used in appraisal.

Where the roles are separate, the manager cannot read the code of three teams. A manager with a span of 24 depends on the leads' judgement and on measures, and the typical failure is that measures replace knowing. The remedy is a rhythm in which the manager reads the monthly sample of AI-involved changes, not only a dashboard.

Question Tech lead Engineering manager
What the team builds and why, and the acceptance criteria Holds Informed
Review rules, disclosure and protected paths Writes and applies Signs the agreement
Narrowing a ceiling in the team Holds and records Informed
Raising a ceiling Proposes with evidence Takes to the owner of the delegation profile
Ownership records and deputies Holds Checks coverage
The stop right on a change or an agent Holds Holds a second route
Coaching, career, absence and wellbeing Contributes what is seen in the work Holds
Appraisal, pay, contract No part (or a second reader where the roles are one) Holds, with the line above; never delegated to a tool
Evidence upward Supplies, with scope and date Carries
Contact with the works council or union Informed Holds, with HR

Metrics that do not mislead

Every figure that leaves a team becomes someone's evidence, and a figure that has lost its scope is repeated by people who never saw it. The test is the claim with evidence: what was measured, how, when, with what result, and when it expires.

What the studies measured

Four sources show why a number from outside the team cannot be imported as a planning figure.

Source Who and what What was measured Result as reported Why a team lead cannot import it
(175, Peng et al., 2023) Controlled experiment; developers asked to write an HTTP server in JavaScript Time to complete the task, with and without GitHub Copilot The group with access finished 55.8 per cent faster One specified task, started from nothing
(176, Cui et al., 2024) Three randomised field experiments at Microsoft, Accenture and an anonymous Fortune 100 company; 4,867 developers Completed tasks A pooled increase of 26.08 per cent (standard error 10.3 per cent, as reported in the abstract; full text not read); authors describe the experiments as individually noisy; larger effects for less experienced and shorter-tenure developers Counts completed tasks in firms with different work, not quality or stability
(63, Becker et al., 2025) Randomised trial; 16 experienced open-source developers, 246 tasks in mature projects on which the developers averaged about five years of prior experience Time to complete a task, with AI tools allowed or disallowed, early-2025 tools Allowing AI increased completion time by 19 per cent; before the tasks developers forecast a 24 per cent reduction and afterwards estimated 20 per cent Small group, familiar repositories, early-2025 tools
DORA reports (216, Google Cloud, 2024) (42, Harvey & DeBellis, 2025) Annual survey of technology professionals; the 2025 report draws on nearly 5,000 respondents Self-reported use and reported delivery performance 2024: AI adoption associated with individual productivity, flow and job satisfaction and negatively with delivery stability and throughput; 2025: a positive relationship with throughput and product performance, a continued negative relationship with stability, 90 per cent of respondents using AI at work Survey associations, self-reported, across organisations of every kind

The four disagree on the surface. Underneath they agree with AI Leader's wider review: effects depend on the task, the person and the conditions, and perceived and measured effects can diverge (F161; AI Leader, Chapters 3, 10 and 20). The trial of experienced developers shows the divergence in one place: the developers who were slower with the tools believed they had been faster. The 2025 DORA report describes AI as an amplifier of what is already in a team (42, Harvey & DeBellis, 2025). None of these studies observed the claims core of Hansa Mutual or the case platform of Nordvik Region. No outside figure is therefore a planning figure; the team measures its own work, over a stated period, and says what it did not measure.

Acceptance rate, share of lines and other activity figures

Acceptance rate is the share of shown suggestions that a developer accepts. The share of AI-assisted lines is the share of committed lines that trace to an accepted suggestion. Both count activity at the keyboard, and both appear in the two organisations: the Mode 2 pilot at Nordvik Region reported an acceptance rate of 31 per cent for 12 developers (AVR-NR-2030-01), and at Hansa Mutual the dashboard of the IDE assistant reported that 42 per cent of committed lines in the claims product line were AI-assisted, counting accepted suggestions as a share of lines; a sample of 40 merged pull requests in August 2030 found 27 per cent of lines traceable to an accepted suggestion, and no one measured whether the lines stayed (AVR-HM-2030-01).

Three properties make these figures unsafe as measures of value. They count what was accepted, not what was needed, reviewed or right. Their denominators and counting rules differ between tools and versions, which is the difference between the 42 and the 27 per cent. And headcount arithmetic reaches for them first, because they are large and cheap to obtain.

Manheim and Garrabrant, writing on the variants of what is sometimes termed Goodhart's law, describe the failure that occurs when a metric used to improve a system is pushed so far that further optimisation is ineffective or harmful (61, Manheim & Garrabrant, 2019). For a team the point is simpler: a figure made a target is changed by the people it targets. The DORA programme's own guide lists, among the misuses of its delivery metrics, setting them as goals, relying on one of them, comparing very different applications and competing against other teams, and states that they are meant for the application or service level (222, Harvey, 2026).

A list that pairs every measure

The measures a team keeps are chosen so that no single one can be read alone. The SPACE framework argues that productivity cannot be captured by one metric or one dimension and names five, satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow (62, Forsgren et al., 2021). The list below is not SPACE but follows the same instinct: each measure is paired with a check that does not use the same data, as AI Leader concluded for first-line leaders (F171).

Measure Level What it shows How it misleads Pair with
Change lead time and deployment frequency Service, team Flow of changes to production Rises when changes are smaller or reviews thinner Change fail rate and rework rate
Change fail rate, deployment rework rate, failed deployment recovery time Service Instability Depends on how incidents are classified The monthly sample of AI-involved changes
Review wait time Team Whether review keeps pace with volume A short wait can mean a stamp, not a review A second reviewer re-reads five merged changes and logs what the first missed
Escaped defects traced to AI-involved changes Team Quality of generated and reviewed work Under-reported if disclosure is punished A blameless review of each (Chapter 23)
Ownership coverage Team, organisation Share of repositories and services whose owner in OWN-* is a living, active person or team A name in a file is not Understand An owner explains a recent change without the tool
Developer experience pulse Team Satisfaction and flow Self-selected, small groups An observed measure, such as time in the review queue
Acceptance rate, share of AI-assisted lines Tool, aggregated Usage Counts activity, not value Reported only as a usage claim with an expiry
Perceived time saved Survey Perception Can diverge from the measure in either direction The measured counterpart, or "not measured"

Three rules go with the list. Measures are held at team level, in groups of five or more, and per-person views are switched off in the tool; the draft developer-tooling annex KBV-IT-2024-DEV-01 at Hansa Mutual proposes this minimum group size, and at Nordvik Region telemetry is the subject of the negotiation record MBA-NR-2030-03. A lead does not keep a measure that a works agreement forbids. The agreement states which measures are never used in appraisal, so that developers can rely on it and the manager can be held to it. And each figure carries its date: the default clocks of AI Leader, 90 days for a usage claim and 180 days for a value claim, apply unless the team states others (F160).

Which figure must not reach the board

Both organisations have a figure that reached a senior body without its scope. At Nordvik Region the April 2030 note on the Mode 2 pilot, written by Anders Falk, went to the executive committee as "a third faster", although its data were an acceptance rate of 31 per cent for 12 developers and a survey answered by nine of them ("about four hours saved a week"); nobody had measured delivery time. At Hansa Mutual the 42 per cent went into the group CIO's report to the executive board in February 2030.

The figure that must not reach the board is the share of AI-assisted lines, or the acceptance rate, presented as productivity, as capacity or as the case for fewer developers. What may reach it is a claim with its parts. For Nordvik Region the honest form of the April note reads: in a pilot of 12 developers between February and April 2030, 31 per cent of suggestions were accepted; 9 of the 12 answered a survey and reported about four hours saved a week; delivery time was not measured; the usage claim expired 90 days after April 2030 and the value claim has not been measured. That sentence is less pleasing than "a third faster" and survives a question. Chapter 20 builds the adoption and value record AVR-* that keeps the quoted and the measured figure side by side; the lead sends nothing upward that the record would have to contradict.

Pairing and onboarding

Pairing with people and with assistants

Pair programming has an older evidence base than AI coding. A meta-analysis by Hannay and colleagues of experiments comparing pairs and individual programmers found, as its abstract is summarised in secondary records, a small positive overall effect on quality, a medium positive effect on duration (pairs finished sooner) and a medium negative effect on effort (pairs used more), with significant variation between studies and signs of publication bias (226, Hannay et al., 2009). Pairing changes outcomes in some tasks under some conditions, and it has costs.

No study was found that compares a developer paired with a person with one paired with an assistant, and the book's position is that an assistant is not a pair: it does not hold the team's earlier decisions, does not answer for the change and carries nothing to the next session unless someone has put it in a file. Chapter 21 treats the assistant as a teammate that is not one. Three forms of pairing are worth protecting because each puts two people where generation cannot verify itself:

  • Pairing to frame. Two people agree the acceptance criteria and the boundary of a change before generation begins (D1 Frame).
  • Pair review of an agent-opened change. Two people read the diff of a change in a security-critical or payment path, one reading before either sees the tool's summary. Under DLG-HM-DEV-01 an AI review comment never counts as one of the two required human approvals, and the Level 4 prohibition for security-critical code rests on a named human reviewer.
  • Pairing across the Understand test. A developer who has accepted a large generated change explains it to a colleague without the tool; the colleague asks where it is wrong.

Onboarding

Onboarding is the lead's responsibility for every new joiner: a junior, a senior from another firm, a transfer, a consultant. Chapter 13 designs the apprenticeship and the plans APR-NR-2030-01 (Emil Nordgren, joined in August 2030) and APR-HM-2030-01 (Aylin Demir, joined in September 2030). The lead makes the plans real by protecting the time in which a new colleague attempts a task before asking a tool and reads the owner's explanation of a module before changing it.

The evidence supports the caution. In randomised experiments by Shen and Tamkin, developers learned a new asynchronous programming library with and without AI assistance; AI use impaired conceptual understanding, code reading and debugging without significant average efficiency gains, participants who fully delegated coding showed some productivity improvements but learned less, and three of six identified interaction patterns preserved learning (67, Shen & Tamkin, 2026). The paper is a preprint, not peer reviewed. It measures learning, while the field experiments above measure output, in which less experienced developers gained more; the results do not contradict each other, but an onboarding plan that tracks only output will miss the loss the learning study found.

The lead's inference, not a finding of either study, is that onboarding is measured by the first change the new colleague can explain and has owned through production, not by the time to the first merged line. Three further duties follow:

  • The agreement is part of onboarding. A new joiner reads the team working agreement in the first week and the lead walks through it, including the paths where agents may not edit.
  • Consultants are in scope. Nordvik Region has about 22 consultant developers working inside its teams under framework NR-2025-102, and Hansa Mutual about 190 external developers, and the agreement applies to anyone who commits to the team's repositories. Nordvik's framework agreement had no clause on AI tools when a consultant pasted a test-database connection string into an unapproved public assistant in March 2030 (INC-NR-2030-0071, illustrative). The lead can enforce the rules through repository settings and training; the manager takes the missing clause to procurement (Chapter 18).
  • The assistant's own instructions are onboarded. Many tools read a repository file of instructions for the agent. The file is treated as part of the team's agreement: it has an owner, it is reviewed like code, and it is in the protected set that agents may not edit.

Headcount conversations

Sooner or later a lead or manager is asked whether the team can be smaller, usually with a number attached: a vendor's percentage, a pilot figure, a study from the press. A headcount conversation starts from a claim with evidence and ends with a decision by a person who has the authority.

What the labour-market studies say and do not say

Two studies of employment are often quoted. Brynjolfsson, Chandar and Chen, using administrative payroll data from ADP covering millions of US workers through June 2026, report in the revision of August 2026 that employment of workers aged 22 to 25 in AI-exposed occupations is 19 per cent below where it would be had it kept pace with less-exposed occupations, that the gap operates mainly through reduced hiring and not separations, and that experienced workers show no comparable gap; the authors call the findings early, descriptive indicators and not causal estimates, and report that the pattern weakens when education is controlled for (51, Brynjolfsson et al., 2025). Humlum and Vestergaard linked adoption surveys to Danish administrative records and found precise null effects on earnings and recorded hours at worker and workplace level, ruling out effects larger than 2 per cent two years after ChatGPT's launch (53, Humlum & Vestergaard, 2025). The results concern different countries, populations and outcomes, and neither says how many people a particular claims team needs; a lead who cites either should say so.

The form of the conversation

A headcount conversation is held on a record with six parts, so that each party can see what is being asserted.

  1. The claim. Who asserts what, quoted as asserted ("a third faster", "42 per cent AI-assisted").
  2. The scope. Which team, which work classes, which repositories and which period the claim concerns.
  3. The measure and the method. What was measured, how, and by whom; the evidence owner is independent of the sponsor of the claim (F160).
  4. The date and the expiry. When the figure was taken and when it lapses; "not measured" is a legitimate entry.
  5. The alternatives for the capacity. What the time could do instead: review, ownership gaps, legacy, apprenticeship, the test oracle. The demand side matters. The DORA reports associate AI adoption with a negative relationship to delivery stability (216, Google Cloud, 2024) (42, Harvey & DeBellis, 2025), and more generated change means more to review, own and operate. Review capacity is the constraint to look for.
  6. The decision owner and the next look. Who decides and when the claim will be re-examined.

The lead supplies the evidence; the manager carries the case upward and holds contact with HR and the representatives; the decision belongs to those with authority over budgets and structures. A decision about a named person's employment is never taken by a tool or a score.

The law sets the timing and not the content. At Nordvik Region, section 11 of the Swedish Co-determination Act obliges an employer bound by a collective agreement to negotiate on its own initiative with the union before deciding on an important change in its activities or in members' employment conditions (10, Swedish Parliament (Sveriges riksdag), 1976). At Hansa Mutual in Germany, section 90(1) no. 3 of the Works Constitution Act requires the employer to inform the works council in good time of planned work procedures and workflows, including the use of artificial intelligence, and section 90(2) requires consultation early enough for the council's proposals and concerns to be taken into account (95, Germany, n.d.); section 111 adds information and consultation on planned changes in the establishment that may entail substantial disadvantages for the workforce, among them restriction of significant parts of it and the introduction of fundamentally new working methods, in undertakings with more than twenty employees entitled to vote (148, Germany, n.d.). These are organisational implications and not legal advice, and the Polish and Dutch entities have their own rules. The practical consequence is that the evidence must exist before the decision: a manager who adopts "42 per cent" as a planning assumption and informs the representatives afterwards has the timing wrong.

Two conversations, illustrative

At Nordvik Region, after the note of April 2030, the executive committee asked in September 2030 whether the consultant volume under NR-2025-102, about 22 developers, could be cut by a third in the 2031 budget. Gunilla Roos and Anders Falk answered with a record: the claim was "a third faster"; the scope was a pilot of 12 developers, nine of whom answered a survey; the measures were IDE telemetry and the survey, and delivery time was not measured; the usage claim had expired in July 2030 and no value claim existed. The record proposed measuring lead time, change fail rate and rework rate for the case platform and the integration team over two quarters and keeping the consultant volume unchanged until the budget decision in April 2031. The union's IT representative, Tomas Ekblad, received it while MBA-NR-2030-03 was open.

At Hansa Mutual, a planning assumption for 2031 that cut planned external developer hours was based on the 42 per cent figure. Jens Albers and Stefan Brückner wrote the record. It quoted the 42 per cent (telemetry, February 2030) beside the 27 per cent (sample of 40 pull requests, August 2030), noted that no one had measured whether the lines stayed, marked the usage claim expired, and asked that the figure be withdrawn from the planning assumption until two quarters of team-level measures existed. The Konzernbetriebsrat was informed before the assumption became a plan.

A team working agreement

A team working agreement is a short, versioned file that states how a team works with AI and who is responsible for what. It sits below the delegation profile DLG-* and the mandate manifests MND-* and may narrow them. It sits below any works agreement and gives way to it. It is written by the tech lead, signed by the engineering manager, read by everyone who commits to the team's repositories, stored with the code and reviewed on a date and on triggers: a change of model by a provider, an incident in which an AI-involved change took part, a new tool, and a change in the delegation profile. It is not a policy, which is long and read once, nor a culture statement (Chapter 21), but a checklist that a new joiner can follow on the first day and an auditor can test.

A sound agreement has ten parts:

  1. Scope and ownership: repositories, people (including external members), owners and deputies in OWN-*.
  2. Work classes and ceilings: for each of the ten classes of development work, the inherited ceiling and any narrower one, with the paths where a lower ceiling applies.
  3. Review rules: the number of human approvals, that an AI review comment never counts as one, that the reviewer forms a view of the diff before reading the tool's summary, a size limit, protected review time, a named reviewer for security-critical paths and disclosure of AI involvement.
  4. The oracle: tests for a change are written or approved by someone other than its author, and tool-drafted tests count once a person has read them (Chapter 9).
  5. Agents and mandates: which agents work under which MND-*, that no agent merges, and the protected files that agents do not edit.
  6. Data and secrets: what may go into a prompt, which code may reach only self-hosted models, and what to do on a leak.
  7. Metrics: the measures kept, their levels, those never used in appraisal and the expiry of each claim.
  8. Rhythm: the weekly and monthly blocks.
  9. Onboarding: what a new joiner reads and does in the first weeks.
  10. Stop and review: who may lower a ceiling, how it is recorded, the review date and the triggers.

The obligation of the deployer to support the AI literacy of its staff gives the onboarding and training clauses a legal footing: Article 4 of the AI Act, as replaced by Article 1(5) of Regulation (EU) 2026/1744, requires providers and deployers to take measures to support the development of AI literacy of their staff and does not require them to guarantee any specific level for any individual (5, European Union, 2026). The agreement is where that duty becomes an activity of a team.

Practical guide: Writing a team working agreement for AI-assisted development with review rules and a metrics list

Purpose. To give a development team a written, checkable agreement on how it works with AI, with review rules and a metrics list that the team and the representatives can read.

Roles. The tech lead, who writes it; the engineering manager, who signs it; developers, including juniors and external members, who test whether it can be followed; a quality or test engineer for the oracle clause; a platform engineer, who knows what the pipeline and gateway enforce; the owner of the delegation profile, informed; the works council or union representative, informed before adoption where telemetry or work organisation is touched; the data protection officer where prompts or logs hold personal data.

Inputs. The delegation profile and mandate manifests for the team's tools; the works agreements and negotiation records in force; the ownership records; the team's incident and review history; the latest adoption and value record.

Steps.

  1. Collect the ceilings from the delegation profile, mandate manifests and works agreements, and write them at the top of the file so that the team narrows from them.
  2. Establish what the team uses by asking, in a team session or an anonymous survey. Do not use tooling to detect which individuals use which tools: the agreement rests on what people say, and a team that expects covert detection stops telling the lead anything.
  3. Write the scope and ownership clause. Check each repository against OWN-* and name a deputy for every owner.
  4. Write the review rules and the oracle clause from the team's own incidents, and test each rule against the question whether a colleague could break it by accident.
  5. Write the protected set: the agreement, the review rules, the ownership file, the agent instruction file, the pipeline definition and the test oracles, with the agents' ceiling on them at Level 0 Advisory.
  6. Write the data clause with the platform engineer and test it against the last leak.
  7. Write the metrics list with level, pair, expiry and non-use in appraisal; strike every measure the works agreement does not allow.
  8. Write the rhythm and put it in calendars; a rule without reserved time is not kept.
  9. Walk through the draft with the whole team, including external members and juniors, and change what they cannot follow. Send it to the representatives before adoption where it touches their rights.
  10. Set the review date and triggers, store the file in the repository, link it from the pull request template and record each change as a pull request.

Result. An agreement file under version control, a weekly rhythm in the calendars, and a log of changes. The agreement is the artefact that the Name and Revert tests need at team level.

Worked example: A team working agreement and weekly rhythm for a claims-platform team

The claims core delivery team in Hamburg at Hansa Mutual (illustrative) has nine people: seven employees and two external developers from Wiślana Software. Its tech lead is Stefan Brückner (ROLE-HM-TCL-01). Its engineering manager is Jens Albers (new, illustrative), who has a span of 24 across three delivery teams. The team builds and maintains the claims core SVC-HM-001, and its settlement interface to SVC-HM-004 counts as a payment path. It was adopted on 14 October 2030 after two team sessions, stays within DLG-HM-DEV-01 and carries the agent pilot's mandate MND-HM-DEV-02.

# teams/claims-core-hamburg/working-agreement.yaml (illustrative)
version: "1.0"
adopted: 2030-10-14
review_due: 2031-01-13
review_triggers: [provider_model_change, incident_with_ai_involved_change, new_tool, change_of_dlg]
tech_lead: ROLE-HM-TCL-01
engineering_manager: Jens Albers
ceilings_from: DLG-HM-DEV-01          # the team may narrow a ceiling, never raise it
scope:
  repositories: [claims-core, claims-settlement-interface]
  people: {employees: 7, external: 2}
  owners: OWN-HM-*                    # each owner has a named deputy
work_classes:
  generate: {ceiling: "Level 2 Supervised", lower_on: [payment, authentication], lower_ceiling: "Level 1 Assisted"}
  refactor: {ceiling: "Level 2 Supervised"}
  test: {ceiling: "Level 1 Assisted", oracle: "written or approved by someone other than the change author"}
  review: {ceiling: "Level 1 Assisted"}
  migrate: {ceiling: "Level 0 Advisory"}
review:
  human_approvals_for_production: 2
  ai_comment_counts_as_approval: false
  reviewer_reads_diff_before_ai_summary: true
  max_lines_per_review: 400           # team choice, revisited at review
  protected_review_windows: ["Tue 10:00-12:00", "Thu 10:00-12:00"]
  named_reviewer_required_on: [payment, authentication]
  pull_request_states_ai_involvement: true
agents:
  mandate: MND-HM-DEV-02
  may_merge: false
  protected_files: [working-agreement.yaml, CODEOWNERS, pipeline definition, agent instruction file, test oracles]
  ceiling_on_protected_files: "Level 0 Advisory"
data:
  claims_code_models: self-hosted-frankfurt-only
  prompts_must_not_contain: [credentials, personal data]
metrics:
  level: team            # minimum group size 5; per-person views off
  kept: [change_lead_time, change_fail_rate, rework_rate, review_wait, ownership_coverage]
  usage_claims: {acceptance_rate: "usage only, expiry 90 days"}
  never_used_in_appraisal: [acceptance_rate, ai_assisted_line_share, per_person_telemetry]
  governed_by: KBV-IT-2024-DEV-01     # draft; this clause gives way when the annex is adopted
stop:
  tech_lead_may_lower_ceiling: true   # recorded in the log; raising goes to the owner of DLG-HM-DEV-01

The weekly rhythm turns the clauses into hours.

When Block Function What it produces
Monday, 30 minutes Framing check D1 Frame Acceptance criteria and a named owner for each item of the week, written before generation
Tuesday and Thursday, two hours Protected review windows D3 Build Human review first, the tool's summary second; disclosures read
Wednesday, 45 minutes Sample of AI-involved changes D5 Steward A second reviewer re-reads five merged changes and logs what the first missed
Thursday, 30 minutes Team review D3 Build Findings, near misses and rejected dependency names from the package proxy discussed
Friday, 15 minutes Ownership and stop check D5 Steward Owners without deputies, changes waiting for revert, any ceiling lowered this week
Monthly, one hour Lead and manager D5 Steward Measures read in pairs; the sample read by the manager
Quarterly Agreement review D5 Steward Amendments, a refreshed claim record, any headcount question answered with evidence

The Thursday block takes a lesson from the package that did not exist (FND-HM-2030-0012, March 2030, illustrative): the Hansa Forge package proxy refused a dependency name that an agent had proposed and that was not in the registry, and two earlier rejections had gone unreported. The agreement makes the proxy's rejections a weekly item.

Across the usage modes

The ceilings below are the highest that the two profiles have allowed, and the last column gives the lead's part at each mode.

Usage mode Nordvik Region Hansa Mutual What the tech lead sets
Mode 0 Ambient AI Completion in the IDEs, on by default since March 2030; generate at Level 1 Assisted (AIDR-1102 filed afterwards) Ambient AI in IDEs and the repository platform, treated as the generate class: Level 2 Supervised outside and Level 1 Assisted inside the payment and security-critical paths; the managed provider's own assistance on the mainframe batch has no ceiling the team can set Know what is switched on; raise the gap with the manager
Mode 1 Conversational assistants Approved enterprise assistant for internal code; not for special-category data, credentials or the benefits-triage rules; drafts only Approved enterprise tiers; drafts only The data clause
Mode 2 Embedded assistants Pilot NR-DEV-001 for 12 developers; generate, refactor and test drafts at Level 1 Assisted, document at Level 2 Supervised HM-DEV-001 for about 340 developers; generate and refactor at Level 2 Supervised outside payment and security-critical paths, Level 1 Assisted inside Review rules, disclosure, protected paths
Mode 3 Agentic work tools Platform team only, drafting infrastructure code and runbooks and never applying change; none for Applications and Integration until tender NR-2030-041 closes in November 2030 About 120 engineers; sandbox, pull requests, never merge to the protected branch (Level 2 Supervised); one Level 3 Bounded class, patch-level dependency updates under MND-HM-DEV-01 Mandate, sandbox, protected files, stop
Mode 4 Built AI None for developers HM-DEV-002 test drafting at Level 1 Assisted; HM-DEV-003 legacy-code explainer at Level 0 Advisory in a pilot Independence of the oracle, the monthly sample
Mode 5 Autonomous production agents None, by the Region's rule No coding agent merges or deploys on its own; the operations agent acts under AI Operations Nothing: any proposal goes to the owner of the profile

Level 4 Autonomous appears in no row and no team agreement sets it in any class named in the prohibitions: a change to production without a gate that the change cannot alter, security-critical or safety-critical code without human review by a named developer, a change to an agent's own mandate, permissions, credentials, test oracles, review rules or pipeline gates, an irreversible action on production data, and a decision about a named person's employment, pay, performance rating or access to work.

Nordvik Region and Hansa Mutual

At Nordvik Region, Applications and Integration has 18 developers, three of them tech leads who also manage. Anders Falk leads the six-person integration and data team, ran the Mode 2 pilot and wrote the April 2030 note. His team's agreement is shorter than the Hamburg example and gives way to MBA-NR-2030-03, which opened in September 2030 on developer tooling and telemetry; under the Swedish pattern the Region negotiates before an important change, and the union's IT representative, Tomas Ekblad, asked in June 2030 to negotiate before the pilot is extended. The Region's weak points are ownership, where 31 per cent of its 96 repositories have an owner who has left or changed team (OWN-NR-2030-00), and consultants under a framework with no clause on AI tools. Falk reissued the pilot note on 7 October 2030 with scope, date and expiry (illustrative).

At Hansa Mutual, with about 290 developers, 62 delivery teams and 20 engineering managers, the roles are separate and the manager's reading of measures is the main risk. Stefan Brückner owns the 42 per cent figure in his team and the pilot mandate MND-HM-DEV-02, and withdrew the figure from his team's reporting on 14 October 2030 when the agreement was adopted (illustrative). In an audit of August 2030, 14 of 410 services had no active owner and the COBOL estate was owned by a department, not a person (OWN-HM-2030-00). The Konzernbetriebsrat co-determines, for matters that concern the group as a whole or cannot be regulated by the individual works councils (section 58), under section 87(1) no. 6 of the Works Constitution Act on tools suited to monitor behaviour or performance (9, Germany, n.d.), which is why the metrics clause in the agreement defers to the draft annex KBV-IT-2024-DEV-01.

Observable, expected and speculation

The labels are those of AI Governance, Chapter 22 (162, Nordqvist, 2026). Observable: AI use in development is widespread in the surveys cited here (90 per cent of the 2025 DORA respondents, self-reported), the studies disagree on the effect on speed, and team-level agreements on AI use exist in the illustrative practice of the two organisations. Expected: metrics reform towards team-level, paired and dated measures, which the DORA programme's own guidance already asks for and which the draft annex at Hansa Mutual and the negotiation at Nordvik Region would require; and support for AI literacy as a concrete activity of teams, since Article 4 of the AI Act as replaced still obliges providers and deployers to take measures. Speculation: teams without leads, in which agents coordinate the work and people review it. A review of self-managing organisations examines the limits of less-hierarchical organising (141, Lee & Edmondson, 2017), and AI Leader found that evidence on delayering is conditional and none tests whether AI carries the coordination (F165). The book's position is that the lead's intent, rules, picture and stop do not transfer; Chapter 29 tests it.

Summary

The tech lead and the engineering manager are the roles through which decisions about AI reach a team, and the chapter concerns D1 Frame, D3 Build and D5 Steward. The tech lead owns what the tools do not: the intent that precedes generation, the rules under which generated code enters the codebase, the picture of the system that makes the Understand test passable, and the stop. The engineering manager owns people, outcomes and the headcount case, and a decision about a named person's employment, pay, performance rating or access to work is never delegated at Level 4. Where one person holds both roles, as at Nordvik Region, review and appraisal are separated by design; where the roles are separate, as at Hansa Mutual, measures must not replace knowing.

Metrics that do not mislead are held at team level, paired with a check that does not use the same data, and dated. The studies disagree on the surface and agree underneath that effects depend on task, person and conditions; none observed the two organisations' codebases. The figure that must not reach the board is the share of AI-assisted lines or the acceptance rate presented as productivity, capacity or the case for fewer developers. What may reach it is a claim with scope, method, date, result and expiry.

Pairing is protected where two people verify what generation cannot, and onboarding is measured by the first change that a colleague can explain and has owned through production. A headcount conversation is held on a record with six parts, with the evidence in place before the decision and the representatives informed in time. The team working agreement and its weekly rhythm make the whole defensible: they narrow a delegation profile and never raise one, protect the files that govern the agents, and are reviewed on a date and on triggers. A lead's agreement is only as good as the ownership underneath it and the contract around it. Chapter 16 turns to the neighbours of the developer: architects, platform engineers and site reliability engineers.

Sources

  1. Nordqvist, G. (2026). AI Leader: How Leadership Roles Change When AI Is Used Broadly in European Enterprises and Public Authorities. The Architecture as Code Series, Book 11, published at leader.geon.se. (174, Nordqvist, 2026)
  2. Nordqvist, G. (2026). AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. The Architecture as Code Series, Book 7, published at aiboss.geon.se. (167, Nordqvist, 2026)
  3. Nordqvist, G. (2026). AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. The Architecture as Code Series, Book 10, published at aiops.geon.se. (170, Nordqvist, 2026)
  4. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 2, published at aig.geon.se. (162, Nordqvist, 2026)
  5. Fitzpatrick, B. (2020). How to Lead a Team. Chapter 5 in Winters, T., Manshreck, T. & Wright, H. (eds), Software Engineering at Google; chapter edited by R. MacNamara. O'Reilly Media, March 2020. Available at: https://abseil.io/resources/swe-book/html/ch05.html (accessed 2026-11-11). (132, Fitzpatrick, 2020)
  6. DevOps Research and Assessment (DORA) programme, Google Cloud. DORA's software delivery performance metrics. dora.dev guide. Available at: https://dora.dev/guides/dora-metrics/ (accessed 2026-11-11). (222, Harvey, 2026)
  7. Hannay, J. E., Dybå, T., Arisholm, E. & Sjøberg, D. I. K. (2009). The effectiveness of pair programming: A meta-analysis. Information and Software Technology 51(7), 1110-1122. DOI: 10.1016/j.infsof.2009.02.001. (226, Hannay et al., 2009)
  8. Peng, S., Kalliamvakou, E., Cihon, P. & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590, submitted 13 February 2023. Available at: https://arxiv.org/abs/2302.06590 (accessed 2026-11-11). (175, Peng et al., 2023)
  9. 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; later published in Management Science (DOI: 10.1287/mnsc.2025.00535). Available at: https://papers.ssrn.com/abstract=4945566 (accessed 2026-11-11). (176, Cui et al., 2024)
  10. 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, submitted 12 July 2025, revised 25 July 2025. Available at: https://arxiv.org/abs/2507.09089 (accessed 2026-11-10). (63, Becker et al., 2025)
  11. Google Cloud, DORA (2024). Accelerate State of DevOps Report 2024. DevOps Research and Assessment (DORA) programme, Google Cloud, October 2024. Available at: https://dora.dev/research/2024/dora-report/ (accessed 2026-11-11). (216, Google Cloud, 2024)
  12. Harvey, N. & DeBellis, D. (2025). Announcing the 2025 DORA report: State of AI-assisted Software Development. Google Cloud Blog, 23 September 2025. Available at: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report (accessed 2026-11-10). (42, Harvey & DeBellis, 2025)
  13. Manheim, D. & Garrabrant, S. (2019). Categorizing Variants of Goodhart's Law. arXiv:1803.04585, version 4 of 24 February 2019. Available at: https://arxiv.org/abs/1803.04585 (accessed 2026-11-10). (61, Manheim & Garrabrant, 2019)
  14. 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. Available at: https://queue.acm.org/detail.cfm?id=3454124 (accessed 2026-11-10). (62, Forsgren et al., 2021)
  15. Shen, J. H. & Tamkin, A. (2026). How AI Impacts Skill Formation. arXiv:2601.20245, submitted 28 January 2026, revised 1 February 2026 (preprint, not peer reviewed). Available at: https://arxiv.org/abs/2601.20245 (accessed 2026-11-10). (67, Shen & Tamkin, 2026)
  16. Hoffman, M. & Tadelis, S. (2021). People Management Skills, Employee Attrition, and Manager Rewards: An Empirical Analysis. Journal of Political Economy 129(1), 243-285. DOI: 10.1086/711409; working-paper version NBER Working Paper 24360. (99, Hoffman & Tadelis, 2021)
  17. Garvin, D. A. (2013). How Google Sold Its Engineers on Management. Harvard Business Review, December 2013. Available at: https://hbr.org/2013/12/how-google-sold-its-engineers-on-management (accessed 2026-11-11). (140, Garvin, 2013)
  18. Edmondson, A. (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly 44(2), 350-383. DOI: 10.2307/2666999 (accessed 2026-11-10). (50, Edmondson, 1999)
  19. Elish, M. C. (2019). Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction. Engaging Science, Technology, and Society 5, 40-60. DOI: 10.17351/ests2019.260 (accessed 2026-11-10). (49, Elish, 2019)
  20. Lee, M. Y. & Edmondson, A. C. (2017). Self-managing organizations: Exploring the limits of less-hierarchical organizing. Research in Organizational Behavior 37, 35-58. DOI: 10.1016/j.riob.2017.10.002 (accessed 2026-11-11). (141, Lee & Edmondson, 2017)
  21. 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. Working paper, not peer reviewed. Available at: https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/ (accessed 2026-11-11). (51, Brynjolfsson et al., 2025)
  22. Humlum, A. & Vestergaard, E. (2025). Still Waters, Rapid Currents: Early Labor Market Transformation under Generative AI. NBER Working Paper 33777, May 2025, revised March 2026. Available at: https://www.nber.org/papers/w33777 (accessed 2026-11-11). (53, Humlum & Vestergaard, 2025)
  23. Swedish Parliament (Sveriges riksdag). Lag (1976:580) om medbestämmande i arbetslivet (Co-determination in the Workplace Act), sections 10 to 12. Svensk författningssamling 1976:580. (10, Swedish Parliament (Sveriges riksdag), 1976)
  24. Federal Republic of Germany. Betriebsverfassungsgesetz (BetrVG), section 87 (Mitbestimmungsrechte). Federal Ministry of Justice, gesetze-im-internet.de. (9, Germany, n.d.)
  25. Federal Republic of Germany. Betriebsverfassungsgesetz (BetrVG), section 90 (Unterrichtungs- und Beratungsrechte). Federal Ministry of Justice, gesetze-im-internet.de. (95, Germany, n.d.)
  26. Federal Republic of Germany. Betriebsverfassungsgesetz (BetrVG), sections 5, 58, 76, 77, 80, 90, 95 and 111. Federal Ministry of Justice, gesetze-im-internet.de. (148, Germany, n.d.)
  27. European Parliament and Council of the European Union. Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). Official Journal of the European Union, 24 July 2026. Available at: https://eur-lex.europa.eu/eli/reg/2026/1744/oj (accessed 2026-11-10). (5, European Union, 2026)