Software Doesn't Have a Coding Problem Anymore

For most of computing history, software had a coding problem, and the coding problem was so dominant that it shaped everything else. Writing software was hard, slow, and scarce. So we built an entire civilisation of tools, roles, rituals, and metrics around the central difficulty of producing code. This was not a mistake. It was a rational response to where the bottleneck genuinely was.

The bottleneck moved. The apparatus didn't. And that gap — between a discipline organised entirely around a coding problem and a reality where coding is no longer the problem — is the defining confusion of software right now.

Everything we built assumes coding is the hard part

Look at how a software organisation is actually constructed and you'll see the coding problem encoded into every layer of it. We hire primarily for the ability to produce code. We measure productivity in units of code — story points, commits, velocity. Our most prestigious roles are the ones closest to the hardest coding. Our tools optimise the writing, reviewing, testing, and shipping of code. Our entire notion of what it means to be good at software is, at bottom, a notion about being good at the coding problem. This made complete sense when coding was the scarce, gating, expensive thing.

Now ask what happens to all of that when the coding problem is substantially solved — when a model can produce, in minutes, code that used to take a skilled team weeks. The apparatus doesn't disappear. It keeps running, with all its momentum, pointed at a problem that no longer needs most of the attention it's receiving. We go on hiring, measuring, and tooling for code production as though it were still the bottleneck, in a world where it increasingly isn't.

The problem underneath the coding problem

The coding problem was never the only problem. It was the loudest one — so loud that it drowned out the problem sitting directly underneath it. That deeper problem is this: deciding, correctly and across an entire organisation, what to build in the first place. It was always there. It was always hard. But it was quieter than the coding problem and downstream of nothing, so it never got the apparatus. We never built the tools, roles, and metrics for it the way we did for code, because the coding problem was always shouting for attention first.

Solving the coding problem didn't make the deeper problem go away. It did something more unsettling: it removed the noise that was hiding it. With construction no longer consuming most of the difficulty, what's left exposed is the part nobody built an apparatus for — the deciding, the agreeing, the converging of a whole organisation on a single, correct understanding of what the software should be. That, now, is the gating problem. And we are bringing fifty years of coding-problem tools to it, because they're the tools we have.

Why bringing coding tools to an agreement problem fails

You can feel the mismatch in how organisations respond to AI-era failures. A team adopts AI, ships faster, and starts producing more wrong things faster — features that were built perfectly and shouldn't have existed. The instinct, trained by decades of the coding problem, is to reach for a coding-problem solution: better review, more testing, tighter engineering process. None of it helps, because none of it addresses the actual failure, which happened before any code was written, in the unmanaged space where the organisation failed to agree on what was wanted. You cannot test your way out of having built the wrong thing. You cannot review a diff into being the right requirement. The tools are excellent and aimed at the wrong target.

This is the quiet realisation underneath everything we're building at Propel. The industry doesn't have a coding problem anymore — that one's largely handled, and getting more handled by the month. It has an agreement problem, and it has no real apparatus for it: no canonical place the agreement lives, no version history for how it changed, no sign-off establishing who committed to it, nothing holding the build against it. We solved the loud problem and discovered the quiet one was always the harder of the two. The work now is to build for the problem we actually have, rather than bringing ever-better solutions to the problem we already solved.

Solved problems and open ones

• Solved — writing code. Cursor, Claude Code, Codex, Copilot, v0, Lovable and Replit handle it, and improve monthly.
• Solved — reviewing code. AI code review reads every diff, tirelessly.
• Open — deciding what to build. Getting business, engineering and legal to agree, on the record, before the agents start.
• Open — proving it still matches. Showing, months later, that the software the organisation runs is the software it agreed to.