A code assistant suggests; a person accepts, merges, and takes responsibility. That chain of accountability doesn't change because the person writing the draft changes, and it's best if it doesn't: it's the only way to guarantee that there's someone to ask when the system does something unexpected in production.
The problem arises when responsibility is implicitly diluted, without anyone explicitly deciding to do so. No one declares they are no longer accountable for their code. Simply put, the gap between those who accept it and those who understood it widens.
This confusion is costly because it consumes the budget and undermines the initiative's credibility. When, six months later, someone asks what has improved, the honest answer is usually "the initial experience," and that doesn't justify a transformation program.
Three mechanisms, all three silent:
The review becomes superficial. When large changes occur frequently, the reviewer's attitude shifts from "I understand this and agree" to "it seems reasonable." The 2024 DORA report measured the aggregate effect: as AI adoption increased, delivery stability fell by 7.2%, associated with the growth in change batch sizes.
Authorship becomes blurred. In one incident, the question "Who wrote this?" is met with the response "We generated it." This response prevents the conversation from continuing.
Trust replaces verification. The code works in testing, so it's assumed to be good. But working and being good are different things: the latter includes what will happen when the context changes.
In the same DORA report, 39.21% of developers declared little to no confidence in the generated code. This is an inconvenient finding in the opposite direction: there is declared distrust, and yet the volume of accepted code is growing.
It's not a question of blame. It's the ability to answer four questions about any part of the system:
Anyone who can answer all four questions is responsible for that code, whether it was written by a person or a tool. Anyone who cannot answer any of them is not responsible, even if they are listed as an author in the repository.
Role | What does the tool offer? | What remains human |
|---|---|---|
Design | Alternatives and examples | To choose and to accept the choice |
Implementation | Functional draft | Verify that it does what the business expects. |
Revision | Detection of known patterns | Judgment on fit and consequences |
Operation | Alerts and diagnosis | Deciding what to do when something goes wrong |
Responsibility | None | All |
The last line is not rhetorical. No tool shares responsibility before a client, an auditor, or a court. The organization is responsible for what its software does, regardless of how it was produced, as was established in the Air Canada chatbot case resolved in 2024.
Nobody merges what they cannot explain. The basic rule. It doesn't require understanding every detail, but rather being able to answer the four questions above.
Each change has a person responsible, with a name. Not a team. One person who is responsible for that part of the system and who can be asked questions.
Critical tests are written by one person. If the same tool generates both the implementation and the test that validates it, the circuit closes on itself and does not check anything relevant.
The size of the change is limited. It is the measure that makes the previous three possible. A major change cannot be thoroughly reviewed, no matter how good the reviewer's intentions.
If your company outsources development, this conversation has a direct contractual impact. Three questions for the provider:
Who is responsible for defects in the delivered code? A defect is not a scope change. It should be corrected at no cost and documented in writing. In our case, it's the Rain Guarantee: we correct any defects in the code we deliver, for life.
Can you explain any part of the system six months later? The test is simple: ask for an explanation of a randomly chosen module.
What decision documentation is provided? Not line-by-line commentary, but rather explaining why each approach was chosen and what was discarded. That's what allows another team to take over.
A supplier who accepts these three conditions is saying that they maintain the chain of responsibility intact. One who qualifies them is indicating where the gap will be.
For a technical director who wants to know the current state of their team, there is an exercise that takes one hour: Choose three parts of the system at random and ask those responsible for them to answer the four questions.
The result doesn't measure the quality of the code. It measures something more important: whether the organization controls its system or merely owns it.
The person who accepts it and incorporates it into the system, and the organization that puts it into production. No tool shares responsibility before a client, an auditor, or a court: the company is responsible for what its software does, regardless of how it was produced.
With four questions: what does this do in business terms, why is it the way it is and what alternative was discarded, what will break if it's changed, and how do you know it will continue to work? Whoever can answer all four is responsible for that code, whether it was written by a person or a tool.
Through three silent paths: review becomes superficial as changes grow in size, authorship becomes blurred until the response to an incident is "we generated it," and confidence that tests pass replaces verification that the behavior is what the business expects.
Four: no one merges what they cannot explain, each change has a named person responsible and not a team, critical tests are written by a person and not the same tool that generated the implementation, and the size of changes is limited so that review is possible.
They must be responsible for defects in the delivered code at no cost and in writing, be able to explain any part of the system six months later, and provide documentation of the decisions made and the alternatives discarded, not just comments in the code.
According to the 2024 DORA report, 39.21% of respondents expressed little or no confidence in the system. This is a relevant finding because it coincides with an increase in the volume of accepted tests, suggesting that expressed distrust does not always translate into more testing.
Could your team explain any part of your system? Our technical audit evaluates architecture, code, debt, and actual maintainability, in writing and within 10 business days. Request the audit → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
