Code ownership in the age of LLM

Who is responsible for the code if no one wrote it?

Martina scrolls through the code, stops and scrolls back again. Then once more. The code is functional, but difficult to read. There is nested logic, few meaningful names and hardly any clues as to why certain decisions were made. Technically, the implementation is pushing boundaries that should at least be discussed.

At some point, she asks the obvious question: ‘Who actually wrote this?’

A brief moment of silence. Those present look at each other. No one speaks up. Not out of disinterest, but because no one feels responsible. The code has been in the system for a few weeks. It works. Somehow.

‘Dirk, didn’t you write the code?’ Bernd interjects.

After a moment’s thought, Dirk replies, ‘That’s right. I prompted most of it with ChatGPT and then made a few minor adjustments. It looked plausible.’

That answers the question. And at the same time, it doesn’t. Because the real uncertainty remains: Who is responsible for the structure, technical correctness and long-term maintainability?

Dirk didn’t write the code in the traditional sense. The LLM generated it. The code was approved. But no one can say for sure who is responsible for its structure, technical accuracy and maintainability.

This is where the topic of ‘code ownership in the age of LLM’ comes in. Not as a new theory, not as a vision of the future, but as a very practical question in everyday development.

What was code ownership originally intended to achieve?

Code ownership is not an end in itself. The concept arose from a practical need: it was intended to make responsibility in complex software systems visible and manageable.

The primary aim was never to record who wrote which code. Something else was crucial:

• Who can be contacted if questions arise?
• Who feels responsible when requirements change?
• Who is accountable when errors occur or decisions turn out to be wrong in hindsight?

In classic development environments, this assignment was relatively clear. Code was mostly written manually. Developers or teams invested time, understanding and mental effort into their solutions. As a rule, the person who wrote the code also understood it. Responsibility arose almost automatically from the history of its creation.

The various models of code ownership addressed precisely this issue.

Strong code ownership made responsibility explicit. Specific individuals were gatekeepers for clearly defined areas. This reduced uncertainty and facilitated decision-making as long as the number of changes remained manageable.

Weak code ownership loosened this structure. Changes were easier to make without completely dissolving responsibility. Responsibility remained, even if not every change was implemented by the same person.

Collective code ownership went one step further. Responsibility was deliberately shared. The underlying assumption was that working together, reviews and exchanges would create sufficient understanding to ensure quality and maintainability.

All models had one thing in common: ownership was closely linked to human work. To time expenditure, cognitive effort and the struggle for viable solutions. That is precisely why these models worked well enough for a long time. Not perfectly, but stably.

The bottleneck was clear: writing code was time-consuming, changes took time, and complexity arose slowly. Responsibility could be assigned relatively reliably based on proximity to the code and the decision. But this basic assumption is now being challenged because new possibilities are changing the previous relationships.

What new opportunities arise when these basic assumptions are dissolved?

The new opportunities that are often talked about today are not future technology, but have long been part of everyday development. Large language models assist in writing, restructuring, explaining and supplementing code. In doing so, they shift the assumptions on which code ownership has been based up to now.

First, the way code is created is changing. Whereas in the past, every line was deliberately formulated, today larger blocks of code are created in a short period of time. Developers describe a goal or context. The LLM provides a suggestion. The human contribution is often less in the writing itself than in selecting, adapting and accepting.

This dissolves a central link. Writing and understanding no longer automatically coincide. A developer can adopt code that seems plausible at first glance without having fully understood it. The speed with which solutions are created exceeds the time it would take to fully understand them.

In addition, changes become cheaper. Complex or unfamiliar code can be adapted more quickly. Refactorings or alternatives are generated rapidly. This increases the frequency of changes and thus also the number of decisions that have to be made, often without being perceived as such.

At the same time, a new form of false security arises. The code appears consistent, well-structured and comprehensible. However, explainability is no substitute for a sense of responsibility. An LLM’s ability to provide a justification says nothing about whether it is valid in a technical context.

This also changes the role of reviews. They serve less to safeguard technical errors and become more of a place where responsibility arises. Anyone who accepts or approves an LLM’s suggestion makes a decision and assumes responsibility, even if they did not write the code themselves.

This is precisely where we see why previous models of code ownership are coming under pressure. They assume that proximity to the code is created through writing. However, LLMs decouple this proximity from the creation process. The question is therefore not whether code ownership is still needed. The question is where it can be meaningfully anchored under these conditions.

From code ownership to decision ownership

When writing and understanding become decoupled, code ownership loses some of its previous viability. Not because responsibility becomes superfluous, but because it is located in the wrong place.

In a world where code is increasingly suggested rather than written, responsibility no longer arises primarily from the creation of code. It arises where decisions are made.

Decision ownership describes precisely this point. Whoever decides that a proposal is acceptable takes responsibility for its impact. Regardless of whether the code was written manually, developed collaboratively or generated by an LLM. This shifts the focus away from the question of who created the code and towards the question of who is responsible for it in terms of subject matter, technology and organisation.

Decision ownership does not mean that every decision has to be formalised or documented. It means that it is clear who is responsible for certain types of decisions. For example

• the technical correctness of an implementation,
• compliance with architectural guidelines, and
• the impact on maintainability, security or operation.

In classic ownership models, these decisions were often implicitly linked to the code owner. Whoever wrote, decided. Whoever decided, understood. This link no longer exists.

With LLM, the focus shifts. Decisions are made more frequently, in smaller increments and more quickly. Many of them happen casually. A suggestion is accepted because it seems plausible. A refactoring is accepted because it looks clean. This is precisely where decision ownership arises, even if it is rarely explicitly named.

It is important to make a clear distinction here: LLM provides suggestions, it does not make decisions, it does not bear responsibility. Responsibility arises exclusively where people decide to adopt, approve or put something into production.

In practical terms, this means the following for teams:

• Ownership should no longer be primarily linked to files, modules or directories.
• Ownership should be visible at decision points, such as in reviews, approvals or architecture decisions.
• Ownership arises through acceptance, not authorship.

Decision ownership does not completely replace code ownership. It complements and shifts it. Code remains relevant. But the real lever for quality, maintainability and risk increasingly lies in the decisions surrounding the code. The easier it is to create code, the more important it becomes to ask who is prepared to take responsibility for its consequences.

Figure: Decision ownership complements code ownership

Conclusion

Responsibility cannot be generated.

Today, code is created faster, easier and seemingly effortlessly. That is precisely what makes it deceptive. The easier it is to produce solutions, the less the code itself reveals how much understanding, consideration and responsibility actually went into it.

Code ownership has long been a practical means of making responsibility visible. Not because ownership was important, but because it created proximity. Proximity to the problem, to the solution and to its consequences. Today, this proximity can no longer be reliably derived from the creation of the code.

LLMs shift the place where responsibility arises. Not away from people, but away from writing. Responsibility arises where it is decided that something is good enough. That it is technically sound and can go into operation.

This cannot be automated, delegated or outsourced to a tool.

Teams that want to continue to effectively practise code ownership must face up to this shift. Not with new rules, roles or processes, but with clarity. Clarity about who makes decisions and who is accountable for their consequences. Because the easier it is to create code, the more difficult it is to make the decision to accept it. And that is exactly where responsibility begins. Including Dirk’s.

Notes:

Here you will find more infomation about code ownership.

Here you will find an assessment of Code Ownership types by Martin Fowler, one of the authors and first signatories of the Agile Manifesto.

Extreme Programming uses the term “shared code” as a method. Felix Stein also propagates Continuous Code Ownership in a four-part series of Gernan-language articles, as it is not enough to deal with the code only in the course of upcoming modifications, as in practice it can often take several years before a certain piece of code is touched.

Would you like to discuss code ownership in the age of LLM as a multiplier or opinion leader? Then share this article in your network.

Michael Schenkel has published further articles on the t2informatik blog, including: