The Fleet Can't Read the Customer

Every input your agents have is downstream of a decision about what to build, made by someone they never met. A note on why proximity to the customer just became the compounding skill, and why twenty years of walling engineers off from it is now the liability.

By Jason Waldrip, with Claude Opus 4.8 August 7, 2026 08:33

It’s Tuesday. The board has ten cards on it. The fleet can build any one of them by lunch, and probably three of them by end of day. So the question that used to eat your week, can we build this, is already answered. Yes. All of it. Now what.

The hard part moved, and most orgs haven’t noticed where it went. For twenty years the scarce thing was throughput. Building software was slow and expensive, so every process we built was an answer to the same question: how do we get more code out the door per engineer. That’s a reasonable thing to optimize when the bottleneck is the building. It stops being reasonable the moment the building gets cheap.

And the building got cheap. Not a little cheaper. The floor fell out. A fleet of agents will now turn a clear spec into a working, tested branch faster than you can write the spec. If your whole operating model still assumes throughput is the constraint, you’re tuning the one thing that stopped mattering.

the customer got walled off, on purpose

Here’s the part that’s easy to miss because it happened so slowly. While we spent two decades optimizing for throughput, we quietly moved the engineer as far from the customer as the org chart would allow. Sales talks to the customer. Product talks to sales. A PM talks to product. And the engineer gets a Jira card, which is the customer’s actual problem after three rounds of translation, with the context sanded off.

That was defensible when building was the expensive step. You wanted your expensive people heads-down, shipping, not sitting in support queues. Protect the throughput. It made sense.

I came up the other way. I started at the edge, at a CDN, as a sales engineer. In the room with Blizzard and Disney and YouTube while they described what they actually needed, watching them wince at the thing that didn’t fit before anyone wrote a line to build it. Then I spent twenty years moving closer to owning the build. Sales engineer, product, QA, team lead, CTO. Every step was the same deliberate move: pair knowing what to build with the ability to actually build it. I thought I was climbing toward the code. What I was really doing was refusing to let go of the edge on the way up.

what your agents can read, and the one thing they can’t

Look at everything you can hand a fleet of agents. The repo, all of it, every file. The docs, if you kept them. The type signatures. The test suite. The commit history and the reasoning behind it, if your team wrote the why down. Point good agents at that and they will out-read any human on your team. They hold the whole system in context at once, which no person has ever been able to do.

Now name the one input that isn’t in any of that.

Every artifact I just listed is downstream of a decision somebody already made about what to build. The repo is the answer to a question. The tickets are the answer to a question. The API shape is the answer to a question. And the question came from a person, sitting somewhere, with a problem they mostly can’t articulate, who is not in your training data and is not on your board. The fleet can read the entire record of every decision you’ve ever made. It cannot sit in the sales call where the next one gets made.

the reframe

So the leverage inverted, and hardly anyone has repriced it. For twenty years, seniority meant moving up and away from the customer: edge, then architecture, then a title and a calendar full of meetings about the work instead of the work. The customer was for the junior folks and the support rotation. That direction was a promotion.

When building is free, that direction is a liability. The scarce, un-automatable input is knowing which of the ten cards is the one that matters, and that knowledge was never in the codebase. It’s in the room. The engineer who has been in that room can direct a fleet at the right target on the first try. The engineer three translations removed can direct it beautifully at the wrong one, and the fleet will build the wrong thing faster and cleaner than ever, which is worse, not better.

This is why the best software shops have always put engineers on support. 37signals has argued for decades that the people building the thing should feel the customer directly, and did it when everyone else called it a waste of expensive time. That looked like a values choice for years. It was a bet on exactly this: that the day building got cheap, the companies whose engineers already knew the customer would aim straight, and the ones who had optimized their engineers into a Jira feed would keep shipping polished answers to questions nobody asked.

get back to the edge

I’m not saying disband product or fire the PMs. I’m saying the twenty-year trend that treated distance from the customer as a mark of seniority is now backwards, and you can feel it if you’re honest about that board. You can build anything on it this afternoon. So can your competitor. The thing you can’t both do is know which one is worth building, and that isn’t a knowledge problem you solve by reading more of your own repo.

You solve it by getting back in the room. Sit in the support queue this week. Take the sales call you’d normally skip. Watch one real customer use the flow you shipped last month and say nothing while they fumble it. That hour is not a distraction from the engineering. In a world where the fleet does the building, it is the engineering.

What’s the last card you shipped because a real person needed it, versus because it was next on the board?