Main keeps moving

The way a group of people makes one thing together has changed three times in my working life: shared storage, then real co-authoring, and now generation. The third one is happening as I write this.

Each change removed the bottleneck the previous generation had lived with, and each one then produced a new bottleneck in a place nobody was looking. I find that pattern the interesting part. It is why the current problem, which is new, was predictable in shape even though nobody could have named it in advance.

The deck

I spent years in strategy consulting, where the unit of work is a slide.

In the first era, only one person could have a file open at a time. So the work was split by slide: each of us built our own section, and everybody emailed their slides to the project manager, who consolidated them into the master deck.

That consolidation was a real job, and it was one person's. Reconciling two versions of a page two people had both worked on. Chasing whoever had not sent theirs. Re-applying the formatting that broke on the way in. Doing it again when a section came back revised an hour later.

So the parallelism was already there, with several people working at the same time, and the entire cost of it landed on one person at the end. The merge was a role more than a step in the process.

Shared storage arrived and solved the transport problem. The deck lived in one place everybody could reach, and the emailing stopped. It did not solve the merge: two people still could not work on the same slide, and somebody still had to assemble the whole and reconcile the differences. The file got easier to find, and the work stayed just as hard to combine.

Then came real co-authoring in the cloud versions of the same tools, and several people could work in one deck at the same time and watch each other's cursors. That was the real step change of that era. For presentations, the merge problem largely went away.

And now the deck itself can be generated. You describe what the slides should contain, what analysis sits behind them, what the house style is, and the thing gets built. The scarce input used to be the person who knows the template, and now it is knowing what the deck should say.

That is four stages, and each one dissolved the constraint that defined the one before.

The quarterly report

The same shape turns up in the other thing I do. I run a small fund, and every quarter it owes its investors a view of the portfolio.

The old version of that job was mostly chasing. Write to each company, ask for their numbers and their news, wait. Some reply with a tidy deck, some with three lines in an email, some with a spreadsheet, some not until you have asked twice. Then read all of it, work out what has changed since last quarter, write it up company by company, assemble, check, send.

The first part to get fixed was the asking, before any of the writing. A standard request, on a standard cadence, through one channel, so that what arrives is already in a usable shape. That is the same move as putting the deck in shared storage. The work is no easier to do, but the inputs arrive somewhere you can find them.

What has changed more recently is everything after that: reading each company's update against the last one and pulling out what is materially different, drafting the section, and flagging the developments a reader who skimmed last quarter would want pointed at. What lands now is a draft with the changes already surfaced. What is left is the part that was always the job: deciding what it means, deciding how to write about the things that are not going well, and putting my name on it.

It is the same arc, in a field with nothing in common with the first one except that both end in a document somebody has to stand behind.

The code

Software is new to me. I have been building for about a year, and nearly everything I know about how engineering teams worked before that I have picked up from developer friends and colleagues over the last few months. Usually I ran into a problem and somebody told me it had a name, a standard answer, and a thirty-year history behind it.

What struck me, hearing it, is how closely their story matches the one above. It is the same problem and the same sequence, except that it started earlier, went further, and solved the merge properly rather than routing around it.

Version control did what shared storage never did for documents. Instead of locking a file so only one person could hold it, it let everybody work simultaneously on their own copy and then combined the results, line by line, automatically. Where two people had changed the same lines, it stopped and asked. Git, which is now most of the world's answer to this, arrived in 2005 and made branching so cheap that working in parallel became the default rather than the exception.

A whole social apparatus grew on top of that: propose a change, have somebody read it, run the tests automatically, then merge it into the shared trunk. That process is the reason large numbers of engineers can work on one codebase without it dissolving.

The reason this worked when the document world's equivalent never quite did is that code is text, and text merges. Two people editing different functions in the same file produce a result a machine can combine with confidence. Two people restyling the same slide do not.

What these stories have in common

In every stage of all three, the expensive part was producing the work: writing the slide, writing the function. All the tooling (the shared drive, the co-authoring, the branch, the pull request) was scaffolding around a slow authoring step, designed to let several slow authors work at once without destroying each other's output. That assumption no longer holds, and nobody announced it.

When an agent can produce a working change in a few minutes, authoring stops being the constraint. Every process built around the old constraint starts behaving strangely. It does not break outright, which would be easier to notice. It strains in ways that look at first like ordinary friction.

Main keeps moving

This is the specific problem we are living with right now.

There are several sessions running at the same time. Each is working on its own branch, each is fast, and each formed its plan by looking at the shared trunk at the moment it started. None of them can see what the others are about to land.

So by the time one finishes, the ground it was standing on has moved. The change is correct against the trunk as it was forty minutes ago and conflicts with the trunk as it is now. Nobody did anything wrong; three other pieces of correct work arrived in the meantime. The conflict then has to be resolved, which takes a person, and the person is now the slow step.

The underlying assumption in the whole branch-and-merge model is that divergence is slow: you take a branch, you work for a day or two, the trunk drifts a little, you reconcile a little. That assumption held for twenty years because writing the code took a day or two. It does not hold when the work takes twenty minutes and four of them are happening at once.

This puts us somewhere I did not expect, and it is the reason I started with the decks. Consulting had parallel authoring and paid for it with a person whose job was to reconcile the results. Version control automated that person away. The great achievement of the last twenty years of software collaboration is that nobody has to be the project manager of the codebase. What has happened this year is that production got fast enough to overwhelm the automated integrator, and a human is back in the merge seat, doing by hand what the tools can no longer finish. So the constraint has moved again, to a place the current tools were not built for.

Git did not get this wrong. It was designed for human latency, and human latency is what it got. What changed is the ratio between how fast work is produced and how fast it can be integrated. When that ratio moves far enough, a process that was comfortable becomes the bottleneck without anyone changing it.

What we are trying

We have not proved a method, so I will describe a direction.

The direction is that coordination has to become explicit in a way it never needed to be before. Before a piece of work is merged, something should check what else is in flight: what other sessions are touching, what is about to land, and whether the plan formed forty minutes ago still makes sense against the trunk as it will be. Some of that is a discipline a person can hold. More of it, I suspect, has to be automated, because the thing that made the problem is speed and a manual check does not scale with speed.

We are working on it now. It is not solved, and I do not think we are unusual in that. My guess is that a lot of teams are quietly discovering the same thing this year and describing it as merge pain rather than as a structural change in where the constraint sits.

The pattern

Every generation of tooling in all three of these stories made the previously expensive step cheap, and so promoted something else to being the expensive step.

Storage made distribution cheap, and combining stayed expensive. Version control then made combining cheap for code, which left producing as the slow part. Now agentic tools have made producing cheap, and what is expensive is coordination: knowing what everyone else is doing, deciding what should be done at all, and integrating a volume of finished work that nobody has had to integrate at this rate before.

I keep arriving at the same place from the other direction, writing about the water sector: when reading and assembling stop being expensive, the scarce thing becomes judgment. The bottleneck moves up the stack, toward the part that is hardest to automate, and the tools built around the old bottleneck need rethinking rather than tuning.

Adopting these tools was the easy part. At AquaIntel we are now working on that coordination step itself: a check, before anything merges, of what else is in flight and whether the plan still holds.