The flat line problem: why your best engineers keep arguing about process

Mon, 12 Oct 2026 00:00:00 +0000

October 12th 2026. By lunchtime today my Claude Code sessions had run 77 agents, up to 19 of them at the same time. A lot of my day is now writing specs, reviewing what agents built, and deciding what they are allowed to do on their own.

This year we also changed how we build: AI pods. One engineer and one product person, two engineers at most.

I think pods make Simon Wardley's pioneers, settlers and town planners easier to set up than ever. They also make one old problem a lot more expensive. I call it the flat line.

Your best engineers keep arguing about how much process is normal. They are both right, and that is exactly the problem.

01Monday, architecture review

One item on the agenda. Your largest customer's AI agents already use your MCP server to look things up. Now the customer wants those agents doing whole jobs inside your product, with nobody watching, and they want a pilot running next month. The renewal depends on it. Nobody in your market has shipped that yet. With Claude Code, one pod could have a first version running by Wednesday.

Four people react. Nobody is wrong, and nobody says no.

The meeting Nobody in this room is being difficult. All four are right, about different kinds of work.

Three weeks later the customer has stopped asking. And every pod still deploys its own way.

Two problems in the same room, pointing in opposite directions. The new thing got too many rules. The routine thing got too few.

02So whose fault is it?

I'd blame the rulebook.

The same engineering rulebook got applied to two completely different kinds of work, the agent pilot and the deploys. It can only ever be right about one of them.

(Some might say the pod engineer is a cowboy, the manager is a process person, architecture review is slow, and the PM doesn't understand engineering. Sure, but then how were all four of them right on Monday?)

One rulebook All three of these at once, to different parts of the same org.

03Sixteen things your people did this week

Nothing unusual. An ordinary week, sorted the way you already think about it: by who does it.

Product pods

Write the spec, then let Claude Code build it
Review the agents' pull requests
Fix bugs from support tickets, with an agent
Deploy through the pipeline

Engineering managers

Check delivery numbers and token spend
Run planning and the retro
Coach engineers on working with agents
Staff the pods and the on-call rota

Staff engineers & leadership

Design each core service
Agree the quarter's bets with product
Decide what agents may ship without a human, and why
Let customers' agents do whole jobs in the product

Platform pod

Build the agent setup every pod shares
Let agents run a whole roadmap unattended

SRE & IT

Patch servers and rotate secrets
Model APIs, cloud accounts, laptops, SSO

Hold on to this list. Everything below uses these sixteen and nothing else.

04Five things that keep happening

Here are five more you have probably said or heard this year.

We had a good idea for a new kind of integration, and a pod had a first version working in two days. It went to architecture review, they asked for the design doc, and it quietly disappeared.

Nobody was against it. It still died.

That agent workflow one pod built, the one everybody liked? Still that one pod's thing. Six months now.

It works. It just never became the normal way we do things.

Every pod writes its own CLAUDE.md and its own agent rules, and every pod has its own idea of what an agent may ship without a human.

We keep starting over instead of agreeing one way.

The deploy pipeline is still being “improved”. It has been rewritten five times, twice by an agent.

Nobody should be thinking about this at all by now.

The same three people review every risky agent pull request and join every incident call, and they are exhausted.

And they are the ones who never complain.

All five have the same cause.

05Sort the same sixteen a different way

This time I sorted them by how new each thing still is to the world. It goes from work no one has really figured out yet, on the left, to things like electricity on the far right, which you buy and never think about. (If you map, these are Wardley's four stages of evolution.)

1 · Brand new

Nobody knows how yet (genesis)

Let customers' agents do whole jobs in the productStaff & leadership
Let agents run a whole roadmap unattendedPlatform pod

2 · We build our own

Everyone makes their own version (custom-built)

Decide what agents may ship without a human, and whyStaff & leadership
Design each core serviceStaff & leadership
Agree the quarter's bets with productStaff & leadership
Build the agent setup every pod sharesPlatform pod
Coach engineers on working with agentsEngineering managers

3 · The proven way

Already solved, so copy it (product)

Write the spec, then let Claude Code build itProduct pods
Review the agents' pull requestsProduct pods
Fix bugs from support tickets, with an agentProduct pods
Check delivery numbers and token spendEngineering managers
Run planning and the retroEngineering managers
Staff the pods and the on-call rotaEngineering managers

4 · Boring and cheap

It should just happen, every time (commodity)

Deploy through the pipelineProduct pods
Patch servers and rotate secretsSRE & IT
Model APIs, cloud accounts, laptops, SSOSRE & IT

brand newboring and cheap

Column 3 is where the method is already solved, and you copy it exactly. The industry knows by now how a good review of an agent's pull request goes. An AI reviewer reads it first, and anything risky goes to a person as well. (The tools behind it, Claude Code, the AI reviewer, the CI service and the pager, you do literally buy.)

The six things in column 3 are most of what your week actually looks like. Going by the grey tags, four of your five groups are split across two columns, and only SRE & IT stay in one.

The same goes for single words. “Ship” sits in three columns at once.

“Ship this to one customer, this week”

Column 1 · brand new

A one-off behind a flag, because you want to learn something from that customer.
Judgement call each time. I would not even try to write rules for it.

“What an agent may ship without a human, and why”

Column 2 · we build our own

Your own framework, written down. It says which paths an agent may change alone, and who signs off on anything above a certain risk level.
Every pod uses the same one, and it gets reviewed once a quarter.

“Ship it the agreed way, through the pipeline”

Column 4 · boring and cheap

Strict, identical steps every time, even when a pod is in a hurry, so a deploy never needs a meeting.

These three need very different amounts of rules, so I do not see how a single answer to “how we ship” can be right for more than one of them.

06Now compare the two ends

Take one thing from the far left and one from the far right of that list, and ask the same five questions about both.

Question	Letting agents run a whole roadmap unattended	Deploying through the pipeline
Has anyone done this before?	A handful of teams	Every engineering org there is
Will it look the same in six months?	Certainly not	It had better
If it goes wrong on Tuesday?	You throw away a branch	Customers notice before you do
Fastest way to make it better	Try five versions, drop four	Agree one way and stop touching it
Fastest way to ruin it	Agree one way and stop touching it	Try five versions, drop four

Read the last two rows. The same sentence appears on both sides, once as the cure and once as the poison.

07So each column needs a different amount of rules

Here are the four columns again, as four bars, with a few of your sixteen under each. A taller bar means: this needs more rules, more checking, more “do it exactly this way”. Nothing else is being measured.

Picture 1 Nobody argues with this on its own. Deploying through the pipeline obviously needs stricter rules than building something nobody has built. The problem starts in the next picture.

08One rulebook, three ways to be wrong

“Our engineering culture” means one way of working for everybody. On the picture, that is one straight line drawn across all four bars.

Wherever a bar pokes above the line, that work has too few rules. Wherever there is empty space between the top of a bar and the line, that work has too many. The striped areas are the mistakes.

Picture 2 Three different engineering cultures, drawn the same way. In every one of them, one bar out of four fits and the other three are wrong, because the bars form a staircase and a rulebook is a straight line. There is no height that works.

A staircase cannot be covered by one straight line.

You can reorg twice, and the line will still be straight.

09Which is why you need three kinds of people

Would you hand the deploy pipeline to the pod engineer who asked for one pod and two days? I would not.

I think most engineers are at their best in one or two of the four columns. That pod engineer is happiest in column 1, with a first version running by Wednesday. The pipeline needs someone like an SRE, because a mess there costs money, usually at 3am. Most of your people are probably somewhere in between.

Simon Wardley calls the three kinds of people pioneers, settlers and town planners.

Pioneers

Columns 1 and 2

Usually: you, on a brand-new bet · the pod engineer who prototypes everything · an R&D pod · the engineer who built their own agent workflow, and it worked
They go first, and most attempts fail, which is normal for them. They hate approval forms and “wait for next planning”.
Should own: customers' agents doing jobs, unattended agent roadmaps

Settlers

Columns 2 and 3

Usually: product pods on a growing product · tech leads · the platform pod · engineering managers
Good at taking something half-finished and making it work the same way twice.
Their version 2 is better than version 1, so being made to freeze too early drives them mad.
Should own: what agents may ship alone, service design, the shared agent setup, coaching

Town planners

Columns 3 and 4

Usually: SRE · infrastructure and IT · security operations · build and release engineering
They want the identical result every single time, as cheaply as possible, and get nervous the moment someone says “we will decide later”.
Should own: the deploy pipeline, patching and secrets, model APIs and laptops

10Why I think AI pods make this easier

Simon Wardley ran pioneers, settlers and town planners as small cells back in 2005. Most engineering orgs never did, and I suspect team size is a big part of why. A team of six or eight engineers had all three kinds of people in it and worked in all four columns. When the deploy pipeline needed stricter rules, the engineer prototyping something new got them too.

Our pods are one engineer and one product person, two engineers at most, and agents do much of the building. My bet is that a pod that small can be one of the three groups on its own and follow only the rules its column needs.

We have not tried that yet.

If the agent pilot from the Monday meeting started in a pioneer pod, a settler pod would take it over once it worked. The pioneer pod would move on to the next bet, still under the same few rules.

Picture 3 If each pod sat in one column, the rulebook (the solid line on the right) could step up column by column, like the bars in Picture 1.

11And why the flat line costs more than ever

Agents multiply whatever the flat line gets wrong.

Too many rules on column 1: a pioneer pod with Claude Code can build three versions of the agent pilot while the architecture review is still waiting for a design doc nobody can write yet.
Too few rules on column 4: the same agents push far more changes through the pipeline than a team typing by hand ever did. By lunchtime today I had run up to 19 at the same time, on my own. A loose rulebook that held for people typing does not hold for that.
More pods, more mismatches: ten pods instead of two teams means ten places where the line can be wrong, and the rulebook is often the only thing they share.
The rules are code now: agent permissions, hooks and required checks. Make one shared settings file strict, and a pioneer pod's agents stop to ask before every command. Make it loose, and a town planner pod's agents can change the deploy pipeline without a single check.

The drift that section 13 shows got faster too. Two years ago, writing code with an agent was column 1. The surveys since then:

October 2025 · Sonar

25%of developers used AI agents regularly

39%more had tried them

State of Code survey, 1,149 developers

May to July 2026 · JetBrains

90%used AI coding agents at work every week

68%used them every day

Developer Ecosystem survey, more than 15,000 developers

Different surveys and different questions, but either way that is column 3.

Running several agents in parallel moved just as fast. I could not find a survey that counts it yet. The closest is a small one, where 65% of 40 engineers use two coding agents every day. Letting them run a whole roadmap unattended is today's column 1.

The model underneath is already column 4. You buy it by the token, like electricity, from a few suppliers big enough that one of them, Anthropic, is getting ready to go public.

12Why the pilot is still a pilot

This is complaint 2 from section 04.

Work moves to the next column when the next pod decides it is ready and takes it. The pod that built it never thinks it is ready, so the next pod has to overrule it.

That is an argument between people who want different things, and an argument is exactly what one shared culture is built to avoid. So it never happens, and the pilot stays a pilot while everyone says nice things about it.

With agents, a pioneer pod can produce a working pilot in days. If nobody owns the handover, pilots pile up faster than anyone can take them.

Picture 4 The difference between the two sides is two arrows. Take away the border between the pods and the work stops moving, because the border was the thing that moved it.

13And every year it gets worse

Your sixteen things do not stay in their columns. They drift to the right, at a speed the industry decides, and agents made that speed a lot higher. A rulebook written into CLAUDE.md files, hooks and required checks does not drift anywhere, and the agents keep following it long after the work has moved.

Each square below is one of the sixteen. Watch them move right while the line stays where it was.

Picture 5 Nothing moved to the left. Nothing ever does. This used to take a decade. Writing code with an agent went from column 1 to column 3 in about two years. The bill comes all at once, usually the year someone turns the thing you built by hand into a service you can buy.

14Do your numbers show any of this?

Probably not the ones you already collect.

I have not seen your dashboards, but one shared culture is pleasant to work in, and those numbers say so. I think that is why the flat line lasts for years.

What you measure	What you probably see	Shows the problem?
Code shipped per engineer, with agents	Going up	No
Engineers staying on the team	Fine	No
Arguments in design reviews	Hardly any	No
People feel safe asking for help	High	No
People feel safe disagreeing out loud	Low, and nobody asks	Yes
Revenue from products you did not have 3 years ago	Almost zero	Yes
Pilots that became the normal way of working	None	Yes
Processes and tools you retired last year	Zero	Yes
How much depends on the same few people	Almost everything	Yes

15In practice: the same sixteen things

Back to where we started. The whole idea, applied to your own list.

Column	Your things	Who should own it	What good looks like	What kills it
1 · Brand new	Customers' agents doing whole jobs · unattended agent roadmaps	Pioneer pods	Three attempts, two fail, you know within a month	Asking for the design doc
2 · We build our own	What agents may ship without a human · each core service's design · the quarter's bets · the shared agent setup · coaching on agents	Settler pods	One version, written down once, used by every pod	Letting every pod invent its own again
3 · The proven way	Spec first, then Claude Code · reviewing agent pull requests · bug fixes · delivery and token numbers · planning and the retro · staffing pods and on-call	Settler pods	Every pod does it the same proven way, and stops redesigning it	Redesigning review or on-call “because we are special”
4 · Boring and cheap	Deploying through the pipeline · patching and secrets · model APIs, cloud accounts, laptops, SSO	Town planner pods	It runs, it is cheap, you never think about it	Still “improving” it every year

Read the last column down. Three of those four are complaints 1, 3 and 4 from section 04, and each one now has a cause you can do something about.

16What this does for the people

A good engineer in the wrong column starts to look like a difficult one. They usually feel it before you do.

Picture 6 Both rows are the same three people, first in their own column, then in somebody else's.

Some of the people who keep rewriting your deploy pipeline are, I suspect, pioneers who were never given anything new to work on. The agent pilot could use them.

Town planners remove surprises for a living, because in column 4 a surprise means an outage. If one of them ends up on that pilot, their usual questions (what happens when it fails, how do we roll it back) will get “we do not know yet” for weeks, and they will be miserable.

A team of eight could carry one person in the wrong column for a long time, mostly without anyone saying it out loud. In a pod of two, that person is half the pod.

And the Monday meeting in section 01 stops being about character, about who is “resistant to change” and who is “not detail-oriented”. The same goes for the engineer who waits to be given a task and says “Just tell me what to do”. In column 4 that is the right thing to ask, because the task is already known. On the agent pilot, which is column 1, there is no task to hand over yet, so it is the wrong request.

↳What to do on Monday

Find out who is who. Before anything else. For each person on your team, which of the three are they? Do not guess from their title. Ask them what a bad week looks like. “Nobody told me what was expected” and “I was not allowed to try anything” are two different people.
Make your own version of section 05. One afternoon with your staff engineers, your managers and your real list of work.
Give each pod one column, and each column its own rules. If a spike for the agent pilot and a change to the deploy pipeline go through the same review, you have one rulebook, whatever the org chart says.
Let the receiving pod say when something is ready. Write down what “ready” means. Expect the pod that built it to complain. Do not settle it by getting everyone to agree.
Write the agents' rules per column too. A pioneer pod's agents can try anything inside a sandbox with no production credentials. A town planner pod's agents get narrow permissions, hooks and required checks before anything reaches production.
Find out who every process runs through. That is complaint 5 from section 04. In any other system you would call it a single point of failure.
Start measuring the bottom five rows of the table in section 14. Especially the first: feeling safe to ask for help and feeling safe to disagree are two different things.

The Honest Assessment

Works best for:

Process fights that keep coming back: the same argument about reviews, approvals or RFCs, with the same people on the same sides every quarter.
Orgs that already work in small pods: the pod is the unit you place in a column, so the fix is a staffing decision instead of a reorg.
Orgs where most of the week is column 3 and 4 work: the few new bets suffocate under rules that were written for the pipeline.
Deciding what to stop: it shows which rules to remove, as well as which to add.

Struggles with:

Very small companies: when the same three people work in every column, there is nobody to split the work between.
On-call in a pod of two: a town planner pod of one or two engineers cannot carry a round-the-clock rota alone. Column 4 needs several pods, or a rota across them.
Agents blur the columns: a pioneer pod's prototype can look production-ready on day two. Calling it column 1 anyway takes discipline.
Placing the work: the picture assumes you know which column something is in. Agreeing on that is often the hardest conversation of all.
What one culture buys: people trust each other faster, new engineers learn quicker, fewer people leave. Those are real. The pictures only draw the price.
A class system: the moment pioneer pods look glamorous and town planner pods look like bureaucrats, three groups do more harm than good. All three are equally skilled and equally needed.
The bars are a drawing: “how many rules this needs” is not a number you can measure precisely. The bars make an idea visible, and that is all they do.

Before you add or remove a rule, ask which column the work is in.

The four columns (genesis, custom-built, product and commodity), the three kinds of people and the idea that each group takes work from the one before it come from Simon Wardley's work, published under CC BY-SA. The wording, the examples and any mistakes are mine.

Links:

What's your experience? Have you tried AI pods, or giving each column its own rules? Really curious what did work (and what didn't) for others. This landscape is constantly evolving, and I suspect there are and will be better approaches we haven't discovered yet.

Find me on X if you want to share your experiments or challenge my assumptions.

Claude-Code on simalexan