Coding is now cheap. It is not the bottleneck any more. All the agent-maxxers, and even those a couple of steps behind them, are more than familiar with this new reality and its implications. In the enterprise, where the perennial question is build-vs-buy, there is another way to frame this change: weighing the pain of configuring software against the pain of building it.

The entire enterprise software complex rests on one bedrock assumption: it is cheaper to buy a solution with a million knobs and dials and hire an IT department to turn them than to hire a team of SWEs to build that software in-house. Like all cost tradeoffs, there is a point where the two cost curves cross. Agents have drastically moved that crossover point, toward building.

The tradeoff can cut both ways: as a business scales, sometimes it becomes better to buy and sometimes better to build. Getting it right rests (like most things) on a clear-headed leader inside the enterprise who understands both their own business and the solution landscape well enough to pick the right point on the build-vs-buy spectrum. But it’s not just “build vs buy”. It is “build and maintain” vs “buy, configure, and change-manage”.

An example of moving from building in-house to buying from a vendor: Google ran a lot of its own internal people systems before eventually throwing in the towel and standardizing on Workday.

Going the other way, from buying to building: once a company grows big enough, its seat or usage bill with a vendor can grow large enough that you have to weigh it against the cost of an in-house SWE and devops team.

For most companies, an in-house SWE team used to be prohibitively expensive. But now that an in-house team that is agent-accelerated can do 10–100x what pre-AI SWEs could, the calculus changes entirely.

Agents as build plane — we’re all familiar with this. You spec what you need, the agent writes code, you try it, and you iterate. A less obvious enterprise implication is how small the thing you build can be. A vendor has to serve thousands of customers, each with slightly different requirements. You only have to serve your own business. What looks like replacing an enormous SaaS product might actually mean building three workflows, two integrations, and a report.

That also changes how you respond to a requirement that doesn’t quite fit. With a purchased product, you hunt for the right setting, write glue code, or change your process to accommodate the tool. With software you own, you can change the behavior directly. You still have to test it and maintain it. But the cost of expressing the change in code can now be lower than the cost of figuring out how to express it in somebody else’s configuration language.

One could argue that big-tent SaaS has diseconomies of scale, at least for its customers. It has so many knobs and dials precisely because it has to serve a large base. There’s that old line about Microsoft Word: “Everyone says they only use 5% of Word. The problem is, everyone uses a different 5%.” Joel Spolsky made the same point in his essay on the 80/20 myth: “it’s never the same 20%.” So every customer ends up shouldering the complexity burden of the entire base. Build for yourself, and you only need your own 5%.

Agents as control plane — this is the other half. Building software is one thing; operating it is another. An agent with access to the right CLIs, APIs, or MCP tools can become the interface through which you inspect and operate your systems. Instead of learning where a vendor has hidden every knob, you describe the outcome you want and have the agent work through the underlying tools.

Take cloud cost management. Google Cloud already lets you export detailed billing data to BigQuery. Give an agent access to that data, plus resource inventory and utilization metrics through gcloud (or the equivalent CLI on AWS or Azure), and ask: what drove last month’s increase? Which machines look oversized? Which idle resources are still costing money? Have it show the evidence, estimate savings, and propose changes for review. You may be able to answer your actual questions without buying and configuring a separate cloud cost management product.

The leverage comes from connecting the agent to rich data and useful operations. The same interface can investigate a bill, prepare a deployment, or trace a failed job. Recurring tasks can become scripts and saved workflows. We are moving from infrastructure-as-code toward prompts and skills (SKILL.md files) driving devops and infrastructure. The agent becomes the control plane for both the software you built and the services you bought. So agents don’t just lower the cost of building; they also lower the cost of operating and configuring. That moves both sides of the build-vs-buy equation.

Example: my blog used to run on Hugo, a static site generator. My content is all Markdown; I just needed something to render it to HTML through a good-looking template. Like all SSGs, Hugo has its own template language for this. Like all SSGs, Hugo also has a great collection of ready-made templates. I picked one and called it a day. When I wanted to make changes along the way, agents thankfully helped me out, because I had neither the time nor the inclination to learn the nuances of yet another templating language. And then it hit me — I don’t have to put up with the pain of config anymore. I can just vibecode the small subset of Hugo that I need.

That’s exactly what I did. The coding agent was also my control plane: it handled the entire publication lifecycle, from showing me a local preview of a new post to making it live on my real website. It also made sure the switch was invisible: the generated site was bit-identical before and after. So now I have 660 lines of Python publishing my site. Hugo has 173k lines of Go (81k of them tests). It turns out it was easier for me (i.e. my agent) to build the exact subset of Hugo I needed than to keep fighting all the knobs, dials, and config that Hugo exposes as its API.

The Emacs-ification of all software — what made Emacs so powerful was that configuration and extension lived in the same core. There was no hard boundary where configuring the tool ended and programming it began. The two are often confused, but they are very different.

Configuration gives you switches, knobs, and dials for the behavior the product designer anticipated you’d want to customize. Extension lets you add behavior they didn’t anticipate. The tool can keep changing shape as your needs change. Emacs made that possible for people willing to learn Lisp and spend time shaping their environment. That’s why it is the editor of a lifetime. Agents let you do that across your entire computing environment, that too with just natural language.

That’s what happened with my blog. I started by asking an agent to turn Hugo’s knobs, then realized it could build the little publishing system I actually wanted. The same question now applies to enterprise software: is it easier to configure this general-purpose product, or to build and operate the specific thing we need? For decades, the default answer was to configure. But the assumptions behind that default, and the costs that drove it, have shifted dramatically in just the last 12 months. It’s time to revisit the answer.