Software Economics - The High Cost of Free Code

Stop celebrating how much software your team ships. Without strict business intent, a high-volume engineering engine is simply a highly efficient machine for financing future rework.

Rework Is a Capital Problem

Rework is usually filed under engineering hygiene, a quality issue to be managed with better testing and tighter reviews. That filing is a category error. Rework is not an engineering problem that happens to cost money; it is a capital-allocation problem that happens to express itself in code. Every hour spent building something that should not have been built, discovering that it was wrong, and building it again is capital deployed against a negative return, and the fact that the waste is denominated in engineering time rather than dollars does not make it any less a balance-sheet event.

For most of the industry's history, this particular form of waste was bounded by the cost of production itself. Building the wrong thing was expensive enough that organizations were forced to be at least somewhat careful about what they committed to, and the scarcity of engineering capacity acted as a crude but real filter on bad decisions. That filter is now gone. When generation is cheap and fast, the cost of committing to the wrong build no longer constrains the volume of wrong builds, and an organization can pour capital into confidently producing the wrong thing at a scale that would have been financially impossible three years ago.

Part of why this persists is that the waste is structurally hidden. Rework rarely appears as a line item; it hides inside salaries that would have been paid regardless, inside sprints that look fully utilized, inside roadmaps that show steady motion. The capital is being consumed, but the accounting records it as productive work rather than as the correction of an avoidable error. What looks like a fully occupied engineering organization can, on closer inspection, be an organization spending a meaningful fraction of its capacity undoing decisions it made too quickly to make well.

This inverts the economics that most software leaders still carry in their heads. The dominant cost in AI-assisted development is migrating away from generation, which is collapsing, and toward correction, which is not. The expensive part of the lifecycle is no longer writing the code. It is the cycle of building, discovering misalignment with what the business actually wanted, and rebuilding, repeated across an organization that can now run that loop faster than ever without getting any better at avoiding it. Velocity, in this setting, is not the same as progress. It is often just the speed at which capital is converted into work that will have to be redone.

Measuring the Right Number

The reframing this demands is uncomfortable for organizations that have standardized on velocity as their core metric. Throughput, properly understood, is not the volume of software an organization produces. It is the volume of correct software it produces per unit of capital deployed, and those two numbers diverge sharply the moment generation becomes cheap and intent becomes the binding constraint. A team optimizing the first number while ignoring the second is improving a figure that feels like productivity and behaves like waste, and it will keep doing so until the rework lands somewhere a CFO can finally see it.

The organizations that will hold a durable capital advantage are not the ones with the highest output. They are the ones with the highest ratio of intended to produced, the ones whose generated work actually corresponds to a deliberate business decision rather than a machine's plausible guess at one. Getting that ratio right is not a matter of engineering discipline alone. It is a matter of treating the definition and preservation of intent as a capital-efficiency function, because in an economy where anyone can build anything quickly, the only remaining source of advantage is building the right thing on the first attempt.