From Builder to Developer: Learning, Competence and Career

This chapter describes how a builder learns the craft over time: what to learn first, second and third, how competence is shown instead of claimed, how learning with an assistant differs from learning without one, and when a builder becomes a developer and when not. It concerns all twelve steps, Step 1 Intent to Step 12 Hand over, because a builder who keeps following them is practising the habits that make a developer, and it concerns all five developer functions of AI Developer: D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward. Chapters 5 to 16 taught the steps as things to do. This chapter asks what the person who does them must be able to do, alone and without the assistant, and what the organisation owes that person in time, recognition and a route to follow. It ends with two artefacts, a builder learning plan (BLP-*) and a competence record (CMP-*).

The learning path from builder to developer: four rungs, a coach and a dated competence record

Figure 21.1: The learning path from builder to developer. Each rung ends in evidence, and the assistant is switched off for part of each.

A learning path, not a course

A course is a block of time with a content list. A learning path is an order in which a person acquires abilities, each resting on the one before, with a way to tell that the ability exists. The order matters more for a builder than for a trainee developer, because the builder arrives with a working tool and no reading skill, which is the reverse of the usual sequence.

The book proposes four rungs. They are the book's own conclusion, built on the groups of developer competence in AI Developer, Chapter 27, which are: frame and specify; design and system thinking; read, review and verify; delegate and bound; steward; and AI literacy for the role (86, Nordqvist, 2026). The builder's path takes those groups in the order in which the builder's work puts them to the test.

Rung 1: habits. The first things to learn are not programming. They are the habits of Steps 1 to 4 and 7: write down what the tool is for and for whom; decide the tier; keep the history in version control; write the rules that define correct, in a specification, before the assistant generates anything; and have the cases that decide correct written by someone other than the assistant. These are D1 Frame and the first part of D4 Prove. A builder who has only these habits already produces better software than a builder who has none, because the errors that matter most to other people (wrong requirement, exposed data, no way back) are errors of habit and not of syntax. This is a conclusion of the book, and the studies in this chapter do not measure it.

Rung 2: reading. The second thing to learn is to read a change and say, in one's own words, what it does and what it could break. Reading comes before writing for a builder, for a specific reason: the builder is the reviewer of every change the assistant makes, and a review by someone who cannot read is a signature. A builder learns to read by explaining differences between versions (a diff, in the vocabulary of version control, is the list of lines added and removed by a change), starting with changes of a few lines and ending with a change of a whole module. This is D4 Prove and part of D2 Design.

Rung 3: writing and debugging unaided. The third thing to learn is to write a small function and to find a defect by hand, with the assistant off. The aim is not to give up the assistant. It is to have the ability that makes the assistant's output checkable and that the stewardship test Understand needs. This is D3 Build and the debugging part of D4 Prove.

Rung 4: owning. The fourth thing to learn is to carry the duties of D5 Steward: to maintain, to change under a review, to run a restore drill, to hand over, and to know when to stop and call a developer. This is Steps 10 to 12 in practice, and it is where a builder is closest to a developer's role. Ownership is learned by owning something small, with a deputy and a receiving developer who test it.

The path is not a course for three reasons. It has no fixed length, because the builder moves up when the evidence exists and not when the calendar says so. It has no single content, because a builder whose tools never leave Tier A may stay on Rung 1 and 2 for good without harm. And it is a plan the builder makes with a coach and revisits every 90 days, so that it is a living record and not a certificate.

Evidence of competence

A claim that a builder is competent is a claim that needs evidence, as every other claim in this book does. AI Developer, Chapter 27, reached a rule for developers that this book takes over for builders: competence is shown by records of judgement exercised that separate assisted from unaided performance, assessed by a second assessor outside the line, dated, expiring, and limited by purpose and reader because the record is personal data (86, Nordqvist, 2026). Skills frameworks, such as SFIA 9 for digital skills (34, SFIA Foundation, 2024), describe skills by level and are useful as a vocabulary. They do not replace the evidence, which is a work sample.

Four principles shape the competence record for a builder.

Showing, not attending. Attendance at a course is a fact about a calendar. A record of competence says what the person did, under what condition, with what result and on what date. "Explained five of six changes in a 45-minute session with the assistant off" is a record. "Completed the module" is not.

Assisted and unaided are recorded separately. The reason is in the studies below: assisted performance is not evidence of what the person can do without help, and the stewardship test Understand and the test Revert are tests of what the person can do when the assistant is unavailable, wrong or absent. A builder whose assisted record is excellent and whose unaided record is empty has shown that the assistant can do the work, which was never in question.

The assessor is not the coach, and not the line manager. A coach who has taught the skill is the wrong person to certify it, because the coach has a stake in the result. A line manager who decides pay and promotion is the wrong person to see the record, because the record is then a measure of the person in a context of consequences. The second assessor is another developer or quality engineer outside the builder's reporting line.

The record expires. Evidence about unaided performance is a snapshot. This book uses 180 days as an illustrative validity for skill evidence, and 90 days for evidence about a running tool, as conventions and not findings. After the date the entry reads "expired", and a build that depends on the skill (for instance the restore drill) is not covered until the skill is shown again.

Because a competence record is personal data about a named person, its purpose and its readers are limited and agreed with employee representatives before use, in the way AI Boss and AI Leader required for records about people (80, Nordqvist, 2026) (85, Nordqvist, 2026). The plan and the record are not used for pay, rating or discipline, and they are never fed by telemetry on named persons: the assistant's logs record sessions for the run record of the build, not for scoring the builder. A competence record that its subject fears will be read by a line manager is a record that its subject will avoid creating, and then there is no evidence.

Learning with and without the assistant

The assistant can be a tutor, a calculator or a ghost-writer, and the difference decides whether the builder learns. Four studies show how conditional the effect is. Each was made in a setting that differs from a builder's, and the chapter says how.

Shen and Tamkin, in a preprint, ran a pre-registered randomised experiment in which 52 participants, 26 in each condition, completed two coding tasks with an asynchronous Python library that they had not used before. All had more than a year of Python experience. The treatment group could use a chat-based assistant while working, and no participant could use AI during the quiz that followed. The assistant 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 of 0.738), and the difference in completion time was not statistically significant. The largest gap was in debugging questions. The authors identified six patterns of interaction with the assistant, and three of them, which involved more cognitive effort and independent thinking (asking conceptual questions only, asking for explanations together with code, and generating code and then working to understand it), preserved learning (38, Shen & Tamkin, 2026). The study is a preprint, the participants were recruited through a crowdworking platform and were not builders, and each pattern was shown by two to four people, so the patterns are an observation and not a tested remedy. The reading that this book draws is its own: the assistant is not the problem, and a way of using it that keeps the builder doing the thinking is worth designing for.

Bastani and colleagues report a field experiment with nearly 1,000 students at a high school in Turkey, who were given access to one of two assistants for mathematics practice: one that imitates a standard chat interface, and one with prompts designed to protect learning. Access improved performance on the practice problems. When access was removed, the students who had the standard interface performed worse than students who had never had access, and the safeguards in the second assistant largely mitigated the harm. The authors describe the standard use as a crutch during practice (37, Bastani et al., 2025). The subject was school mathematics. The design lesson transfers; the effect size does not.

Prather and colleagues observed 21 novice students in lab sessions with observation, interviews and eye tracking, in an introductory programming setting. They reported a divide between students who accelerated, who used the assistant to produce code they already intended to write and ignored unhelpful suggestions, and students who struggled, whose metacognitive difficulties the assistant could compound, and several of whom finished with what the authors call an illusion of competence (161, Prather et al., 2024). The sample is small and the students were novices in a course. A builder is a novice at the craft and an expert in the domain, which may change the pattern, and no study found for this book measured builders.

Buçinca and colleagues tested, with 199 participants in an AI-assisted decision task that was not programming, designs that force a person to think before seeing the AI's suggestion, called cognitive forcing functions. Those designs reduced overreliance more than simple explanations did, and participants rated the designs that reduced overreliance the most as the least satisfying; the designs helped people with a higher motivation for effortful thinking more than those with a lower one (30, Buçinca et al., 2021). The task was not coding, and the finding that matters here is the trade-off: the practices that protect learning are not the practices people prefer.

Across the four, the pattern is conditional and consistent. What the person did with the assistant mattered more than whether the assistant was there, the benefits showed during assisted work and not afterwards, and the safeguards that worked asked the person to do some of the thinking first. No study found for this book followed practising developers or builders over years, so what happens to skills over a career is unmeasured (AI Developer, Chapter 28) (86, Nordqvist, 2026). AI Threat, Chapter 7, reached the same conditional conclusion for education (78, Nordqvist, 2026).

Four practices follow, and they cost little.

  1. Attempt first. Write the first version of a rule, a test or a short function yourself, with a note of what you expect, before asking the assistant. Compare afterwards. This is the cognitive-forcing idea in a builder's day.
  2. Explain before you accept. When the assistant generates a change, ask it to explain, then explain the change in your own words in the build record or a comment before merging. If you cannot, the change is not yours to ship. This is the Understand test.
  3. Ask conceptual questions before asking for code. The patterns that kept scores high in the experiment began with understanding. This is an observation from one small experiment and the book offers it as a design choice.
  4. Keep an assistant-off block. A fixed part of the week, two hours a fortnight in the plan below, in which the builder reads, traces a defect by hand or writes a small function with the assistant off, and which produces a written artefact and an unaided sample. The block is for the builder's own learning. It is not a test, and it is not reported to a manager.

Offloading and overconfidence

Cognitive offloading is the use of an external tool or action to reduce the mental effort a task needs. It is ordinary and often wise: nobody memorises telephone numbers. It becomes a problem when the effort that is offloaded was the effort that built the ability the person later needs. The studies above measure that condition in different fields, and the chapter's attention is the builder's version of it.

What the studies measured. Lee and colleagues surveyed 319 knowledge workers, who shared 936 first-hand examples of using generative AI at work, and reported that greater confidence in the tool was associated with less critical thinking during the task, and greater confidence in one's own ability with more, and that the nature of critical thinking shifted towards verification, integration of responses and what the authors call task stewardship (42, Lee et al., 2025). The data are self-reported and the workers were not building software. Perry and colleagues, with 47 participants and five security-related programming tasks, found that participants with an assistant wrote less secure code and were more likely to believe they had written secure code; the participants who trusted the assistant less and engaged more with their prompts wrote code with fewer vulnerabilities (23, Perry et al., 2023). Becker and colleagues found, in a trial with 16 experienced developers and 246 tasks, that developers forecast a 24 per cent reduction in completion time, estimated afterwards a 20 per cent reduction and measured a 19 per cent increase (36, Becker et al., 2025). The three studies differ in population, task and method, and none was made on builders. They agree on one thing that a builder can use: a person's sense that the tool is helping is a poor guide to whether it is.

The builder's own mind. Three states matter for a builder. Confidence is useful when it is tied to evidence and harmful when it is not: a builder whose tool has worked for a month is confident and has shown nothing about the day it fails. Overconfidence is confidence that exceeds the evidence, and the studies show that an assistant can raise it. Flow, the absorbed state in which a build moves quickly, is real and pleasant, and a builder in flow reads less. The remedy is not to suppress flow. It is to put a stop in the path: a gate, a test the assistant did not write, a second person's review. The book's gates are a way of making the builder's confidence meet something outside the builder.

Two habits address overconfidence directly. The first is to keep a short list, in the build record, of what has been checked and by whom, with dates, and to treat anything not on the list as unchecked. The second is to seek a second reader early: a deputy who reads the change, or a receiving developer who runs the takeover test. A builder who asks for review before being asked is practising the behaviour of the profession. Psychological safety, the shared belief that one can speak up or ask for help without being punished, is what makes that request possible, and AI Leader, Chapter 21, treats it as a condition of the organisation's (85, Nordqvist, 2026). A builder who is afraid of looking incompetent will hide the very failure the structure exists to catch.

Becoming a developer, or not

Both outcomes are acceptable, and the organisation should say so in writing. A builder who stays a builder is not a failed developer. A builder who becomes a developer is not a promoted builder. The difference is in the role and the duties, and the boundary is a choice to be made with open eyes.

The book's test for the boundary has three parts, and it is its own conclusion.

  1. The work. The person does work that is routinely Tier C, or reviews other people's code, or is a named receiving developer, steward or oracle owner for others' builds. A builder whose own tools are Tier A or B and who asks for review at the boundary is a builder.
  2. The evidence. The competence record shows unaided performance at Rungs 2 and 3, and at Rung 4 for something owned. A person may do developer work with the assistant on and still not be a developer if the unaided record is empty.
  3. The role. There is a role charter (ROLE-*) that says so, a manager who has agreed the move, and a development path with a coach. This is a decision of the organisation and the person, recorded, and it carries the duties of a developer, including the duty to be reviewed.

The edge is a choice, and the choice has costs on both sides. A builder who becomes a developer gains scope and loses the domain role: the product owner who becomes a developer is no longer the person who knows the service. A builder who stays in the domain role can build for years at Tier A and B and call a developer at the boundary, which is the book's recommendation for most builders. An organisation that pushes builders towards developer roles to fill vacancies does something different: it uses the lane to recruit, which is a decision about the organisation and not a consequence of the technology.

There is a second way into developer roles, which the organisation must keep open. AI Developer, Chapter 29, labels the pipeline of developers as an open question, with lower hiring of the youngest in exposed occupations observed in some data and the consequences expected (86, Nordqvist, 2026). The builder route is one candidate for a new first rung: a person who has built tools in a domain, who has been coached and who has an evidenced record can enter development with something that a graduate may lack, which is an understanding of the user's work. Whether it works is speculation. The register of builders, the coaching records and the number of builders who take up developer roles are the data that would show it.

The developer as coach

A builder cannot learn the craft from an assistant alone and should not have to. The developer is the person who has the craft, and coaching is part of the arrangement that makes the lane work, not a favour.

The coach's work has four parts. Review: reading the builder's changes at the boundary and saying why they pass or fail, with reasons the builder can use. Teaching by example: working through a defect with the builder, assistant off, so that the builder sees how a developer reads a failure. Receiving: taking a build at promotion, running the takeover test and stating what failed. Boundary-keeping: saying, early and without contempt, when a build has become something that needs a project.

The coach needs three things. Time: the review and receiving time is work, planned and visible; a coach with no allocated hours will coach in the evenings or not at all, and the lane then fails quietly. Recognition: coaching appears in the coach's role and in the assessment of the coach's work, which is the organisation's decision (AI Leader, Chapter 11, treats coaching as a relationship between named people and not a function that a tool can take over) (85, Nordqvist, 2026). Permission to say no: a coach who may not decline a Tier C build that is not ready is not a gate.

The coach is also a learner. Reviewing generated code taught by builders' questions is a form of practice, and the coach's own unaided record is part of the same evidence regime. Coaching is not a one-way service.

Putting the plan in writing

Practical guide: A builder learning plan

Purpose. To make the builder's learning a plan with an order, a coach and evidence, and to produce a competence record that shows what the builder can do unaided, without turning either into an instrument of control.

Roles. The builder owns the plan. The coach (a receiving developer or another developer) teaches and reviews. The second assessor, outside the builder's line, marks the unaided work samples. The line manager agrees the time and sees only the decision on which tier of build the builder may own. Employee representatives have seen the fields and the limits on readers.

Inputs. The build record (BLD-*) and the tier; the four rungs of this chapter; the six competence groups of AI Developer, Chapter 27, as a checklist; the time agreed for learning and for the assistant-off block.

Steps.

  1. Write the plan's purpose, its readers and what it is not used for. Pay, rating, discipline and telemetry on named persons are excluded in writing.
  2. Name the coach and the second assessor. They must be different people, and neither is the builder's line manager.
  3. Place the builder on the four rungs by evidence, not by self-assessment. Mark each rung met, in progress or planned.
  4. For each rung that is not met, write the evidence that would show it: a specification approved by someone else (Rung 1), a weekly explanation of a change with the assistant off (Rung 2), an unaided work sample (Rung 3), a restore drill led by the deputy (Rung 4).
  5. Set the assistant-off block: its length, its rhythm and its output (a written artefact and an unaided sample).
  6. Set the review interval, 90 days in this book, and the stop sign: the boundary at which the builder calls a developer.
  7. After each assessed sample, write a competence record entry with the condition (assisted or unaided), the evidence, the result and the date, and the date on which it expires.
  8. At each review, read the expired entries first, then the open rungs, and decide whether the tier of build the builder may own changes.

Gate. The plan is in the build's repository or the organisation's records, with a named coach and a different second assessor, the readers are listed, the next review has a date, and at least one unaided entry exists in the competence record.

Artefact. BLP-* and CMP-*, below.

# BLP-NR-2031-01: builder learning plan (Nordvik Region, illustrative)
id: BLP-NR-2031-01
builder: Hanna Wikström            # product owner, e-services
build: BLD-NR-2031-0001            # service-point-check
opened: 2031-11-03
review_every_days: 90
next_review: 2032-02-01
coach: Rasmus Holm                 # receiving developer
second_assessor: Saga Edvardsson   # quality engineer, outside the builder's line
ai_off_block: {hours_per_fortnight: 2, produces: a written artefact and an unaided sample}
purpose: decide the next thing to learn and the tier of build the builder may own
shared_with: [builder, coach, second_assessor]
not_used_for: [pay, rating, discipline, tool telemetry on named persons]
steps:
  - order: 1
    learn: habits (intent, tier, specification, tests the assistant did not write)
    evidence: SPC-NR-2031-0001 approved by someone else
    status: met
  - order: 2
    learn: read a change and explain it in own words
    evidence: weekly diff explanation, assistant off, marked by the coach
    status: in_progress
  - order: 3
    learn: write and debug a small function unaided
    evidence: unaided work sample, marked by the second assessor
    status: planned
stop_sign: personal data of people outside the team, money, or a second unit

# CMP-NR-2031-01: competence record (Nordvik Region, illustrative)
id: CMP-NR-2031-01
person: Hanna Wikström
role: builder, Tier B and C (service-point-check)
recorded: 2031-12-19
assessor: Saga Edvardsson          # second assessor, outside the line
valid_days: 180                    # evidence about unaided performance
entries:
  - skill: frame and specify
    condition: assisted
    evidence: SPC-NR-2031-0001, rules R1 to R3 and the never-do rule
    result: met
    date: 2031-10-15
  - skill: explain a change
    condition: unaided
    evidence: 45-minute session on a six-change pull request
    result: explained 5 of 6; missed the change to date handling
    date: 2031-12-19
  - skill: revert
    condition: unaided, with the runbook
    evidence: RST-NR-2031-0001, drill led by the deputy
    result: pass after the rollback note was corrected on 2031-12-12
    date: 2031-12-19
reader_limits: [builder, coach, second_assessor]

A short check keeps the plan honest. It fails if the assessor is the coach, if the plan does not say what it is not used for, and it reports when a review is overdue. Save it as plancheck.py and run python3 plancheck.py blp.yaml 2031-12-19; with a date after 2032-02-01 it reports the review as overdue.

# plancheck.py: check a builder learning plan (PyYAML, Python 3.12)
import sys, datetime as dt, yaml

plan = yaml.safe_load(open(sys.argv[1]))
today = dt.date.fromisoformat(sys.argv[2])
assert plan["second_assessor"] != plan["coach"], "assessor must differ from coach"
assert "pay" in plan["not_used_for"], "the plan must say what it is not used for"
if today > plan["next_review"]:
    print("OVERDUE: review of", plan["id"], "was due", plan["next_review"])
else:
    print(plan["id"], "ok; next review", plan["next_review"])
for step in plan["steps"]:
    print(step["order"], step["status"], "-", step["learn"])

Across the degrees of delegation

The learning path interacts with the degrees of delegation of the builder's assistant.

Degree of delegation What the builder does What the builder learns What the plan requires
Level 0 Advisory Asks the assistant questions and writes the code Reading and writing, with conceptual help Attempt first; explain before accepting
Level 1 Assisted Accepts suggestions line by line in the editor Reading, by judging each suggestion Explain a change weekly, assistant off
Level 2 Supervised Reviews a change the assistant made on a branch Reviewing, which is Rung 2 at its hardest An unaided review sample, marked by the coach
Level 3 Bounded Hands a defined task to the assistant inside a sandbox Delegating and bounding, with the mandate as the artefact A run record per session; an oracle written by someone else
Level 4 Autonomous Not used for the actions the Level 4 prohibitions list Not applicable Any build that would need it is Tier D

A builder who spends all working time at Level 3 learns to delegate and not to read, and the assistant-off block is the counterweight. The block is smaller than the work done at Level 3 and exists so that the builder can still judge it.

Nordvik Region and Hansa Mutual

Nordvik Region. Hanna Wikström's plan, BLP-NR-2031-01, is part of her role in the e-services team and was opened on 2031-11-03, four weeks after the builder workspace (AIDR-1200). Her coach is the receiving developer Rasmus Holm, and her second assessor is the quality engineer Saga Edvardsson, who is outside Hanna's line and who wrote the oracle cases for the build, so that she knows what the build is meant to do and did not write it. The competence record CMP-NR-2031-01 of 2031-12-19 shows the three kinds of entry: an assisted entry (the specification), an unaided entry that is not a pass (five of six changes explained, one missed) and an unaided entry (the restore drill) that passed only after the rollback note was corrected. Her line manager, Gunilla Roos, sees the decision on the tier of build Hanna may own and not the entries. The union representative for IT staff, Tomas Ekblad, was shown the fields and the reader limits under MBA-NR-2030-03. Hanna remains a product owner: the plan sets her at Rung 2 with Rung 4 for her own tool, and the Region has not asked her to become a developer.

Hansa Mutual. Katarzyna Nowak's plan, BLP-HM-2031-01, is part of a claims analytics development path in the Polish service centre, agreed with her manager, Joanna Kaczmarek. Her coach is the receiving developer Tomasz Wrona. The second assessor is a developer from Group Application Development who is not the coach, and her deputy, Marek Zieliński, who wrote the oracle cases, reads the plan for the build and not the competence record. Her assistant-off block is two hours a fortnight in the claims analytics workspace, where the builder lane (AIDR-1250) provides the assistant at Level 3 Bounded within the mandate MND-HM-BLD-2031-01. The plan and the record are handled under the group's works agreement for IT systems (KBV-IT-2024-DE) and the interim Betriebsrat agreement, and they are not used for rating or pay. Her path leads towards a data analyst's role in claims operations, not towards the development organisation.

The two plans share a limit. In both, the coach's time is the scarce resource, and neither organisation has yet measured what a plan costs in coach hours per builder, which is Question Q29 of the book's foundations.

Observable, expected, speculation

Every statement about the future in this chapter carries one of the three labels of AI Governance, Chapter 22 (75, Nordqvist, 2026).

Observable. The effect of an assistant on later unaided performance depends on how it is used, shown in a randomised programming experiment, a school mathematics field experiment and a lab study of novices, each with a stated and narrow population (38, Shen & Tamkin, 2026) (37, Bastani et al., 2025) (161, Prather et al., 2024). Confidence in an assistant is associated with less critical thinking in self-reports, and with less secure code and more belief in its security in one user study (42, Lee et al., 2025) (23, Perry et al., 2023). Perceived and measured effects have diverged for experienced developers (36, Becker et al., 2025). The evidence on offloading is observable and limited. No study found followed builders or practising developers over years.

Expected. Organisations that give builders a lane will ask for evidence of what builders can do unaided, because the tests Name, Understand and Revert are tests of the unaided person, and because the duty on deployers of high-risk AI systems to assign human oversight to persons with the necessary competence, training and authority will point the same way (AI Act Article 26(2)) (1, European Union, 2024). Career effects follow: builders with evidence records will have a route to roles that require them. This is an inference from a stated duty and a stated trend and not a measurement.

Speculation. That the builder route becomes a significant way into development roles is plausible and unevidenced. That assistant-off practice keeps skills over a career is plausible, supported by the studies' conditional pattern and untested over years. Both are placed in the author's horizon for Chapter 25.

Summary

This chapter concerned all twelve steps and the developer functions D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward. A builder's learning path has four rungs, habits, reading, writing and debugging unaided, and owning, and it is a plan with an order and evidence, not a course. Competence is shown by records of judgement exercised, with assisted and unaided performance kept apart, marked by a second assessor outside the line, dated, expiring and limited by purpose and reader, because the record is personal data.

The studies on learning with assistants point one way: the effect depends on how the assistant is used, benefits show during assisted work and not afterwards, and the safeguards that worked asked the person to do some of the thinking first. The practices that follow are attempt first, explain before accepting, ask conceptual questions before asking for code and keep an assistant-off block. Confidence and flow are real, and the builder's gates, tests the assistant did not write and early review put them in contact with evidence. A builder becomes a developer when the work, the evidence and the role charter agree; staying a builder is equally valid. The developer is the coach, and coaching needs time, recognition and permission to say no.

The artefacts are the builder learning plan and the competence record. Both are checked by script, and both are limited by purpose and readers. Chapter 22 turns to the failures and anti-patterns that arise when these habits are missing, and Chapter 25 returns to the projections about the builder route into development.

Sources

  1. European Parliament and Council of the European Union. (2024). 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. Perry, N., Srivastava, M., Kumar, D. & Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? ACM CCS '23; arXiv:2211.03622. (23, Perry et al., 2023)
  3. 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). (30, Buçinca et al., 2021)
  4. SFIA Foundation. (2024). SFIA 9: the global skills and competency framework for the digital world. (34, SFIA Foundation, 2024)
  5. Becker, J., Rush, N., Barnes, E. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. (36, Becker et al., 2025)
  6. Bastani, H. et al. (2025). Generative AI without guardrails can harm learning: Evidence from high school mathematics. PNAS 122(26), e2422633122. (37, Bastani et al., 2025)
  7. Shen, J. H. & Tamkin, A. (2026). How AI Impacts Skill Formation. arXiv:2601.20245 (preprint). (38, Shen & Tamkin, 2026)
  8. Lee, H.-P. et al. (2025). The Impact of Generative AI on Critical Thinking. CHI 2025, Article 1121. (42, Lee et al., 2025)
  9. Nordqvist, G. (2026). AI Governance. The Transformed Architecture, Book 2. (75, Nordqvist, 2026)
  10. Nordqvist, G. (2026). AI Threat. The Transformed Architecture, Book 5. (78, Nordqvist, 2026)
  11. Nordqvist, G. (2026). AI Boss. The Transformed Architecture, Book 7. (80, Nordqvist, 2026)
  12. Nordqvist, G. (2026). AI Leader. The Transformed Architecture, Book 11. (85, Nordqvist, 2026)
  13. Prather, J. et al. (2024). The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers. ICER 2024; arXiv:2405.17739. (161, Prather et al., 2024)
  14. Nordqvist, G. (2026). AI Developer. The Transformed Architecture, Book 12. (86, Nordqvist, 2026)