Cheap to Build: where the cost of building software actually went

A few months back I wrote about whether the senior engineering role still holds up three years into an organisation going deep on generative AI, especially in software engineering. One line in that piece that I've chewed on for a while and that I've continued to see is that the cost of building dropped significantly, but the cost of everything around it didn't. I originally added this as an observation about organisational alignment and moved on, but since then I've come round to thinking it's an important part of the story on its own, and that it reaches a good deal further than alignment does.

The part nobody argues with anymore is that building software has got cheaper. You can vibe-code a working prototype in an afternoon that would have been a fortnight of work three years ago, and for plenty of throwaway or exploratory cases the quality is good enough; it serves a purpose. The question that has mostly gone unasked, while everyone was busy being impressed by the demos, is whether cheaper building has actually produced better software. Three years in, across a company of four thousand engineers, my honest answer is no. It isn't simply a case of the tools not being good enough yet. I don't think the next model release changes the answer, because I don't think it's that kind of problem.

When the last piece went around, one comment stuck with me more than the others: a reader made the point that the vendors they buy software from now ship several times as many products as they used to, and that the products are noticeably worse in quality than before. That's the same thing I'm describing, seen from the buying side of the table rather than the building side. More is being built, and, unfortunately, less of it is "good". The drop in cost, effort and time has brought us volume, and somewhere along the line we assumed volume and quality would rise together, which they plainly haven't.

The cheap part

It's important to be mindful that what's changed about building software is substantial, and I'm not in any way nostalgic for the old way of doing things when it comes to my day-to-day role (although, a new hobby may be emerging in programming "the old way" which I'm trying out, similar to my previous attempt at programming nostalgia). Three years ago, testing an idea meant carving out real time: a proposal, some design, a few days of building to get to something concrete enough to react to that you could demonstrate to leaders, stakeholders and more. I remember spending a good month putting together a working proof of concept that demonstrated why I should pull together a team of 4-5 and spend 6-9 months building something at scale. Now, I can have a working version of an idea in front of people the same day I have it. There's no doubt, this is the part of the hype that's real.

Speed is the obvious advantage here, but the more interesting one is disposability. When a prototype costs an afternoon rather than a week, you stop being precious about it and what was "good enough" for a PoC becomes a lower bar. I've been known to build three versions of something to understand a problem from three angles and then bin all three, and that's a good trade rather than a wasteful one. You learn more from three cheap prototypes you're happy to throw away than from one expensive one you feel invested in defending. For the job of understanding a problem, this is better than what we had before.

And it isn't only me that sees this: across the company, product teams who'd previously have created a ticket or worked out complex requirements with a platform team and waited now build the thing themselves, because they can. Someone with an idea and a coding agent can get to a working proof of concept without waiting in a queue or needing a prioritisation call, without a sprint, without asking anyone's permission. This is a healthy redistribution of who gets to build, because these product teams understand the problem they're facing, and they can prove the value they'd get from a solution quickly without interrupting their wider mission. More people can turn an idea into something you can actually try, and that used to be a privilege reserved for whoever had engineering time to spare.

So nothing that follows is a complaint that the tools don't deliver, because they obviously do. But what happens after the prototype, after the first stab at a solution has been created? This is where the majority of the cost now hides.

Operational cost

The cost that didn't move is operational: building something got cheaper, but running it didn't, and running software is where most of the real cost has always sat.

The pattern I've seen and heard about most often goes like this: a product team has a problem, and rather than push their requirements back to a platform team, they build the thing themselves with a coding agent. It works, it's useful, and it gradually gets more and more adoption across the company. Up to here this is the healthy redistribution I described earlier and I see this as a wholly positive thing. This changes as the operational reality gradually arrives for the building team: the service needs supporting, scaling and extending, because more and more people now depend on it. It needs someone on call when it breaks during office hours, because it now breaks in ways that matter to other people. It needs security patching, dependency updates, access control, a clear answer on where the data sits and who's allowed to see it, and a person who understands it well enough to fix it when it's preventing another team from delivering during the middle of the day. None of that was in the proof of concept, because none of it is something you would ever demonstrate.

The team that built it didn't sign up to operate it forever: they had a nice idea, wanted to try something out and solve it for themselves and others, and now operating it is becoming a burden that prevents them from working on their primary purpose. This leads to them exploring whether it can be handed over, and the natural home is a platform team, because running things is what platform teams are for. Now a platform team is being asked to adopt and support something they didn't build, didn't design, and can't easily run alongside everything else they already own. This isn't just an engineering concern, this suddenly requires a product manager to understand their problem and the solution, and what demands and needs they've been meeting (or not) from their customers.

The internal developer platform is where this causes the biggest problems. Building on the platform got far faster: an agent can scaffold a service, wire up the boilerplate and get something deployable in a fraction of the time it used to take, but operating on the platform didn't get cheaper to match. The cost of running a service is roughly what it always was, and the number of services wanting to run has gone up, because more teams can now build more of them. The platform ends up absorbing more operational load, from more directions, produced faster than before, and often by people who built something without once thinking about how it would be run. Cheaper building didn't get rid of the operational cost, it just pushed it downstream, onto the people who operate rather than the people who build.

Greenfield is cheap, not brownfield

The obvious objection to all of this is that the models keep getting better, and quickly, so give it a release or two and the finishing problem sorts itself out. I'm not sure this is the case here, because although the models are improving, they're simply making the cheap part cheaper, not the part that actually matters.

If you take a step back and look at where each new model actually impresses you and you'll see that it's usually greenfield: starting something new, in a small or clean context, where the whole problem fits in front of the model at once. That's what the release demos show, because greenfield is what shows well and what's easy to judge in a five-minute video. It's also what the models are trained and measured on. The benchmarks are largely self-contained problems with a clear right answer, and success is judged in producing code that satisfies the task in front of it: generating something that looks right and passes the test now. Very little about how these models are built points them at the thing that actually costs money, which is a change that has to survive inside a large existing system for years.

The deeper reason is that most of the difficulty in brownfield work sits outside code generation entirely. The difficulty in an old, sprawling estate comes from the context that isn't written down anywhere: why something is built the way it is, what will quietly break three services away, and which undocumented assumption half the platform is silently relying on. A model works with what it's given, and the most expensive knowledge is the part that nobody ever wrote down, the learned knowledge that teams carry with them, or worse, that's already left with a previous engineer. A better model reads the code you do have more fluently, but that doesn't uncover the reasoning that never made it into the code in the first place.

To be fair, the models are getting better at working inside existing systems too: larger context windows, better at searching a repository, more able to hold a big codebase in view at once. But that improvement is still small compared to the jump in greenfield work, and it barely touches the most expensive part of brownfield, which is everything the code doesn't tell you. Each new release gets meaningfully faster at the greenfield work that was already cheap, and the operational cost from the last section stays roughly where it always was. That's why I don't think a better model closes this gap.

Organisational cost

When building is so cheap, building your own version is nearly always easier than finding, evaluating and adopting someone else's; doubly so in an enterprise where you have competition requirements, contract assessments, legal agreements and procurement processes. What you end up with is not convergence, but proliferation. Three teams hit the same problem and, rather than one of them solving it and the other two adopting it, all three build their own take, because building your own take is now an afternoon rather than a month. Each version is mostly-there, each is owned by the team that happened to build it, and none of them is the one everyone agrees to use. I've watched this happen with the same class of problem more than once, and the striking part is that everyone involved is acting reasonably: it genuinely is faster for each team to build their own than to go and integrate with a half-finished thing another team is quietly maintaining.

One of the more interesting parts of this dilemma is that the old cost of building used to do a job we never credited it for: it was a filter. You couldn't afford to build your own version of everything, so you were strongly encouraged to reuse, to converge, to adopt the thing that already existed even when it wasn't quite what you'd have built. The expense did the prioritisation for you, for free, and discouraged you from branching out on your own for the most part. Take the expense away and you take the filter away with it, now there's nothing stopping you from heading down your own road. Suddenly, there's no natural force pushing the engineers in a company toward one good version of a solution rather than five sub-optimal ones.

The resource that underpinned all of this, build capacity, suddenly didn't matter, as we now have a near-unlimited supply of that. What remains scarce is the judgement about what should exist, and the will to consolidate the overlaps and switch the duplicates off. That work is very difficult, especially as this isn't getting cheaper, because it's mostly a matter of getting people to agree and giving something up. Worse than that, switching something off is politically expensive once it has a team attached and a handful of users who'll be annoyed, so mostly nobody does it. There are other paths such as migration, winning hearts and minds or adapting the one solution to fit everyone's needs, all of which are more costly in effort, time and social capital. The estate grows a layer of overlapping, semi-owned, quietly load-bearing things that no one ever decided to have, and the cost of that isn't on any one team or area individually, which is exactly why it keeps growing. The obvious difference is that a small company doesn't feel any of this, and that's true: a startup with one product and eight engineers has nothing to converge and nothing to consolidate. But most software gets built, and most engineers work, in exactly the kind of large, long-lived technical organisation where this compounds over time, and that's the setting the productivity story keeps missing.

If there's a fix, it isn't more building capacity, because that's the thing we have too much of. It's whatever replaces the filter that cheap building removed: someone or something that owns the question of what should exist, and has the standing to make the duplicates converge and the dead things stop. That's coordination and ownership work, and that's the expensive, human, doesn't-get-cheaper kind of work again.

What this means

If you put these costs side by side, they turn out to be the same one. Operating a service, understanding an old estate, deciding what should exist and consolidating what shouldn't: none of this is a code generation problem. So far, the models haven't removed any of that cost, they've moved it and highlighted it, out of the part we could see and measure and into the parts we mostly can't.

This is the reality: cheaper building hasn't produced better software, and it wasn't ever going to on its own, because the expensive part of software was never the building of it in the first place. We just couldn't see that while the building was costly enough to dominate everything around it. Once we take the build cost down to near zero, what's left standing is everything that was always the hard part: making the thing maintainable, scalable, able to solve the right problem, supporting it, and deciding whether it should exist at all.

If the promise of generative AI in software engineering is going to come good, the cost has to start falling somewhere that actually matters. It has to get cheaper to verify that a change is right, not just to write it. It has to get cheaper to operate what we build, which means platforms an agent can run on and not only deploy to, and tooling that treats the operational reality as the main job rather than something you get to later. And, most importantly, it has to get cheaper, somehow, to make the calls about what should exist and to act on them, which is the least likely of the three, because it's the most human.

None of that is where the effort has gone so far. AI has spent three years making the cheap part cheaper, again and again, and getting very good at demonstrating it. The part that decides whether any of this produces better software, rather than just more of it, is the part almost nobody is working on. That's a gap, and an opportunity, and closing it is a good deal less exciting than another model that writes a prototype in an afternoon.