What Developers Do: The Gap Described

A person who has built a working tool by conversation with an assistant has done the part of a developer's work that can be seen: the code appears, and it runs. This chapter describes the work that cannot be seen from the code, because that work is the gap between a prototype and software that others can rely on. It concerns all twelve steps, Step 1 Intent to Step 12 Hand over, seen from the professional's side, and all five developer functions of AI Developer, D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward (86, Nordqvist, 2026). It names twelve disciplines, says for each what a professional does, what a builder working by conversation usually has instead and what follows from the difference, and ends in a gap map that the reader can use to score a build. It then says what AI changed (it lowers the cost of every discipline) and what it left (ownership, independence and judgement), and where the edge lies that a builder should not cross alone. Chapter 4 turns the twelve disciplines into the twelve steps of the method.

An iceberg: the generated code above the waterline, the twelve steps below it in three groups, with AI making each cheaper and not supplying the owner or the independent check

Figure 3.1: The visible code and the twelve disciplines beneath it.

Nothing in this chapter says that builders are careless or that developers are the only people who can do the work. The argument is narrower. Each discipline is a habit, each habit can be learnt, and the first thing to learn is that the habits exist. A builder who does not know that a restore test is a thing cannot be blamed for not having done one.

The visible part

Code is the product that others see and the work that people picture when they think of a developer. It is a smaller share of a developer's day than that picture suggests. Meyer and colleagues monitored 20 professional developers at four companies, in Canada, the United States and Switzerland, with a logging application on their computers for an average of 11 full workdays, and collected self-reports of perceived productivity every 60 minutes (128, Meyer et al., 2017). Of the logged time, coding took 21.0 per cent, email 14.5 per cent and work-related web browsing 11.4 per cent. Using the debugger, reviewing others' code and using version control together took 2.4 per cent. Collaborative activities with colleagues, customers or managers took 24.4 per cent. The authors found work highly fragmented, with frequent switches between activities. The sample is small, all on Windows, studied for about two weeks each, with only computer activity captured unless the participant reported otherwise, and it concerns developers working before assistants were common. It does not say that coding is unimportant. It says that, in the logged days of these developers, the typing was a minority of the time.

A second study points to where much of the rest went. Xia and colleagues studied 78 professional developers in seven projects over 3,148 working hours and report that developers spent about 58 per cent of their time on program comprehension activities, with senior developers spending a significantly smaller share than juniors (129, Xia et al., 2018). The figures rest on the published abstract, as reproduced in library catalogue records, and the finding is cited at that level. Comprehension is reading, running and asking questions in order to understand what the software does and why. It is the activity a builder has least chance to do when the assistant has written the code, and it is the activity that every later discipline depends on.

The work beneath

Below the waterline of Figure 3.1 lies work that leaves little trace in the code itself, and which a developer does before, after and around the typing. Before the code, the developer works out what problem is to be solved and for whom, how serious the consequences of failure would be, where the work is to be done and how its history is to be kept, what correct means in examples, and how the software is to be put together. After the code, the developer shows that it works and is safe, releases it by a path that can be undone, watches it run, keeps it owned and, in the end, hands it to someone else or stops it.

None of this is new, and none of it was invented for AI. It is the content of what the profession has learnt over decades of software that failed in production: that a problem misunderstood is solved expensively, that an untested change is a gamble, that a release with no way back turns a mistake into an outage, and that software without an owner decays. AI Developer, Chapter 2, traced how craft, waterfall, agile, DevOps and open source each added a discipline, and what the later volumes of the series call D1 to D5 is the same inheritance in five functions (86, Nordqvist, 2026). Architecture as Code (Chapter 4) records one of the disciplines in miniature, the Architecture Decision Record, a short numbered note kept beside the code that says what was decided, why and with what consequence, so that the reason survives the person who made it (74, Nordqvist, 2025).

A builder working by conversation meets the work beneath the waterline later and in a worse form: as a colleague who cannot run the tool, as a number that nobody can explain, as a restore that fails when it is needed. The twelve disciplines below name the work early, so that it can be done early.

Twelve disciplines

Each discipline is described as a professional practises it, in plain language, with the step of this book that teaches it. The next section sets the twelve side by side.

1. Understanding the problem (Step 1 Intent)

A developer starts by finding out what is wanted and why, from the people who will use the result, before proposing anything. The product is a short statement of purpose, user, present problem, how success will be measured, what done looks like and what the software will not do. The discipline is the habit of asking before building, and its output is an agreement with the user, not code. The cost of skipping it is the cost of building the wrong thing well.

2. Judging the risk (Step 2 Tier)

A developer asks, before choosing a method, how much can go wrong: who will use it, what data it will hold, what harm a failure could do, which law applies and whether it will run without anyone watching. The answer decides how much of the remaining work is needed. The professional habit is proportion, and the professional skill is saying that a build should stop, or go to someone else, when the risk exceeds what the builder can carry.

3. Preparing the workshop (Step 3 Workshop)

Before writing the first line, a developer sets up a place to work in which mistakes can be undone and experiments kept apart from users. Version control keeps every change with its author, date and reason. Separate environments, which are places where the software runs for different purposes (one to try things, one for users), keep trials from reaching people. Secrets, which are passwords, keys and tokens, are kept out of the files. Data used for development is synthetic, meaning invented, so that a mistake cannot expose a real person.

4. Saying what correct means (Step 4 Specification)

A developer writes down what the software must do as examples (given this input, expect this output), together with the cases where it must refuse or fail safely and the things it must never do. The examples are the means of deciding, later, whether the software is right. The discipline separates the person who says what correct means from the machine that produces the code.

5. Deciding the design (Step 5 Design)

A developer chooses the technology, where the data lives, who may read and change it, how it will be reached and how it can be left, and records the decisions. The professional preference is for boring technology, which means what the organisation already runs and knows how to maintain. The output is a short design that another person can read in minutes and the decision records that explain it.

6. Building in small steps (Step 6 Build)

A developer builds in small slices, each of which works, is tested, is kept in the history and can be understood on its own. The developer reads what was produced before accepting it. The habit is as much about being able to go back as about going forward, since a long run of large unreviewed changes cannot be unpicked.

7. Proving it works (Step 7 Prove)

A developer shows that the software is right by something other than the author's say-so. Automated tests, which are small programs that run the software on known cases and compare the result with what is expected, run on every change. The cases that decide correctness come from the specification or from a person who knows the process, and a second person reviews. The discipline is checking by an independent means.

8. Making it safe (Step 8 Secure)

A developer reduces the ways in which the software can be misused or can leak, at a level that matches the risk: no secrets in files, access limited to those who need it, input treated as untrusted, only the data that is needed, logs that do not hold personal data, and dependencies (the packages that other people wrote and that the software uses) checked for existence and upkeep.

9. Releasing it (Step 9 Ship)

A developer releases through a path that is automated and cannot be bypassed, called a pipeline, so that the same tests run every time and the person who made the change is not the only one who can put it in front of users. Each release has a version number and a note of what changed, and the previous version can be restored by following a written note that has been followed once.

10. Running it (Step 10 Run)

A developer watches what was released: whether it ran, whether it failed, what it cost. An alert reaches a person who can act. Backups are restored on purpose to see that they work. A runbook, a one-page set of instructions for telling that the software is healthy, stopping it and finding the person to call, lets a colleague take over at two in the morning.

11. Owning it (Step 11 Own)

A developer keeps the software owned: a named owner and a deputy, documentation that explains what it does and how it is run, updates to dependencies and models on a schedule, review dates, and an end date decided at the start. The discipline is that nothing is left running with nobody answerable for it.

12. Handing it over (Step 12 Hand over)

A developer hands software to someone else so that work can continue without the author: a pack that says where everything is, and a trial in which a colleague, working from the pack alone, runs it, changes it, releases the change and stops and restores it. The professional also knows when to hand a build over, when to promote it to a heavier regime and when to end it.

The gap map

Set side by side, the twelve disciplines show a pattern. Building by conversation (Chapter 2) usually delivers the sixth discipline, in a form that works, and leaves the other eleven to chance. The table gives, for each discipline, what a professional does, what a builder who starts from a first prompt usually has instead, what follows and which step teaches it. The vibe-coding default is a pattern that Chapters 2 and 22 document with evidence and that the builder's own build may or may not show; the builder checks the column against the build, not the other way round.

Discipline Professional practice Vibe-coding default Consequence Step
1 Understanding the problem Intent agreed with the user: purpose, measure, done, non-goals A first prompt that describes a solution Scope drifts; nobody can say when it is finished 1 Intent
2 Judging the risk Five questions, a tier, stop signs Everything is a prototype until it is not A personal script becomes a team's dependency without anyone deciding 2 Tier
3 Preparing the workshop History, environments, secrets out of code, synthetic data, rules for the assistant Files in one folder, one environment, keys in the code No way back; a mistake reaches users; a leaked key 3 Workshop
4 Saying what correct means Specification as examples, failure cases, never-do list, an oracle owner Correctness judged by looking at the output Errors that look plausible pass 4 Specification
5 Deciding the design Boring technology, data and access decided, ADRs Whatever the assistant picked; hosting by accident A tool nobody in the organisation can maintain 5 Design
6 Building in small steps Slices, commit habit, diff read, run record One long conversation and large changes No history to go back to; unreviewed changes 6 Build
7 Proving it works Tests from the spec, independent oracle, review It ran once; it looked right Tests that agree with the code because the assistant wrote both 7 Prove
8 Making it safe Checklist by tier, provenance, minimal data It works, so it is secure Open data stores, missing access control, personal data in logs 8 Secure
9 Releasing it Pipeline, versions, release notes, rollback Copying files over the old ones A mistake cannot be undone 9 Ship
10 Running it Alerts to a person, restore test, runbook, cost limits Nothing until someone complains Failure found by users; a backup that does not restore 10 Run
11 Owning it Owner, deputy, documentation, update and review dates, sunset The builder is the owner by default and then moves on An orphaned tool whose dependencies age 11 Own
12 Handing it over Handover pack and a passed takeover test Only the builder knows The tool stops when the builder is away 12 Hand over

What the evidence shows about the default

The default has been measured in part, and the measures describe the consequence column and not any individual builder. Deng and colleagues collected 9,041 open-source applications built with two AI coding tools, one of them an app builder, audited 200 publicly deployed ones and report 1,186 vulnerabilities, with 91.0 per cent of the audited applications having at least one, 65.77 per cent of the vulnerabilities rated Critical or High, and the problems clustered in broken access control, injection and authentication failures (109, Deng et al., 2026). It is a preprint, not peer reviewed, and its sample is public applications, so it says nothing about internal tools or about builders who follow the steps. Perry and colleagues asked 47 participants to complete five security-related tasks, 33 of them with an assistant; the assisted participants wrote less secure code and were more likely to believe it was secure, and those who trusted the assistant less and engaged more with their prompts produced fewer vulnerabilities (23, Perry et al., 2023). The study is a laboratory experiment on a model of 2022, and its useful finding for this book is the one about belief: confidence is not evidence.

Li and colleagues interviewed 22 members of product teams about vibe coding and report that it follows four stages (ideation, generation, debugging and review), speeds iteration and lowers barriers to participation, and also creates new asymmetries in trust, responsibility and social stigma within teams; participants reported unreliable code, integration problems and over-reliance (104, Li et al., 2025). It is an interview study, not a measurement of rates, and it is the closest the literature comes to the experience of non-developers who build inside organisations. The 2025 Stack Overflow Developer Survey, of over 49,000 self-selected respondents, found that 66 per cent named "AI solutions that are almost right, but not quite" as a frustration and that 45.2 per cent found debugging AI-generated code more time-consuming (127, Stack Overflow, 2025); it reports what developers say, not what a clock measures. The 2025 report of the DevOps Research and Assessment (DORA) programme, from nearly 5,000 technology professionals, reported a positive relationship between AI adoption and delivery throughput and a negative one with delivery stability, with no effect sizes in the announcement (28, Harvey & DeBellis, 2025). These are associations in surveys, and the book's reading is that where output rises faster than the disciplines that surround it, the cost shows later in stability.

What AI changed

AI lowered the cost of every discipline in the list, and it did so unevenly. Generation is the clearest case. Cui and colleagues report randomised field experiments at Microsoft, Accenture and a Fortune 100 company with 4,867 developers, with a pooled 26.08 per cent increase in completed tasks (standard error 10.3 per cent), and results that vary across the experiments (88, Cui et al., 2024). The same economies reach the other disciplines in a way that matters to a builder. An assistant can interview the builder about the problem, draft a specification from the answers, propose a design, write a first set of tests, explain what a change does, draft a runbook and the text of a rollback note, and check a list. Each of these was once a reason that a non-developer could not do the work, because the vocabulary and the labour were out of reach, and each is now a conversation. That is the premise of this book: the twelve disciplines are within a builder's reach for the first time.

The size of the effect is not settled and depends on who is measured. Becker and colleagues ran a randomised trial of early-2025 tools with experienced open-source developers in their own mature repositories and found that the developers took 19 per cent longer with AI while believing they had been 20 per cent faster (36, Becker et al., 2025); the sample was 16 developers. METR's update of 24 February 2026 reports a follow-up with 57 developers, 143 repositories and more than 800 tasks, and states that selection effects (developers declining to work without AI, or withholding tasks) made its data an unreliable signal of the current effect and that the design was being changed (94, METR, 2026). The two results together carry a lesson for a builder that holds whatever the speed-up turns out to be: perceived and measured effects can diverge, so the record of what was checked matters more than the feeling that the work went well.

What AI did not change is the list of what must be supplied from outside the conversation. Three things stand out, and all three are the stewardship principle of AI Developer, Chapter 4 (86, Nordqvist, 2026).

An owner. An assistant produces files; it does not answer for them. Bird and colleagues found, in a study of Windows Vista and Windows 7, that measures of ownership were related to pre-release faults and post-release failures, with one correlation not significant (90, Bird et al., 2011). The study concerns human contributors in two projects of one company. The book's reading is that code with no clear owner is weaker, and that a generator adds volume where nobody is answerable.

Understanding. Naur argued in 1985 that programming is the building of a theory of how the program relates to the world it serves, held by the people who built it and not carried by the text alone (91, Naur, 1985); it is an argument, not a measurement. Shen and Tamkin, in a preprint with 52 participants learning an unfamiliar asynchronous Python library with or without an assistant, report that the assisted group scored 17 per cent lower on a comprehension quiz, with no statistically significant gain in speed, and that three of six observed interaction patterns preserved learning (38, Shen & Tamkin, 2026). It is one task and one library. It suggests that how a builder uses the assistant affects whether the builder can later explain the tool, and that is the point of the explain-it-back drill of Step 11.

Independence. Generating code is cheap, and deciding that it is right is the expensive part. A test has an input and an oracle, the means of deciding whether the result is correct, and Barr and colleagues describe the oracle problem as the difficulty of telling correct behaviour from incorrect (89, Barr et al., 2015). If the assistant writes the code and the tests, a misreading of the rule is in both, and they agree. The check that counts comes from outside the assistant: from the specification, from a person who knows the process, from a reviewer. Judgement, the fourth thing, is the sum of these: knowing what to ask for, what to distrust and when to stop.

The edge

Not every build is a builder's to complete alone, and the twelve disciplines include the discipline of knowing which. AI Developer, Chapter 19, sets four tiers of builds by what can go wrong: A personal, B team, C business and D project (86, Nordqvist, 2026). Chapter 4 restates them in full. For this chapter the point is the line between C and D. A build is Tier D, and is not a citizen build, if it ranks or decides about a named person, is or feeds a high-risk AI system, touches a security-critical path (authentication, authorisation, cryptography, payment, clinical or life-safety logic), or acts irreversibly on production data. These are the conditions under which the Level 4 prohibitions of the series apply, and in each of them the weakness of building by conversation is most costly. A builder cannot judge security-critical code by reading it, cannot be the only check on a decision about a person, and cannot undo an action that cannot be undone.

The edge is not a reproach. A builder who recognises a Tier D idea on the day it appears, writes down what is wanted, and takes it to the development organisation has done the most valuable thing available: the intent and the examples of Steps 1 and 4 are the beginning of the project's specification. The builder's knowledge of the process is the contribution that a developer cannot supply. At Tier C the edge appears in a different form. The tool may be the builder's, but a developer reviews it, and Chapter 16 teaches how a builder works with one as a colleague.

Practical guide: Score your current build against the twelve disciplines

Purpose. To find out which of the twelve disciplines your build already has, with evidence, so that the steps of Part II to Part V can be taken in the order that matters.

Roles. The builder, who scores; a colleague, who reads the score and the evidence; and, if the score reveals a Tier D sign, the builder's manager.

Inputs. The build as it is, including the folder or repository and any conversation history; the gap map above; thirty minutes.

Steps.

  1. Create a file docs/gap-score.yaml in the repository, or a document beside the build if there is no repository yet.
  2. For each of the twelve disciplines write one of three states. Present means that you can open the artefact that shows it. Partly means that something exists but is not enough to show to someone else. Absent means that nothing exists.
  3. For each present or partly, write the evidence: the file, the record or the test result, and its date. A state without evidence counts as absent.
  4. Do not score yourself on intent or good will. Score the artefacts.
  5. Count the states. Mark any discipline whose absence could cause harm to people other than yourself, and read the stop signs of Tier D against the build.
  6. Ask a colleague to read the file and to say, for each present, whether the evidence supports it.

Exit gate. The file exists, every state has evidence or says absent, and a colleague has read it and agrees with each present.

Artefact. docs/gap-score.yaml. The fragment below is Hanna Wikström's score of her first version of service-point-check, which she scored on 2031-09-08 as the first act of her build record; the values are illustrative.

gap_score:
  build: service-point-check
  version_scored: "first version, 2031-09-05"
  scored_by: Hanna Wikström
  scored_on: 2031-09-08
  read_by: Gunilla Roos
  disciplines:
    1_understanding: {state: partly, evidence: "the first prompt, 5 sentences; no measure of success"}
    2_risk:          {state: absent}
    3_workshop:      {state: absent, note: "one file in the team's shared folder; no history"}
    4_correct:       {state: absent}
    5_design:        {state: absent, note: "the assistant's default; export paths fixed to my laptop"}
    6_building:      {state: partly, evidence: "hours_compare_v3.py, about 120 lines, compares hours of portal and phone script"}
    7_proving:       {state: absent, note: "I checked four service points by eye"}
    8_safe:          {state: partly, evidence: "public data only; no secrets used yet"}
    9_releasing:     {state: absent}
    10_running:      {state: absent}
    11_owning:       {state: absent}
    12_handing_over: {state: absent}
  count: {present: 0, partly: 3, absent: 9}
  tier_d_signs: none

Across the usage modes and the degrees of delegation

Across the usage modes

The usage modes of the series differ in which disciplines they help with, and the table says so for a builder. It also states what each mode does not supply. The highest degree of delegation that a builder's assistant may have is set in Chapter 4.

Usage mode Disciplines it helps with What it does not supply
0 Ambient AI Completion while typing in an editor: part of Step 6 Anything that the builder did not ask for and cannot see
1 Conversational assistants Interviewing for intent (1), drafting a specification (4), options for a design (5), drafts of tests (7), explanations of a change, drafts of a runbook (10) and of a rollback note (9) The oracle, the review, the owner; it cannot run anything
2 Embedded workplace assistants Drafting and changing code in the editor (6), test drafts (7), explanations of the diff Independence from the code it just wrote
3 Agentic work tools Running tests and linters, editing on a branch and recording what it did, within a mandate (6, 7, part of 8) The decision to release, access to secrets and production, the gates it must not change
4 Built AI applications Not a help to the build; the tool itself calls a model The assurance that its outputs are right: Tier C at least
5 Autonomous production agents Not applicable to builders The stop path

The Level 4 prohibitions apply to every row: no assistant changes production without a gate that the change cannot alter, edits security-critical code without a named developer's review, changes its own mandate, permissions, credentials, test oracles or pipeline gates, takes an irreversible action on production data, or decides about a named person's employment, pay, performance rating or access to work.

Nordvik Region and Hansa Mutual

The gap map applied to the first version of each build is the starting point of the twelve steps. The details are illustrative and follow the builder profiles of the two organisations.

Hanna Wikström at Nordvik Region had, by 2031-09-05, a first version of the tool that was to become service-point-check: one script, hours_compare_v3.py, of about 120 lines, the third version of the file of Chapter 2, which the assistant wrote from her description, comparing the opening hours of the portal export with those of the phone-service script. It lived on her laptop and ran there by hand, and she passed the list to Elin Berg. She had checked the output for four of the 24 service points by eye. She scored it on 2031-09-08, as above, with no discipline present, three partly and nine absent.

Katarzyna Nowak at Hansa Mutual had, by 2031-09-12, a script of about 90 lines that the assistant wrote from her dictated rules for what a motor property-damage claim must hold. It ran on her workstation against a file of 30 invented claim rows that she had typed, so that, after the episode with the hosted builder in Chapter 2, which she had switched off that day, no real claimant's data was used. It printed a list of missing documents and a request text in Polish. Her score is shown below.

Discipline Hanna's first version Katarzyna's first version
1 Understanding the problem Partly: first prompt, no measure Partly: clear problem and users, no measure
2 Judging the risk Absent Absent: the question of which data had not been asked
3 Preparing the workshop Absent: shared folder, no history Absent: workstation drive
4 Saying what correct means Absent Partly: rules dictated, held in the script
5 Deciding the design Absent: assistant's default Absent
6 Building in small steps Partly: works Partly: works
7 Proving it works Absent: four checked by eye Absent: output read by eye
8 Making it safe Partly: public data only Partly: no real data used, by accident
9 to 12 Releasing, running, owning, handing over Absent Absent

Both builds therefore began with a working tool and an almost empty gap map. The twelve steps of Chapters 5 to 16 fill it in, and Chapter 23 tells in full how that went.

Observable, expected, speculation

Observable. What developers do is documented: in the logged days of the professionals studied, coding was a minority of the time and comprehension a large share (128, Meyer et al., 2017); (129, Xia et al., 2018). That AI lowers the cost of generation is observable in field experiments, with results that vary (88, Cui et al., 2024), and that perceived and measured effects can diverge is observable in a randomised trial and its update (36, Becker et al., 2025); (94, METR, 2026). That applications built by vibe coding show vulnerabilities in public deployments is observable in a preprint (109, Deng et al., 2026).

Expected. That assistants lower the cost of the disciplines beyond generation, such as specification, tests and runbooks, is expected: the interview study points that way and the tools are developing in that direction, but this book has no measurement of the effect for non-developers. That organisations will provide templates that carry some disciplines by default is expected where they have the capacity, and Chapter 17 treats it.

Speculation. That some of the twelve disciplines will disappear because tools do them reliably without a person, is speculation. The conclusion of this chapter is the book's own: whatever tools do, the owner, the independent check and the judgement have to come from outside the generator.

Summary

This chapter described the gap. Code is the visible part of a developer's work and a minority of a developer's logged time, and beneath it lie twelve disciplines: understanding the problem, judging the risk, preparing the workshop, saying what correct means, deciding the design, building in small steps, proving it works, making it safe, releasing it, running it, owning it and handing it over. They are the twelve steps seen from the professional's side, Step 1 Intent to Step 12 Hand over, and the five developer functions D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward stand behind them. Building by conversation usually delivers the sixth discipline and leaves the others to chance, and the gap map sets out for each what follows.

AI lowers the cost of every discipline, so that each is now within a builder's reach; the evidence on size is conditional, and perceived and measured effects can diverge. What AI does not supply is an owner, understanding that survives without the tool, and a check that is independent of the generator. They are the stewardship principle of AI Developer, and they decide the edge: a build that ranks or decides about a person, is or feeds a high-risk AI system, touches a security-critical path or acts irreversibly on production data is Tier D and is not a citizen build.

The practical guide of this chapter, scoring the current build against the twelve disciplines with evidence, gives the reader the picture that the method then fills in. Hanna Wikström and Katarzyna Nowak each began with a working tool, no discipline present and three or four partly. Chapter 4 defines the method in which each discipline becomes a step with a gate and an artefact.

Sources

  1. Meyer, A. N., Barton, L. E., Murphy, G. C., Zimmermann, T. & Fritz, T. (2017). The Work Life of Developers: Activities, Switches and Perceived Productivity. IEEE Transactions on Software Engineering 43(12). (128, Meyer et al., 2017)
  2. Xia, X., Bao, L., Lo, D., Xing, Z., Hassan, A. E. & Li, S. (2018). Measuring Program Comprehension: A Large-Scale Field Study with Professionals. IEEE Transactions on Software Engineering 44(10), 951-976. (129, Xia et al., 2018)
  3. Deng, J., Fan, Z. & Meng, R. (2026). Understanding the (In)Security of Vibe-Coded Applications. arXiv:2606.23130 (preprint). (109, Deng et al., 2026)
  4. Perry, N., Srivastava, M., Kumar, D. & Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? CCS '23; arXiv:2211.03622. (23, Perry et al., 2023)
  5. Li, J., Hou, Y., Lin, L., Zhu, R., Cao, H. & El Ali, A. (2025). Vibe Coding in Product Teams: Reconfiguring AI-Assisted Workflows, Prototyping, and Collaboration. arXiv:2509.10652. (104, Li et al., 2025)
  6. Stack Overflow (2025). 2025 Stack Overflow Developer Survey. (127, Stack Overflow, 2025)
  7. Harvey, N. & DeBellis, D. (2025). Announcing the 2025 DORA Report: State of AI-Assisted Software Development. Google Cloud Blog, 23 September 2025. (28, Harvey & DeBellis, 2025)
  8. Cui, Z. (K.), Demirer, M., Jaffe, S., Musolff, L., Peng, S. & Salz, T. (2024). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. SSRN 4945566. (88, Cui et al., 2024)
  9. 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)
  10. METR (Becker, J., Rush, N., Cunningham, T., Rein, D. & Mahamud, K.) (2026). We are Changing our Developer Productivity Experiment Design. METR blog, 24 February 2026. (94, METR, 2026)
  11. Bird, C., Nagappan, N., Murphy, B., Gall, H. & Devanbu, P. (2011). Don't Touch My Code! Examining the Effects of Ownership on Software Quality. ESEC/FSE '11, 4-14. (90, Bird et al., 2011)
  12. Naur, P. (1985). Programming as Theory Building. Microprocessing and Microprogramming 15(5), 253-261. (91, Naur, 1985)
  13. Shen, J. H. & Tamkin, A. (2026). How AI Impacts Skill Formation. arXiv:2601.20245 (preprint). (38, Shen & Tamkin, 2026)
  14. Barr, E. T., Harman, M., McMinn, P., Shahbaz, M. & Yoo, S. (2015). The Oracle Problem in Software Testing: A Survey. IEEE Transactions on Software Engineering 41(5), 507-525. (89, Barr et al., 2015)
  15. Nordqvist, G. (2025). Architecture as Code. The Transformed Architecture, Book 1. (74, Nordqvist, 2025)
  16. Nordqvist, G. (2026). AI Developer: How the Developer Role Changes When AI Is Used Broadly in European Enterprises and Public Authorities. The Transformed Architecture, Book 12. (86, Nordqvist, 2026)