What Happens When Software Becomes Easier to Build?

Every time the cost of building something falls sharply, the interesting question isn't what gets cheaper — it's what becomes scarce in relative terms once the old bottleneck disappears. Software is in the middle of exactly that shift: writing code, the thing that used to be the primary constraint on building anything, is rapidly getting cheaper, faster and more accessible.

Fact: AI-assisted development tools have measurably lowered the skill and time threshold for producing working software, to the point where someone with limited traditional programming background can build a functional internal tool, prototype or simple product. This mirrors earlier shifts — high-level programming languages made assembly-level skill less necessary, cloud infrastructure made server management less necessary — except compressed into a much shorter timeframe and applying to a wider range of tasks at once.

What doesn't get cheaper

Three things stay scarce, and arguably become more valuable, once code itself is abundant. The first is knowing what to build — a clear, correct understanding of a real problem worth solving, which was never actually the bottleneck of typing syntax, and AI doesn't supply it. The second is taste — the judgement to know when something is actually good, not just functional, and to make the dozens of small decisions that separate a product people want to use from one that technically works. The third is trust — a track record, a reputation, a relationship with the people who'll actually use or pay for what's built, none of which can be generated on demand no matter how fast the code ships.

Analysis: this changes who competes with whom. When building software required years of specialised training, the competitive advantage was largely about who could build something at all. When building is cheap and fast for almost anyone, the competitive advantage shifts entirely to who has the better judgement about what to build, the better distribution to reach the people who need it, and the deeper understanding of the specific problem being solved. Two people can prompt the same AI tool with the same rough idea and get wildly different outcomes, because the gap moved from execution to everything surrounding it.

Opinion: the most likely losers from this shift aren't developers broadly — it's specifically the segment of software work that was valuable purely because it was slow and specialised, with no differentiated judgement attached: generic implementation work, commodity feature-building, the kind of project that was really just translating a spec into working code with no real product thinking involved. The most likely winners are people who already had strong judgement about a specific domain but were previously blocked from acting on it by not being able to build the software themselves.

Prediction, held loosely: as building gets cheaper, the interesting differentiation moves further upstream, toward problem selection and product taste, and further downstream, toward distribution and trust — the parts of the process that were always hardest to shortcut, just previously overshadowed by how hard and slow the middle part was. Expect a lot more software to get built, most of it forgettable, and the ability to tell which of it is actually worth using to become a more valuable skill than the ability to build it in the first place.