Nordvik Region and Hansa Mutual: Conclusions for Two Organisations
Chapter 23 told the two builds as they happened, from September to December 2031. This chapter turns them into decisions. It concerns all twelve steps, from Step 1 Intent to Step 12 Hand over, and the five developer functions behind them (D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward). It states what each organisation should conclude, sets a 90-day plan for three groups of people (the builder, the platform team and the leaders), lists the decisions that only leaders can take, defines the measures by which the book's own claims can be checked, and names the risks and the habits each organisation should stop.
Every conclusion in this chapter is the book's own. It follows from the method of Chapter 4 and from the two builds, which are illustrative: Nordvik Region and Hansa Mutual are fictional, and what happened to Hanna Wikström and Katarzyna Nowak shows that the method is workable and consistent, not that it works in general. Where the chapter says what will happen in the next 90 days, the statement is a plan and carries the label expected: it rests on the plan being followed and on the evidence named, and nothing in it has been observed. The book's wider projections are kept to Chapter 20 and Chapter 25.
Figure 24.1: The three lanes of the 90-day plan. The builder closes open gates, the platform team provides and measures, the leaders decide and protect time. The lanes meet in one review.
What the two builds showed
Two builds are a small sample, and the honest summary starts with what they cannot show. They cannot show that the twelve steps cause better software, because neither build has a comparison build made without the steps. The measures that exist are before-and-after counts without a control group, and the book has labelled them as such: the phone service logged 41 calls about wrong opening hours in August 2031 and 17 in January 2032, and the median time from registration to a complete file in the Hansa Mutual pilot team went from 6.8 days (September 2031, 212 claims) to 5.1 days (December 2031, 198 claims). Other things changed in both periods, and neither figure is an effect of the tool alone.
What the builds can show is narrower and still useful. First, a non-developer can produce, with an assistant at their side, every artefact the twelve steps ask for, in about three months and alongside a day job. The build record, the specification, the mandate, the ownership record, the runbook and the handover pack all exist, and each is in the repository where a colleague can read it. Second, the gates do catch things. In the Nordvik Region build, the Revert test at Step 9 Ship failed: the rollback note named a version tag where the organisation's scheduled-job template needs the release name. Rasmus Holm found it in the takeover test on 11 December 2031 and Hanna fixed it the next day. In the Hansa Mutual build, the independent oracle at Step 7 Prove found what the assistant's own tests had missed: the assistant had copied the rule for motor_collision into motor_glass, so glass claims were being asked for an accident report. Marek Zieliński's oracle case glass-03 failed, and the error was fixed on 10 November 2031, before the first release. Third, the two builds differ in ways that matter for planning: one began at Tier B and moved to Tier C when it started to run on a schedule, the other was Tier C from the first day.
From these three points follow the conclusions of this chapter. They are the book's own, and the rest of the chapter applies them to each organisation in turn.
Nordvik Region
Conclusions
The Region has one builder, one build and one receiving developer, and each of the three is a single point of dependence. Hanna Wikström owns service-point-check (OWN-NR-2031-0001, deputy Elin Berg, sunset 31 August 2033). Rasmus Holm, a developer in Anders Falk's integration and data team, ran the takeover test. The platform team under Maja Lindqvist, with the senior platform engineer Joakim Wester, opened the builder workspace on 6 October 2031 (AIDR-1200). The promotion to Tier C was approved on 15 December 2031 (AIDR-1203). The conclusion for the Region is that the sanctioned route now exists and works for one build, and that the next 90 days decide whether it becomes a route for many or remains an exception that depends on three named people.
The second conclusion concerns proportion. service-point-check is a good Tier C build because it only reads and reports: it never writes to the portal, the phone script or the notices spreadsheet. That never-do rule in docs/specification.yaml is what keeps the build away from Tier D, and it is the first thing a leader should protect when a second request arrives, such as a wish to let the tool correct the portal itself. A tool that writes to the citizen portal changes what can go wrong, and the five questions of Step 2 Tier must be asked again, in writing, before the change and not after it.
The third conclusion concerns the measure. The count of calls about wrong opening hours fell from 41 to 17, which is the figure the e-services team will want to quote. The Region should quote it with its limits (one category, counted by the phone service, one month on schedule, no control) and should keep measuring until there are at least several months of figures. The Region is a public authority, accountable to elected politicians and to the public, and a claim made in its name has to survive a question from an auditor.
The 90 days
The plan starts on Monday 2 February 2032, after the January count is in, and ends with a review on Friday 30 April 2032 (day 89 of 90).
| Who | Weeks 1 to 4 | Weeks 5 to 9 | Weeks 10 to 13 |
|---|---|---|---|
| Hanna Wikström and Elin Berg (builder, deputy) | Close any open item in BLD-NR-2031-0001; Elin runs the weekly report once without Hanna; both read the first 90-day review of OWN-NR-2031-0001, due 1 March, in the week before (26 February) |
Ask Saga Edvardsson to add oracle cases from the notices of the new quarter; run a restore test and record it as RST-NR-2032-0001 |
Explain-it-back drill with Elin as the explainer; update the handover pack; propose the sunset review for 2033 |
| Platform team (Maja Lindqvist, Joakim Wester) | Publish the register entry for the build and a repository template with AGENTS.md, pipeline.yml, tests and an ownership skeleton |
Take a second build into the workspace only after its Tier decision is recorded; fix the template where the rollback note failed | Measure the provision (see KPIs); report to Gunilla Roos and Henrik Dahl |
| Leaders (Gunilla Roos, Henrik Dahl) | Decide the points below | Protect Rasmus Holm's time for takeover tests; keep Tier D requests out of the lane | Read the KPIs with their evidence age |
Decisions needed from leaders
Gunilla Roos, head of Applications and Integration, and Henrik Dahl, Head of IT and Digitalisation and CIO, need to take four decisions. Each should be recorded as an AI Decision Record when it is taken; this chapter does not assign the numbers.
- Name the receiving developers. One developer (Rasmus Holm) is a single point of dependence. Name at least two in Applications and Integration, and say in their role descriptions that receiving a build is part of the job and counts as work, not as a favour.
- Fund the workspace as a service. The builder workspace (the approved assistant, synthetic data, the secrets store, the scheduled-job template) runs on the time of a seven-person platform team. Decide whether it has a named owner and an allowance of time, because a service that depends on goodwill stops when the team is busy.
- Set the rule for a second builder. Decide who may enter the workspace, who records their tier decision, and who may say no. The answer should name a role, not a person.
- Say what the register is for. The register of builds is a tool for support and for review dates. It is not a tool to rank builders or to assess their performance, and the representation arrangements of the Region (the union representative for IT staff, Tomas Ekblad, and the negotiation record
MBA-NR-2030-03) should be told so in writing before the register grows.
What Nordvik Region should stop doing
The Region should stop three habits. First, it should stop reporting the fall from 41 to 17 calls as the effect of the tool without its limits. Second, it should stop reviewing builder work in conversations that leave no record, because a review that leaves no RVW-* record cannot be shown to an auditor and cannot be repeated by a deputy. Third, it should stop treating the 2030 sweep of 60 applications on FormFlow (31 Tier A, 18 Tier B, 11 Tier C) as a finished piece of work: a sweep is a snapshot, and the register has to replace it.
Hansa Mutual
Conclusions
The group has more capacity than the Region and more exposure. Katarzyna Nowak, team lead of a motor claims team in the Polish service centre, owns claims-doc-check (OWN-HM-2031-0001, deputy Marek Zieliński, sunset 31 August 2033). The tool handles claimant personal data, so it has been Tier C from the start, and the group data protection officer, Dr. Sabine Vogel, screened it on 20 October 2031, narrowed its scope to property-damage claims and recorded the decision (AIDR-1251). The builder lane opened on 13 October 2031 (AIDR-1250), the mandate was adopted on 27 October (AIDR-1252), and Tomasz Wrona, the Polish receiving developer, ran the takeover test on 9 December 2031 with a pass and two remarks.
The first conclusion is that the group should resist the pull of scale. The pilot team had 198 claims in December. The tool will be asked for in other teams and other markets, and each of them has its own language, its own claim types and its own supervisor. The templates for pl, de and en exist; a new country is a new specification and a new oracle, and it needs its own receiving developer, as the lane already provides for each market. The evidence from one team in one country is evidence about that team.
The second conclusion concerns the oracle. The most valuable defect in the build (the glass claims asked for an accident report) was found by a person who is not the builder and who did not use the assistant. The group should treat the independent oracle as a role with a name, a time allowance and a succession, and not as a favour from a deputy. In the current set-up the oracle cases are written by Marek Zieliński and by a quality sample drawn by the office of Joanna Kaczmarek, head of claims operations at the centre. Marek is also the deputy owner, which is acceptable at this size and fragile as the number of builds grows.
The third conclusion concerns scope. Injury claims are out of scope because their free-text fields may hold health data under GDPR Article 9, and the decision to include them would raise the tier. That decision is recorded, and the plan should keep it from being reopened in conversation by someone who wants a bigger tool.
The 90 days
The plan runs on the same dates as the Region's: it starts on Monday 2 February 2032 and the review is on Friday 30 April 2032.
| Who | Weeks 1 to 4 | Weeks 5 to 9 | Weeks 10 to 13 |
|---|---|---|---|
| Katarzyna Nowak and Marek Zieliński | Close remark R2 of the takeover test (due 13 January 2032; R1 was closed on 12 December) and record the result in HND-HM-2031-0001; hold the first 90-day review of OWN-HM-2031-0001, due on 2 March |
Extend the oracle with cases from the pilot team's real exceptions, written by the quality sample and not by the assistant; run a restore test | Explain-it-back drill; decide, with Tomasz Wrona, whether a second pilot team is ready |
| Builder lane (Group Application Development, under Dr. Philipp Reinhardt) | Record the receiving developer for each market the tool will serve; check the lane's mandate against the assistant versions in use | Support a second team only if a receiving developer exists for its market; keep production exports readable by the pipeline identity alone | Measure the provision; report to Rainer Lehmann |
| Leaders (Joanna Kaczmarek, Rainer Lehmann, Dr. Sabine Vogel) | Decide the points below | Protect the quality sample's time; hold the scope decision | Read the KPIs with their evidence age |
Decisions needed from leaders
Rainer Lehmann, group CIO, Dr. Philipp Reinhardt and Joanna Kaczmarek need to take four decisions, each recorded as an AI Decision Record when taken.
- Decide the expansion rule. A second team or a second country needs a specification, an oracle, a receiving developer and a data protection screening for its own scope, in that order. The rule should say who may approve an exception, and the answer should not be the builder.
- Make the oracle a role. Name who writes oracle cases in each market, give them time, and write down that the person who writes them must not be the person who built the tool or the assistant that wrote its tests.
- Fix the data path. The pipeline identity reads the production export; neither the builder nor the assistant does. Decide that this is a standing rule of the lane and who audits it, because the rule is easy to weaken one convenience at a time.
- Agree the works-council position. The tool does not rank handlers and logs only claim ids and counts. The group should confirm to the employee representatives, in writing and in the language of each market, what the tool does not do, before a second market adopts it. Works-council rights differ between Germany, the Netherlands and Sweden, and a Polish pilot does not settle them.
What Hansa Mutual should stop doing
The group should stop three habits. First, it should stop quoting the 6.8 to 5.1 days as a result before it has several months of figures and a comparison with a team that did not use the tool. Second, it should stop letting scope questions be settled in a hallway; the answer for injury claims is in the record and any change goes through Step 2 Tier again. Third, it should stop writing oracle cases at the end of a build, when the pressure to ship is highest.
Comparison
The two organisations are close enough to compare and different enough that the comparison teaches.
| Nordvik Region | Hansa Mutual | |
|---|---|---|
| Builder | Hanna Wikström, product owner | Katarzyna Nowak, claims team lead |
| Build | service-point-check |
claims-doc-check |
| Data | Public and internal | Claimant personal data |
| Tier path | B, then C when scheduled | C from the start |
| Who provides the route | Platform team (seven engineers) | Group Application Development |
| Receiving developer | Rasmus Holm, one | Tomasz Wrona, one per market by design |
| Oracle author | Saga Edvardsson | Marek Zieliński and the quality sample |
| Gate that failed | Revert test, rollback note | Independent oracle, glass-03 |
| Main risk | Dependence on three people | Pull of scale across markets |
| Main constraint | Accountability to politicians and the public | Fragmented law across seven jurisdictions |
The similarities are the book's strongest finding, because they hold across a public authority and a supervised insurer. Both builds failed one gate and were saved by it. Both have the same artefacts in the same places. Both rest on a deputy and a receiving developer. Both are measured by a before-and-after count without a control.
The differences are mostly about where the weight falls. The Region's constraint is capacity: a platform team of seven and one receiving developer cannot support ten builders. The group's constraint is consistency: a lane that serves several countries needs the same rule in each of them, and a rule that differs by market has to say so in the record. The Region has to decide how many builds it can afford to receive, and the group has to decide how far one tool's evidence reaches.
Practical guide: A 90-day plan for a builder lane
Purpose. To turn one successful build into a routine that does not depend on any one person, in 13 weeks, with a review whose results can be shown.
Roles. The builder, the deputy, the receiving developer, the platform engineer who owns the workspace, the head of the unit that provides the lane, and the leader who owns the budget. In Hansa Mutual the data protection officer joins when a scope changes.
Inputs. The build record and its gate status, the ownership record, the handover pack, the runbook, the oracle, the register entry, and the most recent measure with its date.
Steps.
- On day 1, write the plan in the build record: three dated goals per lane, one owner each.
- In week 1, list every open gate and every remark from the takeover test. Close them or record why not.
- In week 2, fix the leaders' decisions. A decision not taken by the end of week 2 is recorded as open, with a date.
- In weeks 3 to 4, make the deputy run the tool and the report without the builder, and record how long it took and what the deputy needed to ask.
- In weeks 5 to 9, refresh the independent oracle from real cases, run a restore test, and run the scan again after any dependency or assistant update.
- In weeks 10 to 12, run the explain-it-back drill: the deputy explains the design, the data path and the rollback to the receiving developer, who may interrupt.
- In week 13, read the KPIs below with their evidence age, update the register, and hold the review on day 89.
Exit gate. The review can show, for each build in the lane, a build record whose gate status is current (no gate older than its tier allows), a deputy who has run the tool, a receiving developer who has run the takeover test, and a restore test that is no more than 90 days old. The gate is met by showing these, not by stating them.
Artefact. The updated BLD-* record with a plan section and, for the lane, a register page that lists every build with its tier, owner, deputy, receiving developer and the date of its last evidence.
# docs/ninety-day-plan.yaml (illustrative, Nordvik Region)
plan:
id: PLN-NR-2032-01
build: BLD-NR-2031-0001
starts: 2032-02-02
review: 2032-04-30
goals:
- id: G1
text: Deputy runs the weekly report without the builder
owner: Elin Berg
due: 2032-03-05
evidence: run record RUN-NR-2032-0001 with the questions the deputy asked
- id: G2
text: Restore test passed and recorded
owner: Hanna Wikström
due: 2032-03-04 # the restore test of 2031-12-05 expires on this day
evidence: RST-NR-2032-0001
- id: G3
text: Explain-it-back drill passed with the receiving developer
owner: Rasmus Holm
due: 2032-04-16
evidence: HND-NR-2031-0001, drill section
open_decisions:
- receiving developers named in Applications and Integration
- workspace funded as a service
KPIs and evidence
The book's claims need measures, and the measures need rules, or they become the thing that people optimise. The measures below are the ones that test the book's own claims. Each carries a definition, a source, and an evidence age: the number of days after which the figure may no longer be quoted without being measured again. The ages are illustrative, set at 90 days for evidence about a running tool in line with the ownership reviews of both builds.
| Measure | Claim it tests | Source | Evidence expires |
|---|---|---|---|
| Gates evidenced | Each step ends in an artefact | Register: share of builds whose gates for their tier have a current artefact | 90 days |
| Takeover test result | A colleague can run, change, ship and revert | Receiving developer's record: pass, items failed, hours taken | At each release |
| Oracle findings | The oracle is independent | Count of defects found by the oracle that the builder's own tests missed | Per release |
| Restore test age | The tool can be restored | Days since the last passed RST-* |
90 days |
| Outcome measure | The tool does what it was built for | Phone-service count, median days to a complete file | 90 days, and stated with its limits |
| Unregistered builds | The sanctioned route is easier | Sweep count against register count | Per sweep |
| Time to workspace | The provision works | Days from request to first use of the workspace | Per quarter |
# docs/evidence/kpis.yaml (illustrative)
kpis:
- id: K1
name: Gates evidenced
definition: builds whose gates for their tier have an artefact no older than 90 days, divided by builds in the register
evidence_age_days: 90
- id: K3
name: Oracle findings
definition: defects found by the independent oracle that the builder's own tests did not find
reading: zero is not good news until the oracle itself has been checked
evidence_age_days: 0 # per release
- id: K5
name: Calls about wrong opening hours
value: 17
measured_on: 2032-01-31
method: category count by the phone service, one month, no control group
evidence_age_days: 90
The acceptance-rate trap
One measure is missing from the table on purpose: the share of the assistant's suggestions that the builder accepts. It is easy to collect, it rises when the builder reads less, and it says nothing about whether the software is right. The same holds for lines of code produced and for the number of builds in the register. A figure that people are rewarded for reaching changes what they do to reach it, as Jerry Muller argues in his study of metrics (47, Muller, 2018), and a builder who is told that a high acceptance rate is good will accept more. The measures above are counts of evidence, not counts of activity.
The research on productivity shows how hard the underlying question is. A randomised trial of experienced open-source developers measured their work with and without early-2025 AI tools (36, Becker et al., 2025), and the team that ran it reported in February 2026 that the data of its follow-up gave an unreliable signal of the current effect because of selection effects, with developers declining to work without AI or withholding tasks, and that it was changing its design (94, METR, 2026). The lesson for a lane is not that nothing can be measured. The lesson is that a measure of speed taken from people who can choose how they are measured is weak, and that the two outcome measures of this book, which are counts taken by someone else (the phone service, the claims operations office), are weak in a different way: they have no control. Both weaknesses go in the record.
The review on day 89
The review is where the plan either produces a decision or does not. Each organisation should enter it with three possible outcomes written down in advance, so that the figures decide and the mood of the meeting does not.
Continue. Every gate for the tier of each build has a current artefact, the deputy has run the tool, the receiving developer has run the takeover test, the restore test is no more than 90 days old and no Tier D request has been accepted into the lane. The organisation then agrees the next 90 days, which may include a second build.
Narrow. One or more of the conditions fails and the cause is capacity, not the method. A build with a stale restore test, or a deputy who has not yet run the tool, is narrowed to its current scope and takes no new features until the evidence is current. The lane takes no second build until the gap is closed.
Stop or hand over. The owner has left, the deputy cannot run the tool, the receiving developer declines, or the purpose has disappeared. A professional outcome of a build is sometimes that it stops. The build record says so, the runbook explains how to switch it off, and the sunset date is brought forward. Step 12 Hand over covers this case as fully as it covers a promotion, and an organisation that cannot retire a tool has not finished building it.
The review is also the place to ask the employee representatives to read the register. Under Swedish practice the Region informs its representatives before a register that lists named owners grows, and in Hansa Mutual the position agreed in week 2 is tested against what the tool in fact logs. Both reviews are part of the plan and neither is a courtesy. The outcome of the review is a short note in the build record, dated and signed by the leader who owns the budget, and it is the first piece of evidence for the next period.
Risks and what to stop
The risks below apply to both organisations. Each carries a label for how well it is evidenced.
| Risk | What happens | Label | What reduces it |
|---|---|---|---|
| One builder owns everything | The builder leaves or is ill and the tool has no owner | Expected: a build with one owner depends on that person | Deputy who has run the tool; review every 90 days |
| One receiving developer | The takeover test waits or is skipped | Expected | At least two named, with time |
| Scope creep | A second request moves the tool to a higher tier without a new decision | Expected | Redo Step 2 Tier in writing on any change of data, writing or schedule |
| Stale evidence | A passed test is quoted after the code, the dependencies or the assistant changed | Expected | Evidence age in the record; rerun after any update |
| Security gaps of generated applications | Access control, injection and authentication faults that the builder cannot see | Observable in one study: an audit of 200 deployed applications built with two assistants found at least one vulnerability in 91.0 per cent of them, clustered in broken access control, injection and authentication; a preprint, not peer reviewed (109, Deng et al., 2026) | Step 8 Secure, an independent review by a developer for Tier C |
| Shared errors | The assistant that writes the tests and the assistant that writes the code make the same mistake | Observable that errors of large language models are correlated (24, Kim et al., 2025); how far this affects a given build is not measured here | An oracle written by a person, not by the assistant |
| Literacy duty | No measures have been taken to support the AI literacy of staff who use AI systems | Observable: Article 4 of the AI Act requires providers and deployers to take such measures, without guaranteeing a level for any individual (1, European Union, 2024), and the Commission explains the duty in guidance (45, European Commission, 2026); the book's conclusion is that builders are among the staff concerned | A builder learning plan (BLP-NR-2031-01, BLP-HM-2031-01) and a competence record |
| Gatekeeping or bypass | Developers are asked to say yes or no to everything, or builders go round them | Expected | A receiving developer who coaches, a lane that is easier than the alternative |
| Overclaiming | A before-and-after count is quoted as proof | Expected | Every figure quoted with its method, date and limits |
The risks are not an argument against building. They are what the plan is for, and the review on day 89 is the point at which each organisation decides, with figures and dates in front of it, which of them has grown.
Across the degrees of delegation
The plan assumes the assistant's mandate stays where the builds put it: Mode 2 in the editor and Mode 3 for delegated tasks inside a sandbox, and no Mode 5 for builders. The table sets the plan by usage mode and by the highest degree of delegation each may have.
| Usage mode | In the 90 days | Highest degree of delegation | Who stays accountable |
|---|---|---|---|
| Mode 1 conversational assistant | Learning, drafting a specification, explaining a diff | Level 0 Advisory | The builder |
| Mode 2 embedded assistant | Writing code and tests on a branch | Level 2, edits on a branch | The builder, who reads the diff |
| Mode 3 agentic work tool in a sandbox | Delegated tasks such as an oracle refresh draft or a dependency update on a branch | Level 3 Bounded, within the mandate | The builder; the deputy reviews the run record |
| Mode 4 Built AI applications | Not in the builds; a tool that calls a model goes to the platform's rules | Not decided here | The service owner |
| Mode 5 autonomous production agent | Not for builders | Not used | Not applicable |
Level 4 Autonomous is not used for any action class of the builders' assistants. The prohibitions of AI Developer, Chapter 4 stand without exception: no change to production without a gate the change cannot alter, no code in a security-critical path without review by a named developer, no change to the assistant's own mandate, permissions, credentials, test oracles or pipeline gates, no irreversible action on production data, and no decision about a named person's employment, pay, performance rating or access to work (86, Nordqvist, 2026). A mandate that allowed the assistant to rewrite tests/oracle/ would remove the independence on which the second conclusion above depends.
Nordvik Region and Hansa Mutual
Read together, the two sections ask the same thing of any third organisation that wants to follow them. Each needs a builder who has finished one build to the standard of the twelve steps, a deputy who can run it, and a receiving developer who has done so. Each needs a route that is easier than the unofficial one, an oracle written by someone other than the builder and the assistant, and a review that looks at dated evidence. The Region needs to widen its supply of receiving developers and to fund its workspace; the group needs to hold its scope and keep its expansion tied to evidence, market by market. Neither needs a larger programme than the one described. Both need the plan to be dated, owned and reviewed, because a plan without an owner is only a wish.
Summary
This chapter concerns all twelve steps, with the weight on Step 11 Own and Step 12 Hand over, and the developer functions D1 Frame to D5 Steward. It concluded that the two builds show a workable method and consistent artefacts, not a proven effect; that each organisation depends on a few named people; and that the next 90 days should turn one build into a routine.
For Nordvik Region the plan names the receiving developers, funds the workspace as a service, sets the rule for a second builder and says what the register is for. For Hansa Mutual it sets the expansion rule, makes the oracle a role, fixes the data path and agrees the works-council position. Both should stop quoting before-and-after counts as results, and both should stop settling questions of scope in conversation. Outcomes of the plan are expected, not observed.
The measures that test the book's claims are counts of evidence with an evidence age: gates evidenced, takeover test result, oracle findings, restore test age, the outcome counts with their limits, unregistered builds and time to the workspace. The acceptance rate of the assistant's suggestions is not among them. The risks are named, labelled and paired with an action. Chapter 25 judges the book's thesis against the evidence in this chapter and the chapters before it, and sets out what a reader does on Monday.
Sources
- Muller, J. Z. (2018). The Tyranny of Metrics. Princeton University Press. (47, Muller, 2018)
- 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)
- METR (2026). We are Changing our Developer Productivity Experiment Design. METR blog, 24 February 2026. (94, METR, 2026)
- Deng, J., Fan, Z. & Meng, R. (2026). Understanding the (In)Security of Vibe-Coded Applications. arXiv:2606.23130. (109, Deng et al., 2026)
- Kim, E., Garg, A., Peng, K. & Garg, N. (2025). Correlated Errors in Large Language Models. ICML 2025; arXiv:2506.07962. (24, Kim et al., 2025)
- European Commission. AI Literacy: Questions and Answers. Shaping Europe's digital future. (45, European Commission, 2026)
- 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)