The Developer's Own Mind: Craft, Flow, Cognitive Offloading and Identity

The earlier chapters of Part II asked what a developer must do when AI takes part in building and proving software. This chapter asks what that arrangement does to the developer. It treats the evidence on cognitive offloading, skill formation, complacency and overreliance among people who work with assistants, the experience of flow and craft when the typing goes, the identity of the person who chose the craft, and the ways developers keep their skill in practice. It concerns D3 Build and D4 Prove, because the skill at risk is the one that both functions depend on: the ability to read, debug and judge code that the developer did not type. The stewardship principle of Chapter 4 rests on it. A developer who cannot pass the tests Understand and Revert for a change cannot be its steward, and an oracle written by someone who no longer understands the system is not independent in any useful sense.

The chapter describes effects by population, task and result, says where a study is a preprint, a survey or a small experiment, and does not turn a finding about students or knowledge workers into a statement about developers in general. It ends with a practice plan and two worked examples.

The skill loop: use, offload, practise, verify, with a practice plan read by a chosen partner and no tool telemetry

Figure 28.1: The skill loop. A developer uses an assistant within the mandate, names what is offloaded and what is kept by hand, practises the kept skills without assistance, and verifies them with an unaided work sample. The record is a practice plan read by a chosen partner, never coding-tool telemetry on a named person.

What this chapter builds on

Three earlier volumes treated the same question for other populations, and this chapter takes their conclusions as its starting point. AI Threat, Chapter 6, asked whether people are getting dumber and concluded that the evidence on offloading is conditional, and AI Threat, Chapter 14, treated skills and the ironies of automation, including the loss of the entry rungs by which experts are made (165, Nordqvist, 2026). AI Operations, Chapter 26, applied the argument to the operator's craft and concluded that skills are kept by working a protected share of cases without assistance, because supervision and the degraded mode after a stop need them (170, Nordqvist, 2026). AI Leader, Chapter 28, applied it to the leader's own mind, and its design response was a first view written before the briefing, a dark day with the assistants off and a named partner who reads a dated record (174, Nordqvist, 2026). The present chapter carries that design response over to the developer, with two differences. The developer's unaided skill is measurable in a way a leader's judgement is not, because code can be read, run and reverted. And the developer works with assistants and agents at higher degrees of delegation than most leaders do, so the offloading is more frequent and less visible.

What studies measured

Offloading and skill

Cognitive offloading is the use of action to change the information-processing demands of a task so as to reduce cognitive demand. Risko and Gilbert reviewed research on what triggers it and what its consequences are, and offered a metacognitive framework that integrates findings from several domains (113, Risko & Gilbert, 2016). The definition makes offloading neither good nor bad. Letting completion type a boilerplate constructor is harmless; the question is whether the parts offloaded are the ones the developer must be able to do when the tool is wrong, absent or withdrawn.

Studies from other fields show the shape of the problem. Lisanne Bainbridge argued in 1983 that automating a process leaves the human operator with the tasks the designer could not automate, while the operator's skill in the automated tasks deteriorates from lack of practice, so that the human is least prepared when the automation fails (56, Bainbridge, 1983). That paper is an analysis and not a measurement. Measurements came later. Casner and colleagues asked 16 airline pilots to fly routine and nonroutine scenarios in a Boeing 747-400 simulator while the level of automation varied. They found instrument scanning and manual control skills mostly intact, but more frequent and significant problems when the pilots had to perform the cognitive tasks of manual flight unaided, such as tracking position without a map display or deciding the next navigational step, and those problems were associated with how often the pilots engaged in task-unrelated thought while automation was in use (64, Casner et al., 2014). The result separates two kinds of skill. The hand skill held up. The thinking skill depended on whether the pilot stayed engaged in supervising.

Budzyń and colleagues reported a retrospective, observational study at four centres in Poland. The adenoma detection rate in non-assisted colonoscopy was 28.4 per cent (226 of 795) before the centres introduced AI assistance and 22.4 per cent (145 of 648) after (65, Budzyń et al., 2025). The design cannot show that exposure caused the fall, and the study concerns physicians. It shows that a decline in unaided performance after exposure has been reported in a professional population.

Complacency and overreliance

Parasuraman and Manzey reviewed empirical studies of complacency and automation bias. They concluded that complacency occurs under multiple-task load, when manual tasks compete with the automated task for the operator's attention, and that it occurs in both naive and expert participants and cannot be overcome with simple practice. Automation bias, in which operators make omission and commission errors when decision aids are imperfect, also occurs in experts and cannot be prevented by training or instructions alone (57, Parasuraman & Manzey, 2010). This is the finding that matters most for D4 Prove. A reviewer who sees a plausible pull request while carrying several other tasks is in the condition that the review found to produce complacency, and exhortation to be careful does not remove it. The controls are structural: an oracle written independently of the generator, review budgets, seeded errors, and the right to decline sole approval, which Chapter 14 places in the senior's charter.

Perry and colleagues ran a user study of security-related programming tasks. Their abstract reports that participants with access to an AI assistant wrote significantly less secure code than those without, and were more likely to believe that they had written secure code. Participants who trusted the assistant less and engaged more with their prompts wrote code with fewer vulnerabilities (34, Perry et al., 2023). The abstract does not give the number of participants, and the assistant was an earlier model, so the study is evidence of a mechanism and not of a current rate.

Lee and colleagues surveyed 319 knowledge workers, who shared 936 first-hand examples of using generative AI at work. Higher confidence in the AI was associated with less critical thinking, and higher self-confidence with more. The nature of critical thinking shifted towards verification, integration of responses and stewardship of the task (82, Lee et al., 2025). The data are self-reported and the finding is an association, and the sample was knowledge workers in general. The shift it describes, from producing to verifying and stewarding, is nevertheless close to the shift of the developer role that Chapter 4 defines.

Gerlich reported a mixed-method study of 666 participants across age groups and educational backgrounds, with surveys and interviews. The abstract reports a significant negative correlation between frequent use of AI tools and critical thinking abilities, mediated by increased cognitive offloading, with younger participants showing higher dependence and lower scores (114, Gerlich, 2025). The design is correlational and the participants were not developers. Kosmyna and colleagues, in a preprint, had 54 participants write essays in three conditions (a language model, a search engine, no tools) over three sessions, and 18 of them completed a fourth session in which the conditions were swapped. They reported weaker brain connectivity in the model group, the lowest self-reported ownership of the essays in that group, and difficulty quoting their own work (115, Kosmyna et al., 2025). The sample is small, the task is essay writing and the paper is not peer reviewed.

Developers learning with an assistant

Two studies come closer to the craft. Shen and Tamkin, in a preprint, ran a pre-registered randomised experiment in which 52 participants (26 per condition) completed two coding tasks with a Python asynchronous library they had not used before, in at most 35 minutes. The treatment group could use a chat-based AI assistant, and no participant could use AI during a following quiz of debugging, code-reading and conceptual questions. Participants were recruited through a crowdworking platform and had more than a year of Python experience. The AI group scored 4.15 points lower on a 27-point quiz, which the authors report as a 17 per cent difference or two grade points (Cohen's d = 0.738, p = 0.010), and the difference in completion time was not statistically significant. The largest gap was in debugging questions and the smallest in code reading (67, Shen & Tamkin, 2026). The authors classified the AI group's behaviour into six interaction patterns, and the average quiz scores differed widely between them. Participants who generated code and then asked comprehension questions scored 86 per cent on average, those who mixed code generation with explanation requests 68 per cent, and those who asked only conceptual questions 65 per cent. Participants who delegated all code generation scored 39 per cent, those who began by asking questions and then delegated 35 per cent, and those who relied on the assistant for repeated debugging 24 per cent. The authors note that each pattern cluster is small, and they report that their pilot studies on one platform had substantial non-compliance with the no-AI condition, which is why the main study used another. The result is observable for this task, population and quiz, and it does not show how long the effect lasts or what happens to a developer who works with a codebase for years.

Prather and colleagues observed 21 novice students in lab sessions with participant observation, interviews and eye tracking. Of the 21, 20 completed the programming problem. Students who struggled showed known metacognitive difficulties that the assistant sometimes compounded, and several finished with what the authors call an illusion of competence, while students who did well used the assistant to produce code they already intended to write and ignored unhelpful suggestions (280, Prather et al., 2024). Chapter 13 draws the conclusions for the junior pipeline.

Becker and colleagues ran a randomised trial with 16 experienced open-source developers who completed 246 tasks in mature projects in which they averaged about five years of prior experience. Each task was randomly assigned to allow or disallow early-2025 AI tools. Before the work, the developers predicted that the tools would cut completion time by 24 per cent, and afterwards they estimated a 20 per cent reduction. The measured result was that tasks with AI took 19 per cent longer (63, Becker et al., 2025). The study does not measure skill. It shows that a developer's perception of the tool's effect can differ from the measurement, which is why this chapter does not treat felt fluency as evidence of skill. The authors of the study later reported a follow-up with 57 developers and more than 800 tasks, and stated that selection effects make its estimate very weak evidence. They reported that developers who did not want to work without AI were declining to take part, and that between 30 and 50 per cent of developers withheld some tasks because they did not want to do them without AI (186, METR, 2026). That observation does not measure skill, but it signals that some experienced developers prefer not to work without the tool.

Bastani and colleagues report a field experiment with nearly a thousand high school mathematics students. Access to GPT-4 while solving problems improved performance on those problems (a 48 per cent improvement in grades for the group with a standard chat interface, "GPT Base", and 127 per cent for the group with a tutor-style interface, "GPT Tutor"). When access was taken away, the GPT Base group performed worse than students who never had access, with a 17 per cent reduction in grades, and the safeguards in GPT Tutor largely mitigated the effect (66, Bastani et al., 2025). The figures are those of the abstract of the published article; a correction notice to the paper has been reported, but this review could not locate or read it, so the figures should be checked against the current published text before they are used elsewhere. The finding concerns students of mathematics. Its design lesson is that the same model behind a different interface changed the learning outcome, which makes the interface and its defaults part of the question.

What is established and what is not

Read together, the studies establish a pattern and not a rate. When people let a tool do a cognitive task they spend less effort on it, they remember and later perform less well without it under the conditions studied, and those who trust the tool most examine its output least. The effect depends on how the tool is used. None of the studies followed a cohort of practising developers in an enterprise or a public authority for years, with and without a designed practice, and measured their unaided performance. To the author's knowledge no such study has been published. Whether professional developers' skills decay at a given rate is therefore open as of November 2026, and the response must be cheap, reversible and reviewed against evidence the organisation collects itself.

Flow and craft

Flow is the term Mihaly Csikszentmihalyi gave to the state of absorbed engagement in a task whose challenge matches the person's skill (282, Csikszentmihalyi, 1990). The concept is used here as vocabulary only. The literature on interruptions gives a measured reason to care: in a laboratory experiment with 48 participants, Mark and colleagues studied interrupted work, and their title names the trade they report: more speed and more stress (84, Mark et al., 2008).

What has changed with assistants is where the interruptions and the absorptions fall. Tavantzis, Lambiase and Russo interviewed 21 software engineers across roles and organisations and analysed the accounts by thematic analysis. They identified six dimensions of what they call AI-induced displacement, one of which concerns disruptions to individual focus and cognitive flow (276, Tavantzis et al., 2026). Among the codes in that dimension were giving up the assistant in the middle of a workflow (coded 18 times) and flow disruption through trial and error (17 times). One interviewee, a developer using an agent, described the waiting problem exactly: the agent is working, the developer's attention is no longer wholly on the task, and the question is what to do in the meantime. Another said that the interruption "really breaks the chain of thoughts you have". The study has 21 interviewees and describes the experiences that occur; it does not give their prevalence, and the authors did not compute inter-coder reliability.

A different instrument gives a different picture. The DevOps Research and Assessment (DORA) programme published a post in December 2024 reporting that developers who use generative AI more extensively say they spend more time in a flow state, have higher overall job satisfaction, more productivity and less burnout, and also that they spend less time on work they consider valuable (279, Storer, 2024). The post does not state the survey's sample size, the results are what developers report, and the qualitative component consisted of 10 interviews of about 90 minutes. The two accounts do not contradict each other as measurements, because they sample different people with different instruments. They agree on one point that matters for the craft: the time developers spend on work they value, and the way the work feels, are changing. Whether flow is gained or lost depends on the task, the tool and the team, and neither source fixes the proportions.

Craft pride is the part of the experience that these studies describe in the developers' own words. A senior test engineer quoted at the opening of the interview study said: "I am shipping faster than ever, but I no longer feel like I am really engineering", and added that the code works but does not feel like theirs (276, Tavantzis et al., 2026). The sentence is one person's account, chosen by the authors to open their paper. Its value for a manager is that it names the experience without claiming a rate. A team that treats such a remark as resistance has misread it. It is the developer reporting a weakening of the relation that the stewardship principle needs, since the Name and Understand tests presuppose that the developer feels answerable for the change.

Identity

Schmitt, Gajos and Mokryn carried out a qualitative study of software engineers at one software organisation, with 35 survey respondents and eleven semi-structured interviews, drawing on occupational identity theory and self-determination theory. They report that sense-making depended on expertise: juniors and seniors felt their needs for competence, autonomy and relatedness to be differently affected. Individuals also played an important part in protecting tacit domain knowledge, and the organisation shaped how workers made sense of the technology (277, Schmitt et al., 2024). It is a preprint with one organisation and a small sample. The book's own conclusion from it is that identity work is a normal response to a change in what the role is, differs by seniority and is influenced by the organisation, whether or not it intends to.

The interview study of displacement adds a sharper vocabulary. Its six dimensions concern how engineers justify and adopt AI-generated solutions, shifts in professional identity, tensions with normative and ethical standards, disruptions to cognitive flow, changing dynamics of recognition and collaboration within teams, and the erosion of intrinsic meaning and long-term professional sustainability (276, Tavantzis et al., 2026). Two of these bear on this book's design. Recognition is one: if the team's attention goes to the person who ships the most generated changes, the person who prevents a bad change from reaching production becomes invisible, and Chapter 21 treats the team practice that addresses it. The other is meaning. The authors report that engineers describe the loss of intrinsic meaning as well as skill, and a practice plan that addresses only skill misses half of the finding.

The book's position on identity follows from its thesis. The developer is transformed, not abolished. The identity that the stewardship principle offers is not that of the person who types, and it is not a consolation prize. The steward owns software: knows why it is as it is, can explain a change and can revert it. Those are craft skills, and they are visible in the work in a way that typing speed never was. A developer whose pleasure was in the sentence-by-sentence making of code has lost something real when the typing goes, and an organisation that calls the loss imaginary will not be believed. The honest course is to name it, to protect time for the making that remains, and to give verifying and stewarding the recognition that making used to receive.

Stress, boredom and wellbeing

The evidence here is thin and divided, and the chapter says so. Feng, Afroz and Sarma surveyed 442 developers, analysed the data with partial least squares structural equation modelling and regression, and framed the study with the Job Demands-Resources model. Their abstract reports that adoption of generative AI increases burnout by raising job demands, and that job resources and positive perceptions of generative AI reduce the effect (278, Feng et al., 2026). The study is a preprint. It is cross-sectional, so the authors frame the results as associations, the data are self-reported, and the respondents were recruited from 56 open-source communities, with about 90 per cent men. The DORA post reports the opposite direction for more extensive users: less burnout (279, Storer, 2024). The difference between the two is a difference in sample, measure and design, and the disagreement is unresolved. The defensible statement is that the effect on wellbeing depends on the demands that adoption adds, such as targets, review load and the pace set by generated volume, and on the resources that accompany it, such as time, training and a say in how the tools are used.

The SPACE framework of Forsgren and colleagues gives the measurement stance. It treats satisfaction and wellbeing as one dimension of developer productivity among several, and warns against reducing productivity to a single metric (62, Forsgren et al., 2021). A team that tracks adoption and output but not how the work feels is measuring only part of what the framework says matters.

Boredom needs a plain statement. This chapter found no verified study that measured boredom among professional developers working with coding assistants. The mechanism that Parasuraman and Manzey describe for supervisory tasks, vigilance work with long stretches of monitoring and rare events, suggests that review of generated changes may be tedious and error-prone when volume is high (57, Parasuraman & Manzey, 2010), and it is an expectation of this book, labelled as such, that teams which push review volume up without a budget will see it. It is not an observation.

Three controls follow from the evidence and from the earlier chapters. The first is a review budget and the right to decline sole approval, which Chapter 14 sets in the senior's charter. The second is the practice itself: a protected block of work that the developer does for its own sake, at a pace the tool does not set. The third concerns what an employer may look at. The wellbeing of developers is a matter on which representatives have rights, and the data that would reveal a developer's reliance on the tool, such as acceptance rates and prompt logs on a named person, are the data that Chapter 22 treats as subject to negotiation and co-determination. This chapter's plan therefore excludes them by design.

Keeping skill in practice

Deliberate practice

Ericsson and Harwell restated the original definition of deliberate practice: a form of solitary practice in which individualised instruction helps the learner identify goals and methods for the practice sessions, which the authors distinguish from structured practice defined more loosely (281, Ericsson & Harwell, 2019). They argue that the original definition matters for what can be claimed about the effect of practice. Transferred to development, the point is that practice has a goal and gets feedback. An AI-off day on which a developer does the usual work with the assistant turned off is work without a tool, which may be valuable, and it is not necessarily deliberate practice. A block in which the developer sets out to trace a defect in a module by hand, writes the explanation, and has a colleague check it, is closer.

The software community's own version is the code kata. The CodeKata site argues that in software "we do our practicing on the job", and proposes practice sessions separate from the profession, with time without interruptions, a simple thing to try as many times as it takes, comfort with making mistakes, feedback each time and no pressure (283, CodeKata (n.d.), n.d.). The site is a practitioner's argument and not a study, and the book cites it for the idea and not for any effect.

What to keep by hand

The skills worth protecting are those that the Name, Understand and Revert tests and the independent oracle depend on.

Skill Why it is kept A practice that exercises it
Debugging an unfamiliar failure Largest score gap in the programming experiment (67, Shen & Tamkin, 2026); needed for Revert AI-off block: trace a defect by hand and write the explanation
Reading code one did not write Needed for review and for Understand Weekly reading of a merged change, with a first judgement written before any assistant comment
Explaining why a module is as it is The theory of the program that a steward holds (Chapter 14) Write or update the module's decision note without the assistant
Writing the oracle The independent oracle is a human skill (Chapter 9) Write a test from a specification before the assistant sees the code
Reverting Revert test of the stewardship principle (Chapter 11) A revert drill in the test environment with the assistant off
Designing a small thing from nothing The making that gives the craft its meaning A kata, alone or in a pair

Practices that fit the evidence

The programming experiment points to one practice that costs nothing: when an assistant generates code, ask for the explanation and read it before moving on, and when stuck, ask conceptual questions before asking for code. Those were the patterns that kept the quiz scores high in that experiment (67, Shen & Tamkin, 2026). It is an observation from one small experiment, and the book offers the habit as a design choice, not as a proven remedy. Seeded-error review, in which a colleague plants a defect in a change to see whether the reviewer finds it, tests exactly the complacency that Parasuraman and Manzey describe, and Chapter 9 treats it as a check on review while Chapter 13 gives it a place in the junior's route. A build share, a part of the week in which the developer builds without a review queue, appears in the senior charter of Chapter 14.

Teaching counts as practice: a senior who mentors a junior through an attempt-first exercise, as in Chapter 13, explains the module in front of a person who will ask why. That is the book's inference and not a measured effect.

Nothing in the evidence fixes the right share of AI-off time. A tenth of the week, a fifth, a day a fortnight: each is a design choice that the plan records with its reason and reviews against what the developer's own work samples show. A share that is never reviewed is a ritual.

Practical guide: Agreeing a practice plan with AI-off sessions and code-reading time

Purpose. To give a developer a plan that keeps the skills behind D3 Build and D4 Prove in practice, shows what is offloaded and what is kept, and leaves a dated record that a chosen partner can read and that the employer cannot turn into a measure of the person.

Roles. The developer, who owns the plan; a partner chosen by the developer, usually a peer outside the team or a mentor; the tech lead, who agrees the time; the engineering manager, who protects the time in the plan and does not read the record; the employee representative, who is informed that the plan scheme exists and what its records do not contain; the data protection officer, who confirms the lawful basis and the retention of the record.

Inputs. The delegation profile that applies to the developer (DLG-*); the list of assistants and agents the developer uses and their usage modes; the role charter (ROLE-*); the module or system the developer stewards (OWN-*); the calendar for the next quarter; the agreement with the representatives on developer tooling and telemetry (MBA-NR-2030-03 or KBV-IT-2024-DEV-01, both under negotiation, Chapter 22).

Steps.

  1. List what the developer offloads now and what is kept by hand. Use the work classes of Chapter 4 (specify, design, generate, refactor, test, review, deploy, operate, document, migrate) and be specific: "boilerplate constructors", "first drafts of unit tests", "regular-expression lookups".
  2. Choose the skills to protect from the table above. Start with debugging and with reading unfamiliar code, and add the oracle and the revert drill for anyone who stewards production code.
  3. Set an AI-off block: how long, which assistants are off (completion as well as chat), what work is done by hand and what it produces (a written explanation, a test, a fixed defect). State the stop rule: a production incident that needs the developer, or the developer's own call, ends the block without explanation.
  4. Set code-reading time: how many hours a week, what is read (a merged change, an agent's pull request, a module nobody has touched), and the rule that the first judgement is written down before any assistant comment is opened.
  5. Choose a kata or practice exercise and its interval, and say whether it is done alone or in a pair.
  6. Name the partner and the interval of their meeting. State what the partner reads (the AI-off log, the reading notes, the unaided work sample) and what the partner does not read (completion acceptance rates, prompt logs, appraisal data, the tool telemetry of the developer).
  7. Set the verification: once a quarter, an unaided work sample agreed in advance, such as explaining a module and reverting a change in the test environment.
  8. Fix the reasoned share of AI-off time, the review date, and the expiry of the evidence. A practice record older than 90 days is not evidence that the practice continues; this is the usage default carried over from AI Leader and Chapter 4.
  9. State what the plan will not do: it is not an input to appraisal, pay, ranking or promotion, and it is not shared with the line manager except as a date of completion.

Artefact. A competence record of the family CMP-* of the kind developer-practice-plan, under version control in the repository of the team's working agreements, with a decision record (an AI Decision Record) when the scheme is adopted. The plan is personal data about an employee. Under the General Data Protection Regulation, data must be adequate, relevant and limited to what is necessary (Article 5(1)(c)), and Article 88 lets Member States and collective agreements set more specific rules for employment-context processing (4, European Union, 2016). The architectural implication is to keep the record small and to keep tool telemetry out of it.

Worked example: a quarter for Linnea Sjöberg

Linnea Sjöberg is a senior developer on the case platform team of Nordvik Region, with 17 years in the Region, the keeper of the history of the case-management system SVC-NR-003, a sceptical user of the pilot assistant NR-DEV-001, and the mentor of Emil Nordgren in APR-NR-2030-01 (Chapter 13). On 28 October 2030 the CIO recorded the scheme under AIDR-1137, as an interim arrangement until the negotiation MBA-NR-2030-03 concludes (Chapter 22), after informing the IT representative of the union, Tomas Ekblad. The plan below is illustrative.

# competence/practice-plans/CMP-NR-2030-DEV-P01.yaml (Nordvik Region, illustrative)
id: CMP-NR-2030-DEV-P01
kind: developer-practice-plan
version: "1.0"
holder: {name: Linnea Sjöberg, role: ROLE-NR-DEV-01, team: case platform team}
scheme: {decision: AIDR-1137, adopted: 2030-10-28, status: interim, pending: MBA-NR-2030-03}
period: {from: 2030-11-04, to: 2031-01-31}
offloaded_now: [boilerplate, first drafts of unit tests, lookups of framework syntax]
kept_by_hand: [debugging an unfamiliar failure, explaining why a module is as it is, writing the oracle, reverting]
ai_off:
  block: {hours_per_week: 3, assistants_off: [NR-DEV-001 completion, NR-DEV-001 chat, enterprise assistant]}
  work: "trace one defect a fortnight in the customised case system and write the explanation"
  reason: "design choice; no study fixes the share; reviewed at the end of the period"
  stop_rule: "production incident or the holder's own call; no explanation required"
code_reading:
  hours_per_week: 2
  material: "one merged change a week, written with the assistant, read before any assistant comment"
  first_judgement_written: true
kata: {interval_days: 14, minutes: 60, mode: pair, with: Emil Nordgren, kind: "write the test from the specification first"}
partner:
  name: Maja Lindqvist            # platform team lead, outside the team
  meets_every_days: 28
  reads: [ai_off_log, reading_notes, unaided_work_sample]
  does_not_read: [acceptance_rates, prompt_logs, appraisal_data, tool_telemetry]
verification:
  unaided_work_sample: {due: 2031-01-24, content: "explain the decision module and revert a change in the test environment, assistants off"}
informed: [Tomas Ekblad]          # IT representative of the union
use: "development of the holder only; not an input to appraisal, pay or ranking"
evidence_expires: 2031-05-01      # 90 days after the end of the period
review_by: 2031-01-31

The plan is small on purpose: three hours of AI-off work that produce a written artefact, two hours of reading, a kata with the junior she mentors, a partner who is not her line manager, a work sample at the end, and no pilot telemetry. The sceptic in the team practises in a way that serves the stewardship she already performs.

Worked example: a quarter for Jörg Albers

At Hansa Mutual the developers value speed and ownership, and the plan is built around ownership and the build share. Jörg Albers is a senior developer on the claims portal team (ROLE-HM-DEV-01), the mentor of Aylin Demir in APR-HM-2030-01, and a heavy user of the IDE assistant HM-DEV-001 and of the agent pull requests that the Mode 3 pilot opens through the Hansa Forge gateway. The group CIO recorded the scheme on 11 November 2030 under AIDR-1187, under interim terms until the developer annex KBV-IT-2024-DEV-01 is agreed with the Konzernbetriebsrat, with the local Betriebsrat in Hamburg informed. The plan is illustrative.

# competence/practice-plans/CMP-HM-2030-DEV-P01.yaml (Hansa Mutual, illustrative)
id: CMP-HM-2030-DEV-P01
kind: developer-practice-plan
version: "1.0"
holder: {name: Jörg Albers, role: ROLE-HM-DEV-01, team: claims portal team}
scheme: {decision: AIDR-1187, adopted: 2030-11-11, status: interim, pending: KBV-IT-2024-DEV-01}
period: {from: 2030-11-11, to: 2031-02-07}
kept_by_hand: [debugging an unfamiliar failure, writing the oracle, reverting, reading agent pull requests]
ai_off: {block: {hours_per_week: 4, assistants_off: [HM-DEV-001, Hansa Forge agents]}, work: "own the build of one small component end to end", stop_rule: "incident or own call"}
agent_pull_requests: {read_per_week: 3, first_judgement_written_before_agent_summary: true, seeded_error_review: "one a month, seeded by a colleague outside the team"}
kata: {interval_days: 7, minutes: 45, mode: group, with: "claims portal and Polish service centre developers"}
partner: {name: Ewelina Maj, role: test engineer, reads: [ai_off_log, reading_notes, unaided_work_sample], does_not_read: [acceptance_rates, prompt_logs, tool_telemetry]}
verification: {unaided_work_sample: {due: 2031-01-31, content: "revert one of his own changes in the test environment, assistants off"}}
informed: [Betriebsrat Hamburg]
use: "development of the holder only; not an input to appraisal, pay or ranking"
evidence_expires: 2031-05-08

The plans differ in form and agree in principle: Nordvik's centres on explanation and history, Hansa's on ownership and on a seeded-error review of the reviewer. In both, the partner is not the line manager, telemetry is out and the evidence expires.

Across the usage modes

The usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) differ in how much of the developer's thinking they take and how visibly. The table gives the effect on the developer's mind that the evidence suggests, the highest degree of delegation the two organisations' profiles have allowed (DLG-NR-DEV-01, DLG-HM-DEV-01) for the generate class unless stated, and the practice that answers it. The Level 4 prohibitions apply in every mode: no Level 4 for a change to production without a gate the change cannot alter, for code in a security-critical or safety-critical path without human review by a named developer, for a change to the agent's own mandate, permissions, credentials, test oracles, review rules or pipeline gates, for an irreversible action on production data, or for a decision about a named person's employment, pay, performance rating or access to work.

Usage mode Effect on the developer's mind Highest delegation allowed (generate) Practice that answers it
Mode 0 Ambient AI Offloading without a decision; the developer may not notice what is offloaded Level 1 Assisted at both for completion (accepted line by line at Nordvik) Completion off in the AI-off block; record the default (AIDR-1102)
Mode 1 Conversational assistants Explanations can preserve learning; requests for finished code can displace it Within the profile's generate ceiling; no repository access Ask for explanation before code; conceptual questions first
Mode 2 Embedded workplace assistants Highest volume of small offloads; felt fluency can differ from measured effect Level 1 Assisted at Nordvik; Level 2 Supervised at Hansa outside the security-critical and payment paths First judgement written before the assistant's comment on a read change
Mode 3 Agentic work tools Complacency risk in review; waiting time breaks flow Level 2 Supervised at Hansa (a developer reviews every agent pull request); Level 3 Bounded for patch-level dependency updates (MND-HM-DEV-01); at Nordvik drafting only, never applying Seeded-error review; agent pull requests read before the agent's summary
Mode 4 Built AI applications The oracle can drift towards the generator's view Level 1 Assisted for test drafts (HM-DEV-002) Oracle written by someone other than the author of the change
Mode 5 Autonomous production agents Not in use at either organisation Not delegated Level 4 prohibitions would apply; the revert drill stays

Observable, expected, speculation

Observable. Offloading effects on later unaided performance are documented in other fields (pilots, colonoscopy, school mathematics) and in one small randomised programming experiment, each with stated conditions and populations (64, Casner et al., 2014); (65, Budzyń et al., 2025); (66, Bastani et al., 2025); (67, Shen & Tamkin, 2026). A gap between perceived and measured effect has been shown for experienced open-source developers on early-2025 tools (63, Becker et al., 2025). Developers have described displacement, loss of flow and loss of meaning in interviews (276, Tavantzis et al., 2026). The wellbeing findings are divided.

Expected. Organisations that set no protected practice are expected to find that fewer of their developers can pass the Understand and Revert tests without the tool, because the mechanism is documented in adjacent studies and no one is protecting the skills. Practice schemes with a goal, feedback and a partner who does not appraise are expected to be tried in organisations that have to demonstrate competence, since the stewardship principle calls for evidence of competence, which Chapter 27 treats. Nobody has yet published a measurement of their effect through unaided work samples. This book's labels follow AI Governance, Chapter 22 (162, Nordqvist, 2026).

Speculation. Widespread loss of the ability to read and debug code in the profession is speculation. The studies do not follow practising developers over years, and the effect depends on how the tool is used.

Nordvik Region and Hansa Mutual

Nordvik Region. The Region's developers value public-service purpose, and the plan for Linnea Sjöberg draws on it: her unaided work is the explanation of the case system's decision logic, which serves citizens who depend on the benefits-triage rules, and her mentoring of Emil Nordgren is practice that the Region already values. The scheme is interim under AIDR-1137 until MBA-NR-2030-03 concludes. Under the Swedish Co-determination Act the employer must negotiate with the union before an important change in members' working conditions (section 11) (12, Sveriges riksdag & Regeringskansliet, 1976), and the Region therefore informed the IT representative before adoption and kept telemetry out of the record. Nordvik uses no coding agent beyond the platform team's drafting tools, so the reading practice concerns assistant-written changes in the pilot, and the Region's rule that it has no autonomous production agents stands.

Hansa Mutual. The group's developers value speed and ownership, and the evidence that ownership is thin is concrete: in an audit of August 2030, 14 of 410 services had no active owner (OWN-HM-2030-00), and a COBOL change approved by the one colleague who shared the author's blind spots paid 312 claims twice (INC-HM-2029-0207). The plan for Jörg Albers is built around owning a small component end to end and reading agent pull requests before their summaries. The Konzernbetriebsrat co-determines under section 87(1) no. 6 of the Betriebsverfassungsgesetz on technical devices suited to monitoring the behaviour or performance of employees (9, Germany, n.d.), and a log of AI-off compliance drawn from tool telemetry would be such a device. The plan therefore rests on the developer's own log and on a partner, and KBV-IT-2024-DEV-01 is expected to settle what may be kept. The Polish service centre's representatives and the Dutch works council have asked for the same terms, so the scheme will not carry over unchanged.

Summary

The developer's own mind is part of the system that the stewardship principle relies on. Studies from aviation, medicine, school mathematics, a programming experiment and surveys of knowledge workers show a conditional pattern: offloading reduces effort and later unaided performance under stated conditions, trust in the tool goes with less checking, and the manner of use changes the outcome. No study has followed practising developers over years, so the rate of skill loss is unknown. Flow, craft pride, identity and wellbeing are changing too, on evidence that is qualitative or divided, and the chapter reports it as such. This chapter concerned D3 Build and D4 Prove: what must be kept by hand so that a developer can read, debug, write the oracle and revert.

The response is a practice plan that is small, reasoned and reviewed. It names what is offloaded and what is kept, protects AI-off time that produces a written artefact, sets aside time for reading code the developer did not write, uses a kata or a pair, names a partner who does not appraise, verifies with an unaided work sample, and expires. It excludes tool telemetry on named persons, because that data is subject to the rights of representatives and because a record that can be turned into a score turns practice into performance. Both schemes are interim, under AIDR-1137 and AIDR-1187, pending the agreements that Chapter 22 treats.

The right share of practice is a design choice that the evidence does not fix. The reader can act today: choose one skill that the Understand and Revert tests need, write the plan for one quarter, agree it with a partner and the representatives, and test the skill at the end without the tool. Chapter 29 looks at what may come of the role itself, with the author's own projections labelled as such.

Sources

  1. Risko, E. F. & Gilbert, S. J. (2016). Cognitive Offloading. Trends in Cognitive Sciences 20(9), 676-688. (113, Risko & Gilbert, 2016)
  2. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6), 775-779. (56, Bainbridge, 1983)
  3. Casner, S. M., Geven, R. W., Recker, M. P. & Schooler, J. W. (2014). The Retention of Manual Flying Skills in the Automated Cockpit. Human Factors 56(8), 1506-1516. (64, Casner et al., 2014)
  4. Budzyń, K., Romańczyk, M. et al. (2025). Endoscopist deskilling risk after exposure to artificial intelligence in colonoscopy. The Lancet Gastroenterology & Hepatology 10, 896-903. (65, Budzyń et al., 2025)
  5. 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)
  6. 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)
  7. Lee, H.-P. et al. (2025). The Impact of Generative AI on Critical Thinking. CHI 2025, Article 1121. (82, Lee et al., 2025)
  8. Gerlich, M. (2025). AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking. Societies 15(1), 6. (114, Gerlich, 2025)
  9. Kosmyna, N. et al. (2025). Your Brain on ChatGPT. arXiv:2506.08872 (preprint). (115, Kosmyna et al., 2025)
  10. Shen, J. H. & Tamkin, A. (2026). How AI Impacts Skill Formation. arXiv:2601.20245 (preprint). (67, Shen & Tamkin, 2026)
  11. Prather, J. et al. (2024). The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers. ICER 2024; arXiv:2405.17739. (280, Prather et al., 2024)
  12. Becker, J., Rush, N., Barnes, E. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR; arXiv:2507.09089. (63, Becker et al., 2025)
  13. METR (2026). We are Changing our Developer Productivity Experiment Design. METR blog, 24 February 2026. (186, METR, 2026)
  14. Bastani, H. et al. (2025). Generative AI without guardrails can harm learning: Evidence from high school mathematics. PNAS 122(26), e2422633122. (66, Bastani et al., 2025)
  15. Csikszentmihalyi, M. (1990). Flow: The Psychology of Optimal Experience. Harper & Row. (282, Csikszentmihalyi, 1990)
  16. Mark, G., Gudith, D. & Klocke, U. (2008). The cost of interrupted work: more speed and stress. CHI '08, 107-110. (84, Mark et al., 2008)
  17. Tavantzis, T., Lambiase, S. & Russo, D. (2026). Out of Place in My Own Work: How Generative AI Displaces Software Engineers. ESEM 2026, LIPIcs 394, Article 9. (276, Tavantzis et al., 2026)
  18. Storer, K. M. (2024). Value of development work. DORA, 10 December 2024. (279, Storer, 2024)
  19. Schmitt, A., Gajos, K. Z. & Mokryn, O. (2024). Generative AI in the Software Engineering Domain: Tensions of Occupational Identity and Patterns of Identity Protection. arXiv:2410.03571 (preprint). (277, Schmitt et al., 2024)
  20. Feng, Z., Afroz, S. & Sarma, A. (2026). From Gains to Strains: Modeling Developer Burnout with GenAI Adoption. arXiv:2510.07435 (preprint). (278, Feng et al., 2026)
  21. Forsgren, N. et al. (2021). The SPACE of Developer Productivity. ACM Queue 19(1), 20-48. (62, Forsgren et al., 2021)
  22. Ericsson, K. A. & Harwell, K. W. (2019). Deliberate Practice and Proposed Limits on the Effects of Practice on the Acquisition of Expert Performance. Frontiers in Psychology 10, 2396. (281, Ericsson & Harwell, 2019)
  23. CodeKata (n.d.). CodeKata: How do you get to be a great musician? codekata.com. (283, CodeKata (n.d.), n.d.)
  24. European Parliament and Council of the European Union (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). (4, European Union, 2016)
  25. Federal Republic of Germany (n.d.). Betriebsverfassungsgesetz, section 87. (9, Germany, n.d.)
  26. Sveriges riksdag & Regeringskansliet (1976). Lag (1976:580) om medbestämmande i arbetslivet, 10 to 12 §§. (12, Sveriges riksdag & Regeringskansliet, 1976)
  27. Nordqvist, G. (2026). AI Threat. The Architecture as Code Series, Book 5. (165, Nordqvist, 2026)
  28. Nordqvist, G. (2026). AI Operations. The Architecture as Code Series, Book 10. (170, Nordqvist, 2026)
  29. Nordqvist, G. (2026). AI Leader. The Architecture as Code Series, Book 11. (174, Nordqvist, 2026)
  30. Nordqvist, G. (2026). AI Governance. The Architecture as Code Series, Book 2. (162, Nordqvist, 2026)