When building stops being the hard part

AI made building software cheap enough that ideas no longer get killed by the cost of developing them. Every idea now survives long enough to become a real question, and someone has to decide it. Building the thing takes a weekend. Deciding whether it deserves one is the genuinely hard part, and the part that stayed expensive.

We recently shipped cost attribution for our AI traffic. Every application calling a model sends a couple of headers naming the app and the team, the gateway stamps those onto the cloud credentials, and finance can slice the model bill by team straight from the cloud provider’s cost report. It works. And the moment it worked, the next question arrived, the way it always does now: why are we trusting a header? Any app can put anything in a header. If this number is going to drive chargeback, should identity come from the directory service?

Here is the thing about that next step. Building it is a weekend. The gateway already sees every request; wiring it to validate the caller against the directory instead of believing a string is the kind of task that used to be a quarter of integration work and is now a focused couple of days with an assistant that has read every directory API ever published. Deciding whether to build it is the part that got no cheaper. Does the threat model actually justify it, or is a misattributed invoice line self-correcting the first time a team disputes its bill? What does a directory lookup on the request path do to latency, and who eats that? Who owns the group mappings when they drift, because they will drift, and a chargeback report built on stale mappings is worse than one built on honest headers. None of that is engineering. All of it is the job.

The constraint moved

For most of my career the expensive part of software was making it exist. Estimates were the currency of every planning meeting, and the estimate did a second job nobody thanked it for: it made decisions on its own. Most ideas and proposals died on contact. Too expensive to build was a filtering service that engineering cost provided for free, and it meant that the ideas that survived had already been through a crude but real prioritization. Nobody had to exercise judgment about the ideas that never made it to the whiteboard.

AI collapsed the cost of making things exist, and the filter went with it. Nothing dies on contact with the estimate anymore, because the estimate is a weekend. Every should-we survives long enough to become an actual question, and questions do not answer themselves; they land on people. This is what the liberation actually feels like from inside: not that you can finally build everything, but that you now have to have an opinion about everything, because nothing gets decided for you by being infeasible.

So the constraint moved. Engineering got cheap. Judgment did not, and there is no model release on any roadmap that makes it cheap, because the inputs to these decisions are not in the training data: what counts as a real threat here, how much latency the system can absorb, who owns what in the organization, and which team will still own a mapping table in two years. The assistant can build against all of these, but it holds none of them. The people who do are suddenly the bottleneck on everything, without ever asking to be. To be clear about the scope of that claim: it is about the systems that exist and the roadmaps that are public, not about what is possible in principle. If the deciding part ever does get cheap, that will be a far bigger event than the building part getting cheap, and most of this essay becomes obsolete on that day.

What the judgment is actually made of

It is worth being concrete about what these decisions contain, because from a distance they look like taste and from inside they are closer to a checklist that nobody wrote down. The header question decomposes into four parts, and I keep meeting the same four parts everywhere. What is the failure we are defending against, and is it real or aesthetic? What does the defense cost at runtime, every request, forever? Who operates the thing as it drifts, because everything with a mapping table drifts? And what is the price of deferring, measured honestly, including the parts that cannot be backfilled later?

That last one is the sharpest. In the cost attribution write-up I said the real question is usually not whether to build, but how much to build now and how much to defer. Others have landed on the same ground from the team side: Pedro Tavares argues that writing code was never the bottleneck, that the expensive part was always reviewing it, reasoning about it, and owning it together, and none of that got faster. Very philosophical, I know. But in today’s reality, behind every technical question sits a deep philosophical one, and someone has to answer it, otherwise you stay where you are. What I underestimated when I wrote my version is how much bigger the question gets when building is cheap. Deferral used to be the default outcome, imposed by the backlog. Now it is a choice you have to actively make and defend, against a room that knows the thing could be running by Monday. Saying not yet to something buildable in a weekend takes more conviction than saying it to something buildable in a quarter, and it is the same words backed by less cover.

The same pattern, but at the level of whole systems

When we picked a gateway to put in front of our model traffic, the field was a managed API gateway we already ran, commercial AI gateways, and an open-source project moving fast but missing pieces we needed. The old version of this decision was mostly a build-versus-buy estimate, and the estimate usually decided it. The current version is almost pure judgment, because missing pieces are no longer a reason to walk away: closing a gap in an open-source project yourself is days of work now, something a small platform team could not have credibly planned around two years ago. The gap for us was cost attribution on shared routes, so I contributed the missing piece back to the project: a first pull request adding support for session tags, and a follow-up that lets each request stamp the app and team behind it onto the cloud credentials, so the bill can be sliced by the dimensions that actually matter. It took days, not a quarter. The code is the cheap part. Choosing which codebase deserves those days, whose review process you trust, and what you would do if the project stalled, that is the decision, and no part of it got any simpler.

It is worth saying what that looked like in practice, because it is the argument of this essay in one story. The judgment came first, and it was made in house, based on our own data and with the models doing real work in the analysis, which is its own small irony: the assistant helped us decide how to govern spend on the assistant. We concluded the organization is better off when the finance team sees exact, authoritative dollar amounts on AI spend inside the cloud provider’s own bill, not estimates reconstructed in a third-party platform. Making that call in house was not territorial. Platform work means holding the widest view of the organization, which teams run what, where the money goes, how the pieces connect; that is close to the definition of the job. A judgment that depends on that view can only be made by the people who hold it, so it followed, almost logically, that we were not going to let someone from outside walk in and make it for us. We evaluated several commercial products and chose to build toward the goal instead of waiting, partly on conviction: most of the software we run is open source, and we owe that commons more than we usually acknowledge. If there is one thing I am proud of in the people I work with, it is their critical thinking. It would have been easy to buy a dream; plenty are for sale right now. Nobody here bought one, and I came closest: one pitch was compelling enough that I nearly went under. The people around me are why nearly is the word. The pattern we bet on, attribution attached at the place you actually buy the thing, has since been showing up in more places and may be on its way to becoming the default, which is encouraging rather than the point. The point is what the work felt like. I argue in another essay that solving problems you believe in is the human part of this profession.

The attention moved too

There is a side of this story that saddens me, and I would rather name it than pretend the pattern has no cost. Since then, a whole department of AI developers grew up around us, out of a worthy and entirely legitimate desire not to be left behind. Nobody decided that the rest of the organization should wait; it happened the way these things happen, one urgent request at a time. But attention is a budget like any other, and lately it has gotten harder to give the teams that have been here longest the share of ours they deserve. The problems they bring are no less important. If anything, my view is they have earned a faster answer, not a slower one: they have spent years learning the organization, its needs, its limits, and its potential, each in their own specialty, and that depth is exactly the context this essay keeps calling the scarce thing. A queue sorted by novelty instead of by judgment is the mistake from the top of this essay, wearing different clothes.

Budgeting the scarce thing

I’m afraid I do not have a tidy framework to sell, and I am suspicious of anyone who says they have one. But a few practices have survived contact with this last, turbulent year. Treat decisions, not tickets, as the unit of planning: the question is no longer who has capacity to build, it is who has the context to decide, and that list is much shorter. And underneath every decision sit three questions that were always the real ones, though it used to be possible to ship for years without answering them: what are you building for, who are the people it is meant to serve, and what is the outcome you intend? Cheap building did not make those questions harder. It made them impossible to keep avoiding, because nothing else stands between an idea and production anymore. Write down every decision to defer something with the same seriousness you write down a commitment to build: what was deferred, why, and what would have to happen to revisit it. And let some problems stay unsolved on purpose; to my mind that is currently the most economically powerful move an organization can make in 2026. Solvable stopped being a reason. Everything is solvable; which is exactly why that argument does not justify doing anything on its own.

The header question, for what it is worth, is still open on our side. The enforcement would take a weekend, and we have not spent it, because the honest answer so far is that disputed invoice lines get caught by the people who read them, and a directory check would cost us response time on every request, plus one more component that needs an owner, before it gave us more reliable numbers. Coding assistants sharpen the point: the heaviest new callers live on developer machines, half person and half tool, and are tricky to bind to a directory identity. That may change, and when it does, building it will be the easy part. Though I am not sure that weekend will ever be ours to spend: watching the direction the industry is moving, I would not be surprised if identity verified at the source eventually arrives as part of the platform itself. A deferral that ends with someone else building the thing is the cheapest engineering there is. Which is exactly the point: the cost of building, that weekend, was never the consideration that actually decided anything. It only looked like the central one while building was hard.