Business
Half of Norway's code is AI-generated. Who owns the errors nobody finds?
Nearly half of Norwegian developers let AI write most of their code, and 81 percent fear errors they never catch. The fear is about accountability. When nobody writes the code, nobody owns the error, and that accountability is what a consultant has to sell.
What happened
On September 23, 2026, the Norwegian developer news site kode24 published figures from its annual survey of 2,067 developers in Norway: nearly half let AI generate most or all of their code, only 7 percent write code with no AI at all, and 81 percent worry about errors they never catch. In the same survey only one in five say they pair program regularly, and at Norgesgruppen Data, the IT unit of Norway's largest grocery group, developers now set up and evaluate agents together instead of writing code in pairs.
Why the 81 percent is read as a quality problem
The 81 percent figure is read as distrust of the models. The answer that follows from that reading is better tooling: more tests, stricter static analysis and a new model version that makes fewer mistakes.
The decline in pair programming is read as a loss of culture. The respondents kode24 quotes miss colleagues, sparring and team building, and that loss is real.
Both readings miss what the two figures have in common. Pair programming and code review caught errors, and they also assigned accountability. The person who wrote the line and the person who approved it could both answer for it. Authorship was the accountability model in software development, and it never had to be written into a contract.
When an agent writes the code, the author disappears. Accountability disappears with the author unless someone deliberately moves it. The worry 81 percent of developers describe is about an error that has no owner.
We set up an agent, evaluated it together and watched it work together.
What changed at Norgesgruppen Data?
Mats Grøseth's teams at Norgesgruppen Data have stopped pair programming. The collaboration has moved up a level: colleagues set up an agent together, evaluate it together and watch it work. Line-by-line review is gone.
The choice is rational. Grøseth points out that developers produce many times as much code with AI, and that two people at one keyboard would eat up the gain.
The choice also moves the question of who answers for the code from the line to the setup. The person who evaluated the agent has approved a way of producing code. The same person has not approved the code the agent produced yesterday. If nothing says that approving the setup also means owning the result, nobody owns it.
Who answers for the code when an agent writes it?
When an agent writes the code, nobody answers for it unless the contract says so. The table shows where accountability sat when people wrote the code, and where it ends up when nobody moves it.
| Question | When people wrote the code | When an agent writes the code |
|---|---|---|
| Who wrote the line? | A developer named in the version history | An agent, started by someone |
| Who approved it? | The person who reviewed the pull request | The person who evaluated the agent setup, often weeks earlier |
| Who answers for the error? | The author and the approver | Nobody, unless the contract says so |
| What does the consultant bill for? | The hours it took to write | The hours it took to write, now the cheapest part |
| What should be measured? | Deliveries and error rate | Errors that got through, and the time it took to fix them |
What does it mean if the consultant sells accountability?
The claim behind our pillar on the future of consulting is that when agents do the work, consultants sell accountability and outcomes, and hours stop selling. kode24's figures make that claim specific for software development. Writing the code is the part of the delivery that is cheapest to remove, and half of Norwegian developers have already removed it.
A consultancy that bills hours for AI-generated code charges for the part that costs least to produce. The most expensive part has no price: the error nobody read, which is only found in production.
Accountability for AI-generated code has three parts that can be written into a contract. The vendor decides which parts of the codebase a person always reads, and which are checked by tests and monitoring. The vendor decides which actions the system never takes without an approval. The vendor has a named person who answers, and pays, when an error gets through. How an outcome and an accountability are priced is covered in the pillar's anchor article, What a consultant delivers when agents do the work.
Measurement has to follow accountability. A delivery priced on accountability is measured on errors that got through, and on the time from an error being found to it being fixed. Why hours and run counts are poor measures is covered in How to measure whether automation worked.
Where will the next reviewers come from?
Juniors pair program the most. 32 percent of the 125 juniors in kode24's survey do so regularly, against 19 percent of the 729 seniors. SINTEF researcher Nils Brede Moe has found that pair programming works well when juniors are learning, and he notes that more AI leads to more individual work.
That makes reviewing AI-generated code a staffing question. Deciding whether a change holds up requires having written enough code yourself to recognize an error that passes every test. That skill was built at the keyboard next to a senior. A consultancy that takes responsibility for code it did not write has to be able to show the client who makes that judgment today, and how the people who will make it five years from now are learning it.
What Apps AS does differently
Apps AS builds agentic products of its own. The review in them sits in the seams between what the agent says, the tools it can use and what gets measured afterwards.
Threll is the voice agent product Apps AS develops. A call script for a voice agent is a state machine written in natural language, wired to tools, measured against a fixed analysis schema and run under its own voice configuration. Before a script goes into production, we review the seams between those four against a fixed checklist in seven groups. The review looks for, among other things, an end state no call can reach, a promise the agent has no tool to keep, and an outcome the dashboard can never record. A script can read well and still contain all three.
The script review proposes changes and writes nothing back to Threll. A person reads the proposal and decides. The review has moved from the text to the setup, as it has at Norgesgruppen Data. The difference is that the Threll review has a checklist written down before the script is written.
Outbound calls in Threll are split into two operations. The agent can prepare a call, and the call is placed only when a confirmation is used. Each customer account decides whether that confirmation is required. A phone call cannot be rolled back, which is why the confirmation comes before the call.
The publishing agent on apps.no only writes drafts. Why Apps AS budgets for that review instead of removing it is covered in Manual review of agents is not a cost you can remove. Why risk shifts from wrong answers to wrong actions when software acts on its own is covered in What changes when software acts on its own.
Write down the name of the person who answers for the code
If you have AI-generated code in production, write down the name of the person who answers when an error in that code reaches your customers. If there is no name, that is the gap 81 percent of Norwegian developers describe. Send us the name, or the lack of one, at hello@apps.no. We will reply with which parts of the codebase we would always have a person read, and which actions we would never let an agent take alone.
Sources
About this article. Written by Espen Hareide, co-founder and partner at Apps. A take using the pillar on the future of consulting as its lens. The figures from kode24's 2026 salary and job satisfaction survey come from kode24's article of September 23, 2026, read September 28, 2026. The survey is based on self-selected respondents and is not a random sample. The description of the call script review and the confirmation of outbound calls in Threll is based on Apps AS' own routines and product configuration as of September 28, 2026. The article uses no customer figures.
FAQ
- Is it enough to require a person to approve everything the agent writes?
- Only if the approval has a criterion and an owner. A thousand lines generated in ten minutes are rarely read line by line, and then the approval becomes a signature. Pick out the parts of the codebase a person must always read, such as payments, access control and data deletion, and let tests and monitoring check the rest.
- Who owns the error when a contracted consultant uses agents to write the code?
- The contract has to say. Without a specific clause it is unclear, and in practice unclear responsibility ends up with whoever owns the system, which is the client. A contract that takes accountability seriously states what the vendor checks, how fast errors are fixed and what the vendor pays if an error gets past those checks.
- How do we measure whether our review of AI-generated code works?
- Count errors found in production rather than before it, and the time from an error being found to it being fixed. Also count how many reviews actually changed the code. If almost none of them change anything, the review is either unnecessary or too shallow, and both are worth knowing.
- Should we keep pair programming when agents write the code?
- For training, pair programming still pays off most, and kode24's figures show that juniors are the ones who do it most often. The pair can just as well sit together over the agent setup, as Norgesgruppen Data does, as long as both know that approving the setup also covers the code the agent writes later.
- Is development priced on accountability more expensive than development priced on hours?
- The hourly rate goes up, because the vendor takes on a risk the client used to carry alone. The total price depends on how much of the hours went into writing code. The risk cost the client money before too. It just never appeared on the invoice.
