← All posts AI

The Best Software Is Built Closest to the Need

Published September 11, 2026 · 4 min read

Give a salesperson a way to build their own tool and they often build a better one than the team that builds software for a living. Not better engineered. Better fit. The reason is distance, and agents are about to change what that distance costs.

Give a salesperson a way to build their own software and they will often end up with a better tool than the team that builds software for a living would have made them. Not better engineered. Better fit. It does the specific thing they need, the way they need it, because the person who knew what “good” meant is the same person who built it.

The reason is distance. A salesperson knows the two fields they check before every call, the one number that tells them a deal is going cold, the step they repeat forty times a day and wish they didn’t. Most of that lives in their head, unspoken, and half of it is never written down anywhere. When they build for themselves, it goes straight into the tool. Nothing is lost on the way, because there is no way.

Now put the usual chain back. The salesperson explains what they want to a business analyst. The analyst writes it up. A product manager shapes it into a backlog. A developer, three or four handoffs from the original need, builds it. Each step is one person decoding someone else’s words and re-encoding them in their own. The specification is a compressed version of a picture in one person’s head, and no two people decompress it the same way. What ships is an answer to a question that drifted a little at every step.

The same request drifts at each handoff until the point is lost; the agent path keeps it intact.

None of this was for lack of trying. Software had to be written by people who could write software, and the person with the need usually was not one of them, so the chain existed because the specialist sat at its end. We spent two decades trying to shorten it anyway. Agile put the customer back in the room. Extreme Programming went furthest, making an on-site customer part of the team so the need could be corrected constantly instead of once at the start. It helped, but it never closed the gap, for two reasons. Putting the picture in your head into words is genuinely hard. And you often do not know what you need, or how it should work, until you have something in front of you to use. The requirement is not sitting there fully formed, waiting to be captured. It emerges as you use the thing, which is exactly the moment the old chain reaches you last.

Agents change that. When the person with the need can describe it and get working software back, the specialist in the middle stops being mandatory for a whole class of software. The distance can fall toward zero, the way it does when the salesperson builds their own tool, except now they do not have to learn to code first. This is the quiet half of the argument in Paul Dix’s “The End of Programming”: everyone notices the code getting written faster, fewer people notice that the need no longer has to travel so far to become software. And because building is now cheap, you can get something in front of you fast enough to discover what you actually needed, which is the part the old chain always made you wait longest for. Speed is the obvious win. Fit is the one that matters more.

It does not fully collapse, and it should not always. The knowledge-holder still has to say what “good” means clearly enough for the agent to hit it, and saying it clearly is a hard problem in its own right, worth its own piece. Some software is shared infrastructure that a hundred people depend on, and you do not want each of them quietly building a private version of it. You can see the shape forming already: when Salesforce tied Claude into its platform in 2026, the data model, the permissions and the governed actions stayed central, and the agent generated the dashboards and apps on top. The base holds; the layer above it is what turns personal. But for the long tail of tools that exist to serve one team’s specific need, the old trade-off is loosening.

So the advantage moves toward the organizations that shorten the distance between the person who knows and the thing that gets built, and away from the ones whose reflex is to add another layer of translation to be safe. The best software was always going to be built closest to the need. For most of the history of software, we just could not afford to build it there.

AIEngineeringProduct

Comments

No comments yet — be the first.