Until now, a fundamental aspect of the development process within teams and organizations was knowing who owns every feature or system within a project. Most of the time, the person who wrote it was implicitly assigned as the owner of that piece. If the original author is no longer on the team, another person might be elected (not explicitly but informally) to that role. Maybe they maintained the feature; maybe the author transferred the knowledge before leaving. In any case, all pieces of code have at least one owner.

The owner

We assume that the person who wrote, tested, and decided the code was ready to be merged has all the information needed to quickly fix bugs when they arise, or at least can streamline the debugging process and identify issues faster.

But now the table has turned. The owner didn’t spend days thinking through the implementation. We define the task and let a subordinate (an LLM) handle the writing process. We can conduct a deep review of the proposed changes, but even then we cannot expect the same depth of understanding of the code that was written. It’s worth noting that thorough reviews should be mandatory, but due to organizational pressures, this level of rigor is not enforced across all teams, exacerbating the problem.

Even with mandatory reviews and strict policies enforcing deep understanding before merging, the speed gains from LLMs make maintaining ownership increasingly difficult. The product grows faster than ever. Thousands of new lines appear each week. Maintaining ownership of everything is simply not manageable for humans.

Project evolution over time has changed

Before LLMs, projects started small. The team, usually, was also small. As features accumulated, the team grew organically. Complexity increased at the same pace as scale. Eventually, the complexity of the development workflow hit a barrier—either the team was too large to synchronize effectively, or the project was too complex for everyone to work together. Projects were naturally split into distinct parts, each with dedicated teams.

Now, projects scale in size and complexity at an accelerated rate. Headcount does not increase proportionally—in fact, many companies are actually reducing headcount. Fewer people, yet thousands of lines of code added monthly. This combination no longer scales.

The paradox

Right now, whether due to hype or the pace of organizational change, teams focus solely on accelerating delivery. Development workflows remain unchanged. The concept of code owners persists. This paradigm no longer works.

We’re already seeing the consequences. Applications will crash more frequently. Users will encounter more bugs regularly. This isn’t new—we’ve seen major companies fail spectacularly in recent years (Cloudflare, AWS). We’ll simply see it happen more often.

Humans will still be accountable for the code pushed to production (as stated in an IBM document from 1979: A computer can never be held accountable. Therefore a computer must never make a management decision, which is absolutely true in the LLM era), so we as an industry need to find a new paradigm for this era of software development.

In my opinion, at the current growth rate, the solution requires greater investment in prevention, but more importantly, we must improve our reactive responses when errors occur. More code means more bugs, with or without LLMs, so stablishing reliable response workflows is critical moving forward.