Agentic Development, Part 1: The Bottleneck Is No Longer Code

One developer can now easily produce 100,000 lines of code in a few days.

Now put several of them on the same codebase, and you will see a disaster in no time.

The main problem is overlap.

When several developers work with their own agents, their own context, and their own decisions, the team can move very fast while creating collisions just as fast.

There is a serious conflict between speed and safety.

For months, we have focused on how to become more productive as individuals with AI. There is still a lot to learn on this subject. I discover new things myself every day.

But the uncomfortable thing about AI productivity is that a team can become full of very fast individuals and still fail to move faster on the roadmap.

Agentic development does not remove the need for teamwork. It makes teamwork the main engineering problem.

The individual productivity trap

The productivity gain is real.

But individual productivity can become absolutely inefficient when the team is not synchronized. In the end, a collection of highly productive people is not necessarily more impressive than a good team before the agentic era.

When a team is not synchronized, scale no longer works.

Putting more resources on a subject no longer guarantees that you will move faster. The additional capacity creates more output, but it also creates more decisions, more overlap, and more context to absorb.

That can work on isolated objectives. But once roadmaps overlap, individual speed is no longer enough.

Once every contributor can generate the volume of a small team, the organization has to coordinate a level of output it was never designed to absorb.

The bottleneck is now obvious: communication, synchronization, and scope overlap.

The question is no longer only:

How do I make one developer more productive with AI?

It is:

How do we aggregate the agentic capabilities of several people?

Agents have separate contexts. Humans do not.

I remember working on large applications in 2006 that took more than 15 minutes just to compile.

You could not rebuild your application all the time. You only had a few shots during the day to debug your code.

Somehow, I am getting that same feeling now: waiting for the machine to finish the work so I can review and steer.

People talk a lot about running agents in parallel. But that only works if you can handle the constant context switching.

Agents have separate contexts. I do not.

Every developer now operates with one or several agents carrying their own instructions, assumptions, and working memory. The developer has a context. The agent has another one. The other developers and their agents have their own.

Execution can be parallelized much more easily than understanding.

This becomes even clearer when you look at agent memory.

Memory remains the Achilles' heel of AI agents. Or at least, it is what is hardest to manage over the long term.

Every time you start a new Codex task, it is as if a brilliant new developer joins your team to handle just that one task and then leaves, dropping some code behind and possibly some documentation.

The next task? Yet another new developer shows up for a few minutes. They can skim through the code and documentation left by the previous one and start the work.

It feels a bit like an episode of Black Mirror. You can clearly see how hard it becomes to make things work smoothly by the time you reach the 100th developer.

It is eternal turnover management.

Agentic decisions are often silent

Even if agent memory improves, another problem remains: agents are useful precisely because they can move without asking for approval at every step.

Volume is only part of the issue.

Agentic AI makes many decisions silently. That is also why it is useful. If an agent stopped every few minutes to ask for confirmation, we would lose the productivity gains.

But those silent decisions create context divergence.

An agent will not wait for perfect clarity. It will move.

Developer A can build a behavior. Developer B can later modify it through another agent without fully seeing the impact. A merge can be so structural that the next morning someone opens the application and no longer recognizes what they are looking at.

The code may still work. The tests may still pass. But the team's shared understanding has moved further away from the actual system.

This is not traditional technical debt.

Technical debt usually means that people understand the system but accept shortcuts that will cost them later.

Here, the system itself can change faster than the team can absorb what happened.

That is knowledge debt.

The collision surface is larger than the codebase

The consequences of this context divergence are not limited to application code.

An agent does not only write code.

It can touch the cloud, the database, storage, authentication, environments, and data.

A test database can change. Data used by one developer can disappear. An environment can be modified before the rest of the team has absorbed what happened.

As you know, agents work better when they have more context. We naturally give them access to more files, more history, more tools, and sometimes a broader codebase.

The more context they have, the more useful they become.

But the more shared the surface is, the easier it becomes to overwrite, modify, or remove work done by someone else.

At that scale, reviewing everything, controlling everything, or even knowing exactly what changed becomes unrealistic.

The risk is not that the agent does nothing. The risk is that it does a lot of reasonable things while carrying a slightly different understanding of the objective.

Those local decisions accumulate.

Eventually, every developer is moving quickly inside a system nobody completely understands anymore.

More communication will not solve it

At this point, the easy reaction is to communicate more.

I do not think this works.

At some point, the amount of information becomes too large for a human brain. Developers can spend entire days catching up, synchronizing, and rebuilding context while the changes were produced in a few hours.

Communication is necessary, but it cannot be the only synchronization mechanism.

The team cannot compensate manually for unlimited execution speed.

If every developer generates the volume of work that a team produced a year ago, then every developer also carries the complexity that a team handled a year ago.

Your role as a team lead starts to resemble the role of a manager coordinating several team leads.

This is the real impact of agentic development.

The bottleneck is no longer the ability to produce code.

It is the ability to maintain a shared direction while code, infrastructure, data, and decisions are changing at machine speed.

Part 2 will look at what this requires in practice: shorter feedback loops, stronger technical specifications, smaller collision surfaces, better architecture, and a different role for technical leaders.

Continue to Part 2: Making the Speed Useful

Cover: detail from Auguste Rodin's The Gates of Hell. Photo by Jean-Pierre Dalbéra, CC BY 2.0; displayed in monochrome.