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

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.

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?

It is tempting to read all of this as character. The pod engineer is a cowboy, the manager is a process person, architecture review is slow, and the PM does not understand engineering.

What actually happened: one engineering rulebook was applied to two completely different kinds of work, and a single rulebook can only ever be right about one of them.

So we start with the work your engineers actually did this week, then the problems you already have, and only then the idea that explains both.

03Sixteen things your people did this week

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

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.

All five have the same cause.

05Sort the same sixteen a different way

Now sort them by how new the thing still is to the world, not by who does it. Left: nobody has really figured it out yet. Right: you buy it and never think about it, like electricity. (If you map, these are Wardley's four stages of evolution.)

Column 3 does not mean you buy all of it from a vendor. It means the method is already solved. The industry knows how a good review of an agent's pull request goes: an AI reviewer reads it first, and a person reads anything risky. So does your best engineer, and so does every competitor. Your job there is to copy the proven way exactly. (The tools behind it, Claude Code, the AI reviewer, the CI service and the pager, you do literally buy.)

Look at the small grey labels. Your product pods appear in two columns. Staff and leadership work appears in two. So do the platform pod and the managers. Four of your five groups sit in two columns, and the six things in column 3 are most of what your week actually looks like.

One word can sit in three columns at once. Take the word every engineer uses every day:

Three different amounts of rulebook, for one word. If your org has a single answer to “how we ship”, it is wrong about two of these three.

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.

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.

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.

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

A person who is brilliant in column 1 will find column 4 suffocating. A person who runs column 4 perfectly will look at column 1 and see a mess.

The SRE who wants a runbook for everything is right, for their column. Mess costs money where they work, usually at 3am. The pod engineer who prototypes everything is right about theirs: mess is where their work happens. Swap them and you will have two difficult employees and no idea why.

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

10Why AI pods make this easier than ever

Simon Wardley ran pioneers, settlers and town planners as small cells back in 2005. Most engineering orgs never did. A team of six or eight engineers held all three kinds of people and worked in all four columns, so changing the rules for one column meant changing them for the whole team.

AI pods change that. Ours are one engineer and one product person, two engineers at most, with agents doing much of the building. A pod is small enough to be one of the three groups: a pioneer pod, a settler pod or a town planner pod, each with the rules its column needs. Your pods probably still mix columns, like any team did. They do not have to.

The pods stay where they are, and the work moves. A pioneer pod finishes a first version. A settler pod takes it and makes it work for everyone. A town planner pod takes it from there and makes it cheap.

Give each pod one column, and each column its own rules.

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:

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.

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.

14And it feels wonderful the whole time

One shared culture makes the numbers you already collect look excellent. They are accurate, and they cannot see this problem.

When everyone agrees in every review, look for the handover that never happened.

15In practice: the same sixteen things

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

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

Put someone in the wrong column and you turn a good engineer into a difficult one, and they feel it before you do.

Rules take away the one thing pioneers are good at: finding out. Give them a pod in a column where nobody knows the answer yet, and the energy that went into rewriting the deploy pipeline a fifth time goes into the agent pilot instead.

The SRE who wants a runbook for everything is correct, for column 4, where a surprise is an outage. Put them on the agent pilot and they will ask for a design doc nobody can write yet, and they will be miserable doing it.

Pods make this impossible to hide. In a team of eight, one person in the wrong column gets carried by the others. In a pod of two, that person is half the pod.

And the Monday meeting in section 01 stops being about character. So does the engineer who waits for a task and says “Just tell me what to do”. That is the right request in column 4, where the task is known, and the wrong one in column 1, where nobody knows it yet. Show the whole team this page, and the engineer who wants a task and the pioneer who hates being given one will both recognise themselves.

Nobody has to be told they are “resistant to change” or “not detail-oriented” ever again.

↳What to do on Monday

1. 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.
2. Make your own version of section 05. One afternoon with your staff engineers, your managers and your real list of work.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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:

• Simon Wardley: On Pioneers, Settlers, Town Planners and Theft
• Anthropic: confidential draft S-1 submitted to the SEC (June 2026)
• Sonar: State of Code Developer Survey report 2026 (1,149 developers, October 2025)
• JetBrains Research: AI Coding Agents, Adoption Trends (Developer Ecosystem Survey 2026)
• AI Builder Club: a 40-engineer survey on running two coding agents (May 2026)