Team Practice and Culture: Pairing, Review Culture, Trust and Psychological Safety

Chapter 20 asked how a leader measures adoption without mistaking use for value. This chapter turns to the team, because the evidence that decides whether AI helps or harms a piece of software is produced in daily routines: how people work with an assistant, how they review what it generated, how far they trust it, and whether they say so when it is wrong. It concerns D3 Build, because the way a developer directs and accepts generated code is a habit before it is a policy, and D4 Prove, because review, testing and the reporting of defects are carried by a team's culture as much as by its tools. The chapter treats pairing with an assistant, review culture, trust calibration, speaking up, the safety of juniors to ask, shadow AI and a team practice agreement short enough to be checked.

The team's trust loop: use, review, report, learn, with the stop right and the safety to ask outside the pipeline

Figure 21.1: The team's trust loop: use, review, report and learn, calibrated by a trust ledger, with a stop right outside the pipeline and a question that may always be put to a person.

The argument has five parts. An assistant can be worked with in a pairing-like way but is not a second person, and the difference is the absence of someone who can be named, who understands and who can revert. Review culture decides whether review is a gate that is passed or a practice that finds things. Trust in generated code is calibrated against outcomes that the team records. Speaking up depends on what happens to the person who speaks, and an assistant changes what that risks at three points. Shadow AI and concealment are signals about all of this, and the response is an approved route, not a hunt.

What the earlier volumes settle

The chapter takes five conclusions as its starting point. AI Leader, Chapter 21, concluded that trust in AI is calibrated and not maximised, that psychological safety is a property of teams, that an assistant changes what speaking up risks at three points, the record, the count and the draft, each a rule a named leader sets, and that shadow AI and concealment are signals about trust (174, Nordqvist, 2026). This chapter applies those points to a development team. AI Threat, Chapters 6 and 14, concluded that relying on AI reduces effort, recall and, among those who trust the tool, checking, and that the response is drafting first, unassisted practice, seeded-error drills and an oversight-quality metric reported at team level (165, Nordqvist, 2026). AI Operations, Chapter 25, concluded that responsibility tends to land on the person nearest the system and that the design response is structural, a stop right without penalty and metrics about the rota, never the person (170, Nordqvist, 2026). AI Purple, Chapter 23, set out when a session is safe for the truth: roles and not people are named, no result enters an appraisal and anyone may pause (169, Nordqvist, 2026). AI Boss, Chapter 13, treated the chilling effect of monitoring (167, Nordqvist, 2026). Chapter 4 added the stewardship principle (Name, Understand, Revert) and the independent test oracle. Chapter 9 treats the mechanics of review and testing; this chapter treats the culture in which they happen.

Pairing with an assistant

A developer who talks to an assistant while writing code is often said to be pairing with it. The comparison carries expectations that the tool cannot meet. Pair programming puts two people on one piece of code, one writing and one thinking ahead, and its evidence is conditional. A meta-analysis of experiments on pair programming reported a small positive effect on quality, a medium positive effect on duration and a medium negative effect on effort, so that pairs finished sooner and used more person-hours, with significant variation between the studies and signs of publication bias; the authors concluded that moderating factors, such as task complexity, deserve attention (226, Hannay et al., 2009). The studies concern two humans, before generative AI, and say nothing directly about a person and a model. They do show that the value of pairing lies in a second mind that questions what the first intends.

An assistant supplies something like the second half of that exchange: it proposes, and the developer accepts, edits or rejects. What it cannot supply is the part of a pair that carries responsibility. A human partner can be named in the pull request, can explain the change to a colleague a month later, and can be asked to help revert it. The tool does none of these, which is the content of the stewardship principle of Chapter 4: AI may draft, generate and refactor, and the developer who commits the result passes the tests Name, Understand and Revert. A rule of language follows: a developer works with an assistant, and pairing is reserved for two people. A team that believes it paired has a reason to believe the change was reviewed, and that belief is the failure that the review culture below exists to prevent.

The evidence on the interaction is early and varied. A study in which 21 programmers completed coding tasks with an AI completion tool and then labelled their own sessions with a taxonomy of activities reported that the taxonomy revealed inefficiencies and time costs in the interaction (211, Mozannar et al., 2024). A randomised controlled trial of 16 experienced open-source developers on 246 tasks in repositories they knew well found that, with the tools of early 2025 allowed, tasks took 19 per cent longer; before the trial the developers had forecast a 24 per cent reduction in completion time and afterwards estimated that the tools had reduced it by 20 per cent (63, Becker et al., 2025). The scope is narrow: sixteen people, one kind of codebase, one period, and tools that have since changed. Its value to a team is the gap between belief and measurement. The same gap is reported from the other direction in a user study of security-related programming tasks, where participants with an assistant wrote significantly less secure code than those without and were more likely to believe their code was secure, while those who trusted the assistant less and engaged more with their prompts wrote code with fewer vulnerabilities (34, Perry et al., 2023). None shows that a team's own experience will be the same. Together they suggest that the feeling of being helped is a poor measure of being helped, and that a team has to check it against something it can count.

For the practice of a team, three conclusions follow, and they are the book's own. First, the developer is the driver and the navigator at once when working with an assistant, and has to supply the questioning that a human partner would, which is why the habit of stating the intent before generating (Chapter 5) belongs in the practice. Second, where a change is in a security-critical or safety-critical path, authentication, authorisation, cryptography, payment or clinical logic, a second human is the pair, and the pairing happens on the review and on the oracle, not on the generation. Third, a critique from a second model is an input to the human review and never a substitute for it; at both organisations an AI review comment never counts as one of the human approvals.

Review culture

Review is the point at which a team's culture meets generated code. Code review as practised in industry has several purposes, finding defects among them. The practitioner documentation of one large company states the purpose in a form that is useful for any team: the primary purpose of review is to make sure that the overall code health of the code base is improving over time, and reviewers should favour approving a change once it definitely improves code health, even if it is not perfect (212, Google, n.d.). That is one company's standard, set out as guidance and not as a measured effect, and it is quoted here because it states two obligations that pull against each other. A reviewer must not let a change sit because it falls short of an ideal, and a reviewer must not approve a change that makes the code worse. Generated code puts pressure on both.

Generated code changes the pressure in three ways. The first is volume. A developer with an assistant can produce more changes than before, and the 2025 report of the DevOps Research and Assessment (DORA) programme, based on a survey of nearly 5,000 technology professionals, associates AI adoption with higher delivery throughput and with lower delivery stability, and attributes the instability to AI increasing the volume of change without strong controls such as automated testing, mature version control and fast feedback loops (42, Harvey & DeBellis, 2025). The reading is the programme's own, from a survey association, not a trial. Review capacity is where a team's culture absorbs the load or fails to (Chapter 9). The second change is authorship. A reviewer can ask a colleague why; for a generated change the reviewer can ask only whether the colleague understood it. The third is tone. A review of generated code can slide into a review of the person who accepted it, and a team that allows this teaches its members to hide their use of the tool.

The practices that follow are modest and specific.

The author reads the diff first. The author of a change, whoever or whatever wrote it, reads the whole diff before asking anyone else to, and can state in the pull request what the change is for and what was checked. This is the Understand test applied before review begins, and it is the single most effective way to keep the reviewer from becoming the first reader.

Disclosure is routine and has one purpose. The pull request says whether an assistant or an agent took part and, for an agent, links the run record (RUN-*, Chapter 8). The purpose of disclosure is to tell the reviewer where to look harder and to feed the provenance record (PRV-*, Chapter 10). It is not a mark against the author, and the count of disclosures per person is never reported to anyone. This is the rule on the count that AI Leader, Chapter 21, set: no individual figure goes to a leader (174, Nordqvist, 2026).

The reviewer starts from their own judgement. The reviewer reads the change and the specification (SPC-*) and forms a view before reading any AI-generated summary or comment, the discipline that AI Leader, Chapter 19, and AI Threat, Chapter 14, derive from the research on automation bias (165, Nordqvist, 2026). A systematic review of automation bias in decision support examined how often automation bias occurs, the factors that mediate it and the measures that mitigate it (43, Goddard et al., 2012), and the AI Act asks overseers of high-risk systems to remain aware of the possible tendency of automatically relying or over-relying on a system's output (Article 14(4)(b)) (1, European Union, 2024). A team that builds no high-risk system is not subject to that provision, but the tendency it names does not depend on the legal category.

A reviewer may return a change as too large to understand. The right to say "I cannot review this" is a condition of review being real, and the tech lead protects review time in the sprint plan, because time that exists only if nothing else is urgent stops when the volume rises. The practice agreement below gives it a number.

Comments concern the code. A comment says what is wrong and why. It does not speculate on how the author came to produce the change. An AI reviewer's comments are drafts for the human reviewer to adopt or discard, so that the human owns the finding.

Review culture is easy to claim and hard to evidence. A team that says its review is thorough should be able to say what a sample of its review records (RVW-*) shows: how many reviews led to a change, how long a review took, and how often a defect found after merge had passed review. These are measures of the team's review, reported for the team, and Chapter 20 sets the rule that they never become a ranking of reviewers.

Trust calibration

Trust in an assistant is not a feeling to raise. The review by Lee and See of trust in automation concluded that trust guides reliance, that the design problem is appropriate reliance, and that whether trust is appropriate depends on the context, the characteristics of the automation and the cognitive processes of the person (146, Lee & See, 2004). Applied to a development team, calibration means that the team relies on the assistant where the evidence shows it is reliable, checks harder where it is not, and revises both as the evidence changes.

What developers report is mixed, which is itself a reason for a team to look at its own record. In the 2025 Stack Overflow Developer Survey, a self-selected sample of over 49,000 respondents, 46 per cent of respondents said they distrusted the accuracy of AI tools and 33 per cent said they trusted it; the share who highly trusted it was 3.1 per cent, and the lowest share of high trust, about 2.5 per cent (the survey's chart; its text says 2.6), was among experienced developers. Of the respondents, 66 per cent cited "AI solutions that are almost right, but not quite" as a frustration and 45.2 per cent that debugging AI-generated code is more time-consuming (217, Stack Overflow, 2025). The DORA survey of the same year reports that 30 per cent of respondents had little or no trust in AI-generated code, that 90 per cent use AI at work and that more than 80 per cent believe it has increased their productivity (42, Harvey & DeBellis, 2025). Both are surveys of what people say: a population that uses the tools heavily and doubts what they produce. A calibrated team treats them as a prompt to count, not as a conclusion.

Counting needs a place to put the results, and the book's proposal is a trust ledger kept by the team: a short record, reviewed in the retrospective, of where generated changes were accepted, where they were returned, and where a defect was found after merge, grouped by class of work (Chapter 4) and by origin of the change, with the date of each entry. It is not a new artefact family. It is a section of the team's own notes, and the production figures that come from it feed the adoption and value record (AVR-*) of Chapter 20 with the evidence age that Chapter 20 requires. It shows where the assistant earns its place and where it does not, so that the team can set review depth accordingly, and it makes a belief that the tool is reliable in a class of work a claim with evidence, which expires (Chapter 4). It is about the team and about classes of work; it does not rank developers.

Calibration can be helped by design. A field experiment on decision support with 199 participants found that cognitive forcing functions, interventions that make the person think before seeing the AI's recommendation, significantly reduced overreliance compared with simple explanations, that the designs that worked best were rated lowest by participants, and that people with a higher need for cognition benefited more (44, Buçinca et al., 2021). The setting was a decision task and not coding, so the result transfers as a principle: forming one's own view before opening the generated summary is a forcing function, and a team should expect it to feel slower. Seeded errors serve the same end. A tech lead who occasionally plants a known defect in a change under review, with the team's prior agreement, learns whether reviewers are reading, and tells the team the catch rate, not who caught what; AI Threat, Chapter 14, recommended the oversight-quality metric for exactly this purpose, and it is reported at team level (165, Nordqvist, 2026). Both need the team's agreement and, where there are employee representatives, a conversation with them first (Chapter 22), because a drill that is also a test of individuals is something else. Experience is no protection: complacency and automation bias occur in naive and expert users and are not overcome by simple practice (57, Parasuraman & Manzey, 2010), and automation leaves the human the hardest tasks, because the easy ones have been taken (56, Bainbridge, 1983). Review depth therefore follows the class of work and the path the change touches, not the rank of the author.

Speaking up

A defect in generated code, a near miss caught in review, a doubt about whether the tool was permitted to see a file: each is information that the team can use only if someone says it. What decides whether they do is the answer the team gives to the person who spoke. Edmondson defined team psychological safety as a shared belief that the team is safe for interpersonal risk taking, and in a study of 51 work teams in a manufacturing company found it associated with learning behaviour, which in turn related to team performance (50, Edmondson, 1999). Later reviews describe it as people's perception of the consequences of interpersonal risk in a context (143, Edmondson & Lei, 2014) and examined its antecedents and outcomes in a meta-analysis of 136 samples (144, Frazier et al., 2017). The research mostly predates generative AI and measures association. For software, an older tradition gives the same lesson in operational terms. Westrum's typology classifies cultures by how they process information, and the DORA programme presents it in a table in which messengers are punished in a pathological culture, neglected in a bureaucratic one and trained in a generative one, and failure leads to scapegoating, justice or inquiry (70, Westrum, 2004) (71, Google Cloud, n.d.). The programme states that a generative, high-trust culture predicts software delivery and organisational performance. Westrum himself cautioned that the relation between culture and safety needs more exploration, and the programme's claim is an association in its surveys.

An assistant changes what speaking up risks at three points, as AI Leader, Chapter 21, set out (174, Nordqvist, 2026), and each has a concrete form in development.

The record. Prompts, chat transcripts and agent run records are searchable artefacts. A developer who asks the assistant a question that reveals what they do not know leaves a record that others can read. The team's rule is that run records (RUN-*) belong to the change and to the team's learning, and that no leader reads a named developer's prompts for any purpose other than investigating a specific incident, under the arrangement agreed with the employee representatives (Chapter 22). At Nordvik Region the question whether prompts to coding tools are records under the public-access and archives rules is open with the archivist and legal counsel, and until it is answered the gateway records metadata only (Chapter 16).

The count. If the tool reports how much code a developer accepted, how often they used the assistant or how many suggestions they rejected, developers will manage the figure. Bernstein's field experiment at a factory in China found that making workers more observable could reduce performance by inducing concealment (142, Bernstein, 2012). No per-person count goes to a leader, and a team figure is reported only above a minimum group size.

The draft. The assistant can produce the first version of a defect report, a post-incident summary or a retrospective note, and the person who would have written it may feel it is safer to let the draft say less. The person who reports a defect owns the report and may edit the draft freely, and an error found in an assistant's draft is a contribution.

A near miss deserves special mention because generated code produces a particular kind. A coding agent proposed a dependency whose name did not exist in the registry; the package proxy refused it, and a later review of agent runs found that two further names had been proposed and rejected in the previous month and that no one had been told (Chapter 10; FND-HM-2030-0012). The proxy worked; what was missing was the route by which a refused name becomes information. The cure is cheap: a one-line entry in an open log, with the date, the change, what was refused or caught and by what, read at the next retrospective. The log is the team's memory of what almost happened, not an incident register.

The tradition of blameless review gives the form. The site-reliability literature states that a blameless postmortem focuses on contributing causes without indicting any individual or team, assumes that everyone involved had good intentions and did the right thing with the information they had, and rests on the observation that where finger-pointing prevails people will not bring issues to light for fear of punishment (74, Lunney & Lueder, 2017). That is practitioner literature from one company and describes a norm, not a measured effect. It has a boundary. Elish's concept of the moral crumple zone describes how responsibility for an action may be attributed to a human actor who had limited control over an automated system, so that the nearest person absorbs blame for a failure the design produced (49, Elish, 2019). In a development team the person nearest the system is the developer who approved the pull request. Blamelessness protects that person from the misattribution, and it does not remove the stewardship tests: someone is the named owner, and the review of a defect asks what in the mandate, the specification, the oracle or the review made the defect likely, and who changes it. Blameless towards the individual, answerable for the change.

Finally, the stop right. Anyone in the team may hold a merge, pause an agent run or ask for a change to be reverted, on a doubt they can state, without penalty if the doubt turns out to be unfounded. This is the structural answer of AI Operations, Chapter 25 (170, Nordqvist, 2026), and it matches the Revert test. A stop made in good faith is never recorded as a failure.

Safety to ask

The people most exposed to the cost of speaking are those who know least. A junior developer who does not understand a generated function has two ways to find out: ask a colleague, who may think less of them, or ask the assistant, which will not. The second is the easier, and a team in which it is the only safe route loses something that no tool replaces. Seniors lose sight of what juniors do not know, and juniors lose the social route by which a craft is learned (Chapter 13).

The evidence on what the assistant does to learning is early. In a randomised experiment in which developers learned a new asynchronous programming library, reported in a preprint not yet peer reviewed, AI use impaired conceptual understanding, code reading and debugging abilities, and of six interaction patterns identified, three involved cognitive engagement and preserved learning outcomes (67, Shen & Tamkin, 2026). The abstract gives no effect sizes and the full text was not read for this chapter, so the finding is used for its direction only: how the assistant is used matters. A study of high-school mathematics reached a compatible conclusion for a different population (66, Bastani et al., 2025). The conclusions below are the book's own.

First, the team agrees that a question to a person is always acceptable, and that "why does this generated code do that" is a better question than "can you check this". Second, seniors model not knowing: a senior who says "I do not follow this function; let us read it together" gives a junior permission to do the same. Third, a junior's questions are asked in an open channel and answered there, so that the next person finds the answer. Fourth, the junior's learning is assessed from work samples and conversation, not from the assistant's logs, which is the rule of the apprenticeship plan (APR-*, Chapter 13). A wider finding supports the stakes: in a survey of the global workforce, 66 per cent of employees who use AI reported having relied on AI output at work without critically evaluating it and 56 per cent reported having made mistakes in their work because of AI (54, Gillespie et al., 2025). The data are self-reported and from a survey funded by a consultancy.

Shadow AI

Shadow AI, the use of AI that no one in authority decided on, is common among developers, and a team culture shapes whether it is open or hidden. In the 2024 Work Trend Index, a vendor-commissioned survey of about 31,000 knowledge workers in 31 markets, 78 per cent of AI users said they were bringing their own AI tools to work, and 52 per cent of people who use AI at work were reluctant to admit using it for their most important tasks (93, Microsoft, 2024). The global study of trust and attitudes found in its self-reported data that 56 per cent of employees who use AI had done so at work without knowing whether it was allowed, that 57 per cent had used it in non-transparent ways, that 48 to 49 per cent had uploaded company information or copyrighted material to public tools, and that the share who had done so was highest where the organisation had banned generative AI (67 per cent, against 56 per cent where a policy guided use and 33 per cent where there was none) (54, Gillespie et al., 2025). The authors read that as suggesting bans may be ineffective; it is a cross-sectional association, and organisations that ban may be those whose staff most want the tools. The industry survey in IBM's 2025 report on the cost of data breaches, with 600 organisations, found that 63 per cent had no AI governance policies to manage AI or prevent shadow AI, and that a high level of shadow AI added USD 670,000 to the global average breach cost (55, IBM, 2025). It is a self-reported survey with its method only briefly described, so it is used for direction only.

Developers have specific reasons: the approved tool is slower or weaker, no approved route exists for a task, or the rules are not known. Nordvik Region illustrates the last two. The Mode 2 pilot NR-DEV-001 covers 12 of the 18 developers, so six developers have no approved assistant for code, and the framework agreement NR-2025-102 under which about 22 consultants work contained no clause on AI tools. In March 2030 a consultant pasted a connection string for a test database into an unapproved public assistant while asking for help with a SQL view (INC-NR-2030-0071, illustrative). The platform team rotated the credential within 40 minutes and found no access from outside. The cultural fact worth keeping is the speed of the report: someone said what had happened quickly enough for a 40-minute rotation.

The response has four parts, and none of them is surveillance of individuals.

  1. An approved route that does the job, so that the private tool is not needed (Chapters 16 and 18).
  2. A plain rule on what must never be pasted into a tool outside the approved route: credentials, special-category data, personal data of citizens or customers, and the rules of the benefits-triage system. The rule is short enough to remember and is stated with examples.
  3. A conversation before any enforcement. Each team discusses what it already uses and why; the tech lead goes first.
  4. A report route that costs nothing. A developer who has pasted something they should not have reports it to the platform team or the security function and is thanked.

Controls on where traffic may go belong to the platform team and the security function, concern destinations and not individuals, and are agreed with the employee representatives before they are switched on (Chapter 22). None of the four parts needs monitoring of what a named developer types or pastes.

Practical guide: Running a retrospective on AI-assisted work with a safe way to report defects

Purpose. To learn, once a sprint, what the team's use of AI did to the work, and to make the reporting of defects and near misses routine and safe.

Roles. The tech lead or a rotating facilitator runs it; the quality engineer brings the sample of reviews and the escaped defects; the product owner attends for the part on specification. A union delegate has agreed the rules in advance and is not present. The engineering manager does not attend the part on reports.

Inputs. The open log of near misses and defects since the last retrospective; a sample of five to ten merged changes with their review records (RVW-*) and, for agent runs, run records (RUN-*); the trust ledger; the team practice agreement.

Steps.

  1. Open by restating the rule: names are not recorded, nothing said enters an appraisal, and anyone may pause the session.
  2. Read the open log aloud, entry by entry, without asking who made it. Thank the entries' authors collectively.
  3. For each entry ask the five questions of a blameless review: what the assistant or agent was given and produced; what the human did with it and what they could see; what the mandate and specification said; what made it hard to check; and who changes which of these.
  4. Review the sample of merged changes for the class of work and the path, and update the trust ledger: where the tool was reliable, where it was not, and where the team's review caught or missed a defect.
  5. Decide one change to the practice, one owner and a date, and write it into the next sprint.
  6. Close by asking what the team nearly did not say, and allow two minutes of silence before the answers.
  7. Record the entries and the change without names, delete the working notes, and report to the engineering manager only the count of entries, the change decided and the team's trust ledger summary.

Artefact. The updated log and the change to the team practice agreement, kept in the team's repository.

A team practice agreement

A team practice agreement is the written form of the rules above. It fits on one page, every clause can be checked by someone other than its author, and the team adopts it. It is not a delegation profile (DLG-*): it raises no degree of delegation and may only be stricter than the profile. It is identified by the decision record that adopts it and by its place in the team's repository, because the book coins no new identifier family for it. The following is an illustrative agreement for the e-services team of Nordvik Region.

team_practice_agreement:
  status: illustrative
  version: 1.0.0
  team: e-services team, Applications and Integration, Nordvik Region (7 people)
  adopted: 2030-11-26
  decision_record: AIDR-1121
  governed_by: DLG-NR-DEV-01
  functions: [D3 Build, D4 Prove]
  rule: stricter-than-profile-only
  working_with_assistants:
    word_pairing_reserved_for: two people
    intent_stated_before_generation: true
    security_critical_changes: second human reviews the oracle as well as the code
  review:
    author_reads_full_diff_first: true
    disclosure: assistant or agent named in the pull request; run record linked
    ai_comment_counts_as_approval: false
    reviewer_starts_from_own_judgement: true
    may_return_as_too_large_to_review: true
    protected_review_time_per_developer_per_sprint: 4 hours
    seeded_errors: quarterly, announced in advance, catch rate reported for the team only
  trust_ledger:
    kept_by: team
    grouped_by: [class of work, origin of change]
    entry_expires_days: 180
    feeds: AVR-NR-2030-01
  speaking_up:
    open_log: near misses, defects, doubts; one line, no names
    read_at: every retrospective
    stop_right: anyone may hold a merge or pause an agent run; no penalty
    per_person_counts_to_any_leader: never
    prompts_and_run_records: belong to the change; metadata only at the gateway until MBA-NR-2030-03 concludes
  safe_to_ask:
    question_to_a_person_always_acceptable: true
    junior_questions: open channel, answers kept
    learning_assessed_from: work samples and conversation, never tool logs
  shadow_ai:
    never_pasted: [credentials, special-category data, citizens' personal data, benefits-triage rules]
    report_route: platform team, thanked and not disciplined
    team_conversation_held: 2030-12-05
  reviewed_with: Tomas Ekblad (union IT representative) on the clauses touching telemetry
  review_due: 2031-06-02

The agreement contains no clause that a leader could use against a named person, and every clause that touches data about people states its limit.

Across the usage modes

The table gives, for each usage mode, what the team practice has to settle and the highest degree of delegation the two organisations allow today. The Level 4 prohibitions of Chapter 4 apply in every row: no mode reaches Level 4 for a change to production without a gate the change cannot alter, for security-critical or safety-critical code without review by a named developer, for a change to the agent's own mandate, permissions, credentials, test oracles, review rules or pipeline gates, for an irreversible action on production data, or for a decision about a named person's employment, pay, performance rating or access to work.

Usage mode What the team practice has to settle Highest degree allowed (Nordvik Region; Hansa Mutual)
Mode 0 Ambient AI Completion appears without a decision to use it; the author still reads the diff; no acceptance count per person Level 1 Assisted; Level 1 Assisted
Mode 1 Conversational assistants What may be pasted; questions to a person remain acceptable; private accounts are shadow AI Level 1 Assisted; Level 1 Assisted
Mode 2 Embedded workplace assistants Disclosure in the pull request; review depth by class of work; reviewer starts from own judgement Level 1 Assisted for generate, Level 2 Supervised for document; Level 2 Supervised for generate outside the security-critical and payment paths
Mode 3 Agentic work tools Run records, the stop right, a human reviewer for every pull request an agent opens Level 2 Supervised for platform engineers' drafts of infrastructure code, never applied (AIDR-1116); Level 2 Supervised, with one Level 3 Bounded class (patch-level dependency updates)
Mode 4 Built AI applications for developers Test drafts and code explainers: the oracle is written by someone other than the author of the change None built; Level 1 Assisted for test drafts (HM-DEV-002) and Level 0 Advisory for the legacy-code explainer (HM-DEV-003, pilot)
Mode 5 Autonomous production agents No coding agent merges or deploys on its own; the team's stop right applies to any agent that touches its change None; none

Nordvik Region and Hansa Mutual

Nordvik Region's culture is consensus-oriented and cautious, and its agreement was adopted slowly: the e-services team discussed the draft at two retrospectives in November 2030, with the product owner Hanna Wikström asking that the specification precede generation and the quality engineer Saga Edvardsson asking who writes the oracle. The clause on protected review time was the longest argued: the four hours per developer per sprint were agreed on the understanding that Gunilla Roos, who is accountable for use under DLG-NR-DEV-01, would remove other work to fit them. The union's IT representative Tomas Ekblad read the clauses on the log, the counts and the run records before adoption, because the negotiation record MBA-NR-2030-03 on developer tooling and telemetry was open, and the agreement says so. The risk of a consensus culture is an agreement adopted by everyone and kept by no one. It was recorded as AIDR-1121 on 2030-12-02, and its first test is whether the log has entries by the end of the first quarter; an empty log in a team that uses the tools daily is a signal, not a clean record.

Hansa Mutual's culture is fast and metric-driven, and its risk is a practice adopted in a sprint and bent by a dashboard. The claims core delivery team in Hamburg under Stefan Brückner had the 42 per cent figure of the IDE assistant's dashboard in its name, and a sample of 40 merged pull requests in August 2030 had found 27 per cent of lines traceable to an accepted suggestion (AVR-HM-2030-01). The team's practice agreement, recorded as AIDR-1171 on 2030-12-09 and extending the working agreement of 14 October 2030 (Chapter 15), therefore opens with a rule about numbers that governs the culture around them: the share of AI-assisted lines is not a target and is never shown with a developer's name, and any figure the team reports upward carries its method and date. Because the local Betriebsrat in Hamburg had agreed the IDE assistant under an interim arrangement and the annex KBV-IT-2024-DEV-01 was in draft, the agreement states that telemetry is reported by team with a minimum group size of five and that acceptance rates play no part in appraisal or pay (Chapter 22). The Polish and Dutch representatives, informed later than Hamburg's, had asked for the same terms. The team's open log began with the three refused package names of FND-HM-2030-0012, entered retrospectively with their dates, which gave the first retrospective something to read. A short excerpt of the Hansa clauses that differ from Nordvik's shows the shape.

team_practice_agreement:
  status: illustrative
  version: 1.0.0
  team: claims core delivery team, Hamburg (Group Application Development)
  adopted: 2030-12-09
  decision_record: AIDR-1171
  governed_by: DLG-HM-DEV-01
  numbers:
    ai_assisted_share_is_a_target: false
    shown_with_developer_name: never
    figure_reported_upward_carries: [method, sample, date, evidence age]
  review:
    human_approvals_for_critical_functions: 2
    ai_comment_counts_as_approval: false
    oracle_for_a_change_written_by: someone other than the author of the change
  speaking_up:
    open_log_seeded_with: FND-HM-2030-0012 (three refused package names)
    telemetry_reported_by_team_minimum_group_size: 5
    acceptance_rate_in_appraisal_or_pay: never
  works_agreements: [interim agreement of the local Betriebsrat, Hamburg; draft KBV-IT-2024-DEV-01]
  review_due: 2031-06-09

Observable, expected, speculation

It is observable that developers use AI tools widely and say that they doubt the accuracy of what the tools produce, in surveys of self-selected and surveyed professionals (217, Stack Overflow, 2025) (42, Harvey & DeBellis, 2025); that what developers believe about the effect of the tools on their speed can differ from what was measured, in at least one randomised trial with 16 developers (63, Becker et al., 2025); and that many workers bring their own AI tools to work and are reluctant to say so (93, Microsoft, 2024).

It is expected, on the trend of the instruments and the surveys, that team practice agreements of this kind will appear in works agreements and in procurement of development assistants as conditions for use, because the employer's duty to inform workers' representatives before using a high-risk AI system at the workplace (Article 26(7) of the AI Act) (1, European Union, 2024) and national co-determination rules point towards written rules about telemetry. It is expected that Article 5(1)(f) of the AI Act, which prohibits using AI systems to infer emotions of natural persons in the workplace except for medical or safety reasons, will be the first question to put to any supplier of sentiment analytics for developers (1, European Union, 2024).

It is speculation that review will in future be performed mainly by agents with humans sampling, and that teams with a written practice agreement will deliver better than teams without; no study this chapter relies on measures either, and the evidence for psychological safety concerns teams and learning, not agreements as an instrument.

Summary

This chapter concerned D3 Build and D4 Prove: how a team directs and accepts generated code, and how it reviews, tests and reports defects. Working with an assistant is not pairing, because the assistant cannot be named, cannot explain a change a month later and cannot help revert it. The evidence on speed, security and learning is early and mixed, and the finding that recurs is that the feeling of being helped is a poor guide, so the team counts what it can.

Review culture decides whether review finds things: the author reads the diff first, disclosure is routine and has one purpose, the reviewer starts from their own judgement and may return a change as too large to understand, with time protected for it. Trust is calibrated through a trust ledger of outcomes by class of work and origin, with dates, and never ranks a developer. Speaking up depends on what happens to the person who speaks: the record, the count and the draft are rules a named leader sets, the open log gives near misses a route, blameless review protects the person nearest the system without relieving the named owner, and the stop right lets anyone hold a merge or pause an agent without penalty. Juniors need a safe route to ask a person, and shadow AI is met with an approved route, a plain rule on what is never pasted and a conversation before enforcement, never monitoring of named developers.

The team practice agreement writes this down on one page, is stricter than the delegation profile and never looser, and is identified by the decision record that adopts it: AIDR-1121 for Nordvik Region's e-services team and AIDR-1171 for Hansa Mutual's claims core delivery team. The conclusions on practice are the book's own, drawn from the evidence cited. Chapter 22 turns to the developers' representatives and settles what telemetry, prompts and appraisal the works agreements allow.

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. 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. (226, Hannay et al., 2009)
  3. Mozannar, H., Bansal, G., Fourney, A. & Horvitz, E. (2024). Reading Between the Lines: Modeling User Behavior and Costs in AI-Assisted Programming. CHI 2024; arXiv:2210.14306. (211, Mozannar et al., 2024)
  4. Google. The Standard of Code Review. Google Engineering Practices documentation. (212, Google, n.d.)
  5. Westrum, R. (2004). A typology of organisational cultures. BMJ Quality & Safety 13(Suppl 2), ii22-ii27. (70, Westrum, 2004)
  6. Google Cloud, DORA. Capabilities: Generative organizational culture. dora.dev. (71, Google Cloud, n.d.)
  7. IBM (2025). 2025 Cost of a Data Breach Report. Research by the Ponemon Institute. (55, IBM, 2025)
  8. 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)
  9. 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)
  10. Harvey, N. & DeBellis, D. (2025). Announcing the 2025 DORA report: State of AI-assisted Software Development. Google Cloud Blog. (42, Harvey & DeBellis, 2025)
  11. 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)
  12. Lee, J. D. & See, K. A. (2004). Trust in Automation: Designing for Appropriate Reliance. Human Factors 46(1), 50-80. (146, Lee & See, 2004)
  13. Stack Overflow (2025). 2025 Stack Overflow Developer Survey. (217, Stack Overflow, 2025)
  14. 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)
  15. 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)
  16. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6), 775-779. (56, Bainbridge, 1983)
  17. Edmondson, A. (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly 44(2), 350-383. (50, Edmondson, 1999)
  18. Edmondson, A. C. & Lei, Z. (2014). Psychological Safety: The History, Renaissance, and Future of an Interpersonal Construct. Annual Review of Organizational Psychology and Organizational Behavior 1, 23-43. (143, Edmondson & Lei, 2014)
  19. Frazier, M. L., Fainshmidt, S., Klinger, R. L., Pezeshkan, A. & Vracheva, V. (2017). Psychological Safety: A Meta-Analytic Review and Extension. Personnel Psychology 70(1), 113-165. (144, Frazier et al., 2017)
  20. Bernstein, E. S. (2012). The Transparency Paradox: A Role for Privacy in Organizational Learning and Operational Control. Administrative Science Quarterly 57(2), 181-216. (142, Bernstein, 2012)
  21. Lunney, J. & Lueder, S. (2017). Postmortem Culture: Learning from Failure. In Beyer, B. et al. (eds), Site Reliability Engineering. O'Reilly Media and Google. (74, Lunney & Lueder, 2017)
  22. Elish, M. C. (2019). Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction. Engaging Science, Technology, and Society 5, 40-60. (49, Elish, 2019)
  23. Shen, J. H. & Tamkin, A. (2026). How AI Impacts Skill Formation. arXiv:2601.20245 (preprint). (67, Shen & Tamkin, 2026)
  24. Bastani, H. et al. (2025). Generative AI without guardrails can harm learning: Evidence from high school mathematics. PNAS 122(26). (66, Bastani et al., 2025)
  25. Gillespie, N., Lockey, S., Ward, T., Macdade, A. & Hassed, G. (2025). Trust, Attitudes and Use of Artificial Intelligence: A Global Study 2025. The University of Melbourne and KPMG. (54, Gillespie et al., 2025)
  26. Microsoft and LinkedIn (2024). 2024 Work Trend Index Annual Report: AI at Work Is Here. Now Comes the Hard Part. (93, Microsoft, 2024)
  27. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? The Architecture as Code Series, Book 5. (165, Nordqvist, 2026)
  28. Nordqvist, G. (2026). AI Boss: When Artificial Intelligence Manages People. The Architecture as Code Series, Book 7. (167, Nordqvist, 2026)
  29. Nordqvist, G. (2026). AI Purple: How Red and Blue Learn Together When AI Joins the Loop. The Architecture as Code Series, Book 9. (169, Nordqvist, 2026)
  30. Nordqvist, G. (2026). AI Operations: How Artificial Intelligence Transforms IT Operations. The Architecture as Code Series, Book 10. (170, Nordqvist, 2026)
  31. Nordqvist, G. (2026). AI Leader: How Leadership Roles Change When AI Is Used Broadly. The Architecture as Code Series, Book 11. (174, Nordqvist, 2026)