Draft: The Faros Whiplash and The Systems View

The Faros report on AI-assisted development has been rattling around in my head for a few days.

The story it tells is a strange one:

• Teams are producing more code. 
• More tasks are being completed. 
• More pull requests are being created. 

And yet :

• waiting times are up, 
• review times are up, 
• lead times are up, 
• incidents are up, and
•  bugs are up. 

The picture shows a development process that's getting busier without getting faster.

My first reaction was the same as everyone else's. Maybe the AI-generated code just isn't very good. The report certainly contains evidence that quality is suffering. But the more I looked at the numbers, the more I focused on waiting times.

I've spent enough years looking at value stream maps to have a habit of looking for queues.

A surprising amount of "developer behaviour" turns out to be queue behaviour in disguise.

• A review problem turns out to be a queue.
• An approval problem turns out to be a queue.
• A testing problem turns out to be a queue.
• A dependency problem often turns out to be several queues standing on each other's shoulders.

The Faros report shows that production increases dramatically, but review latency increases even more dramatically. More work enters the system, but much more seems to be waiting in it. People are touching more tasks, more pull requests, and switching context more often.

That doesn't look like a coding problem.

It looks like a system that has become better at starting work than finishing it.

I've seen something similar before in a non-agentic space: a feature gets split into several tickets. The database work goes one way. The service work goes another way. Somebody takes the UI. Somebody else takes the tests. Everybody is busy. If you walk around asking people how things are going, the answers are encouraging. Progress is being made everywhere. Each person's tickets are progressing...

...and yet the feature doesn't seem to finish.

There's always one more thing waiting for another thing.

• The API is ready, but the UI isn't.
• The UI is ready, but testing isn't.
• Testing is done, but deployment isn't.
• Deployment is done, but something failed and has come back.

Most of the feature's life was spent not being worked on at all. It was spent waiting for other pieces of itself.

Years ago I started thinking about that as a scatter-gather problem. We talk a lot about the scatter because that's the part where people expect to become productive. We don't spend nearly as much time talking about the gathering, which is where all the dependencies, assumptions, misunderstandings, and timing problems finally converge.

The moment we split the work, we also created a future obligation to put it back together, whether we realize that or not.

AI makes it easier to start work. In some cases, it makes it dramatically easier. A developer can explore more ideas, create more code, open more pull requests, and move more quickly from a blank screen to something that looks finished.

The phrase "looks finished" may be doing a lot of work there. It runs up some metrics. The cycle time is faster, the ticket closure rate is up, the per-person "velocity" (for the gullible who track such things) goes up.

Because software has a peculiar property. A thing can be finished locally and unfinished globally at the same time. Tickets are not features, after all.

• The code exists.
• The feature doesn't.
• The branch exists.
• The product doesn't.
• The ticket is done.
• The value isn't.

More code was being written, but the downstream parts of the system seemed were struggling. The system appeared to be accumulating inventory faster than it could absorb it.

If that's what's happening, then the interesting question isn't whether AI writes good code. The interesting question is whether coding was ever the limiting constraint in the first place.

That's a different question entirely.

The Theory of Constraints tells us that accelerating a non-constraint creates inventory. 

Reinertsen tells us that inventory increases lead time. 

Little's Law tells us that increasing work in process has consequences, whether we acknowledge them or not.

The Faros findings don't prove any of those explanations; they only make them hard to ignore.

Why Collaboration?

Suppose the work is highly dependent. Suppose we're building a feature that spans a service, a database, a UI, tests, deployment, and a few things nobody remembered to mention during planning. We can divide that work and coordinate later, or we can coordinate earlier and divide less of it.

Neither choice eliminates coordination.

The coordination exists either way.

The difference is when it happens, where it happens, and what happens while we're waiting for it.

That's why I have a hard time seeing collaborative work as a mere preference. In some situations, it probably is. If we're updating unrelated websites, there may be little reason to work together.

But software delivery systems are full of work that appears independent until it encounters a shared constraint.

• A reviewer.
• An environment.
• A deployment.
• A test suite.
• An integration point.
• A customer.

By the time those dependencies become visible, the economics have already changed.

The story may not be that AI is making developers less effective. It may be that AI is exposing parts of the system that were already limiting flow. If that's true, then the results in the Faros report are to be expected, and possibly inevitable.

At some point, the conversation must stop being about code and start being about the system that surrounds the code.

That's usually where we start looking.