The Era of Software Abundance: Why AI Makes Engineering Fundamentals More Valuable, Not Less

Every management practice we have inherited exists to ration one scarce thing: the ability to produce code. The people who could write it, the hours they had, the patience to get the details right — estimation, headcount planning, the review queue are all ways of budgeting that. It is why "more engineers" was the default answer to "more software".

That default is no longer safe to plan around. The mistake runs in both directions. It would be wrong to believe nothing has changed: one engineer with a clear specification can now produce a working prototype in a single session. It is equally wrong to conclude that software has become cheap. Code has become cheap. Software has not.

If your engineers already use an AI coding assistant, the question is no longer hypothetical: code is being generated faster than the process that used to review it was designed for. What is missing is not the tool. It is a written answer to what that code must satisfy — and the checks that prove it does.

The difference between cheap code and cheap software is the whole argument. When a resource becomes abundant, its marginal value falls, and the constraint moves to whatever is still scarce. For software, the scarce step is no longer writing the code. It is deciding what should exist, specifying what must be true, and proving that what was built is what was meant.

From Scarcity to Abundance

That shift is structural, and it does not need a productivity claim about any particular AI model. If the cost of producing an implementation falls far enough, the number of implementations a team can consider rises, the number it can afford to discard rises, and the cost of being wrong about which implementation to keep becomes the dominant cost. Abundance does not remove the work. It relocates it.

It relocates the work to the expensive half. Regenerating an implementation is cheap. Re-integrating it is where the cost lands. A change costs most at the boundaries it crosses — the interface it has to honour, the data it has to leave intact, the team that must change it next year — and abundance produces more changes crossing more boundaries, not fewer. This is why "generate more, review later" tends to make organisations slower, not faster. Work you cannot check behaves like stock rather than throughput: it looks like progress on a status report, and it costs you every time someone has to touch it again.

Those practices are what the machine cannot supply: a boundary stated before the code exists, a check that can fail, and a settled decision about where each concern belongs. Design and cost arrive at the same place from opposite ends.

Cheap Code Is Not Good Software

The identity layer is where this shows up first, because almost every organisation has one — and often more than one. A "login page" is not a page. It is a rule about who may do what, and that rule has to live somewhere.

What this shows: the same removal done once, and two applications that never hear about it.

Nothing here is broken code. Each application works exactly as it was built to. What is wrong is where the decision lives: who may do what is copied into each application instead of decided once in front of all of them, so a change that should be one action becomes three, and the two that were missed are invisible until something goes wrong. That is what a boundary does — it decides where a change has to happen, and therefore where the cost lands.

AI is not careless, and that is the problem. An assistant asked to add a feature does exactly what a good contractor does with a ticket and no architecture brief: it builds the thing in front of it, competently, using what it can see. It cannot see your system unless the request carries it — where the rule already lives, which service owns it, what must not be duplicated. So it takes the shortest path to a working answer: a new implementation, correct in itself. The model is not failing at the task. It is succeeding at a smaller task than the one you needed done.

That is why the work moves upstream. The context you have to give it — the boundary, the rule that already exists, the check that will judge the result — is the engineering judgement this argument is about, and none of it can be generated on your behalf.

That is not a quirk of login pages. Code is a text. Software is a system: decisions about boundaries, interface contracts, data ownership, failure behaviour and operational cost, expressed in a form a machine can run.

Generated code fails in a characteristic way. It compiles, it renders, it passes a smoke test — and then it ignores a boundary, duplicates a responsibility, or reaches into a module it should not know about. The failure is architectural, not typographical, and that is what makes it expensive: it looks correct at exactly the moment a reviewer is most likely to accept it. That failure is designed against in the architecture, not reviewed away in the diff.

More generated code is not more delivered value. If the checks that judge it cannot fail on the defects that matter, then abundance has not given you capacity — it has given you a larger surface to verify with the same review hours.

Judgement Is a Technical Capability

If code is abundant, the differentiator is judgement. Not taste, and not seniority as a title: judgement as a set of decisions that can be stated and defended. What must be true for this to be correct? Where does the boundary go? Which system are we willing to maintain? What should we refuse?

An AI model can generate options and analyse trade-offs, and it does that well enough to be useful. What it cannot do is own the consequence of choosing. That remains human work — what the book calls the orchestrator's mindset: an engineer who has learned to direct more work than they personally type while keeping the judgement that makes the result correct. That judgement becomes more valuable precisely because the alternatives are now cheap to produce: a team that cannot choose well will generate more options than it can evaluate, and confuse activity with progress.

This is the part of the argument that gets misread as nostalgia. It is not. Judgement is not a soft skill that survives automation by being unautomated. It is a technical capability with components — requirements, architecture, quality, governance — and each component is learned, practised and reviewable. The fundamentals are the interface between intent and generated output. They are not what slows a team down. A weak specification with cheap code produces expensive rework at a larger scale, because the machine faithfully builds the wrong thing faster.

What Changes in the Work — and What Does Not

What changes is the unit of work. The line and the function stop being the meaningful unit; the specification and the check do. Architecture decisions move earlier, because re-integration is the expensive step, not generation. Review becomes the bottleneck, and the quality of a review depends on whether the change can be judged against a stated boundary, not reconstructed from memory.

What does not change is the set of rules that must always hold. Correctness, security, operability and cost do not relax when producing code gets cheaper. If anything they tighten, because abundance makes violations cheaper to create and no cheaper to find.

Here is what a specification looks like when it is precise enough to build against. Not "users must only see their own documents" — that cannot be tested. Instead: a document read is allowed when the caller's tenant matches the document's tenant; any other request is answered as though the document did not exist. That version can be built against, reviewed and tested, and it contains a judgement a machine would not supply on its own — answer "not found", not "forbidden", because a refusal confirms the document exists. The check is equally specific: two tenants, a document in one, a read from the other, and an assertion that the answer is not-found. It can fail — if someone helpfully changes the policy to forbidden, or if a cache serves a stale grant — and those are exactly the defects that compile, render, pass a smoke test, and are wrong.

The bill for getting that wrong arrives later, at the boundary. A decision made after three applications have each grown their own copy of the rule is not paid when it is made; it is paid by the team that has to change three systems, reconcile two lists, and explain why a removal did not take effect. Abundance does not remove that cost. It moves the spending from producing code to changing decisions that have already been built into several places.

Those changes are why the work now sorts into three things. What is being asked has to be stated precisely enough to be built against; where each concern belongs has to be decided while it is still cheap to move it; and what proves the result has to be a check that can fail on every change, with no express lane for generated code. The book we publish names these Prompt, Engineering and Workflow — the naming is a convenience; the sorting is what binds — what the work must answer, whatever the three are called.

Instrumentation is not a fourth item on that list. It is the layer that makes a running system observable, diagnosable and provable — how you find out whether the three decisions held. The structures are what you decide. Instrumentation is how you find out whether your decisions were true.

What This Argument Claims — and What It Does Not

The claim has limits worth stating: this argument is about where the constraint sits while generation is cheap, and about which of your existing practices still pay for themselves there — not a claim that AI replaces engineers, and not a promise that the constraint will sit where it sits now forever.

The argument is about mechanism, not magnitude: it does not turn on how much faster any one tool makes a team, and it can be judged against your own system rather than taken on trust. The method behind it is written down in the book.

What the argument makes clear is where the value sits. The work that pays is design rather than typing — the decision that prevents a class of defect, the gate that catches the one that gets through, and the review that can say why a change is safe. Those are what an organisation cannot generate its way out of, and they are what senior engineers and technology leaders are actually accountable for.

If you are deciding how to adopt AI in an engineering organisation, the useful question is which constraints your system can state, and which of them it can prove — not which model to standardise on. That answer will outlast every model you choose.

The practical version: write down what your system must prove, and the check that proves each one. Where you cannot name the check, you have found the constraint — and the next outage will be diagnosed by the wrong team.

The Orchestrator's Takeaway

Abundance raises the bar rather than lowering it. When generating code is no longer the scarce step, the teams that compound an advantage are the ones whose requirements, architecture and checks make generated code safe to accept — and that is an engineering problem, not a tooling one. Invest where the constraint now is: in judgement made explicit, and in proof that can fail.