Five Years From Now, Code Will Be Cheap. Judgment Will Not.
AI is lowering the cost of implementation, but it is not lowering the cost of bad decisions.
Part 1 of 3 in The Future of Software Engineering When Code Becomes Cheap.
I’ve been thinking about the economics of software more than the technology of software lately, because the economics are what usually determine how organizations behave. For most of the industry’s history, code was expensive because qualified human attention was expensive. Every new feature, report, workflow, integration, migration, and internal tool required people who could understand the problem, translate it into software, test it, deploy it, and live with the consequences.
That scarcity shaped almost everything about software delivery. Organizations accumulated backlogs because engineering time was limited. Reasonable ideas died in prioritization meetings because the cost of building them exceeded the value anyone could prove in advance. Technical debt remained in place because fixing it competed with visible business demand, and the business usually had a hard time valuing the absence of future pain.
Code was not expensive because every line was intellectually profound. A lot of software work has always been routine, repetitive, and frankly less glamorous than the industry likes to admit. It was expensive because each line still consumed human time, and human time was the constraint around which software organizations were built.
AI is starting to change that constraint. I do not mean that code is free, or that agents can be trusted to own arbitrary production systems without oversight. That is not where we are. What has changed is that the amount of human effort required to reach a usable first implementation is falling, and that has consequences that are larger than autocomplete or faster ticket completion.
Modern AI systems can inspect repositories, generate application logic, draft tests, produce documentation, update configuration, diagnose routine defects, and propose alternative implementations. They can work through a problem in several directions at once, especially when they have access to tools, tests, logs, and enough context about the system. They still fail, and they fail in ways that require skilled review, but the early implementation labour that used to consume days or weeks can now sometimes be compressed into hours.
What I find more interesting is not whether this makes individual developers 10 percent or 40 percent faster. Those averages hide too much variation to be useful by themselves. The more important question is what happens when implementation stops being the primary economic bottleneck in software delivery.
One possible answer is that we build much more software. Lower implementation costs usually expand demand, and there are countless workflows inside organizations that were never automated because the business case could not survive the delivery estimate. There are internal tools nobody approved, reconciliations nobody fixed, exception processes nobody cleaned up, and niche applications nobody built because scarce engineering capacity had to be reserved for larger programs.
If AI reduces the cost of producing those systems, many of them will finally get built. Smaller teams may create more internal software. Departments may automate work that used to sit below the threshold of IT prioritization. Business units may expect software to conform more closely to how they actually operate, because the cost of tailoring the system will be lower than it used to be.
The uncomfortable part is that more software does not necessarily mean proportionally more software-development jobs. Demand for software can rise while demand for traditional implementation labour falls. A team that once required several developers, analysts, testers, and documentation resources may be replaced by a smaller group of experienced people directing AI systems, reviewing their output, and accepting accountability for what goes into production.
That does not mean software engineering disappears. It means the centre of value moves. The future software professional will be less differentiated by how much code they can produce and more differentiated by whether they can decide what should be built, direct AI systems to build it, and determine whether the result is safe, correct, maintainable, and worth operating.
This is where the abstraction ladder matters. The work moves from “build this feature” toward “understand the business problem, define the constraints, choose the architecture, establish the conditions for correctness, and prove that the system satisfies them.” That is a very different job from turning a well-written ticket into code, and it rewards a different set of instincts.
In practice, I expect engineers and architects to spend more time defining objectives, selecting patterns, comparing generated alternatives, reviewing security implications, validating data handling, and deciding which failures matter. They will need to understand how the system behaves under change, not merely whether the current implementation passes a narrow test. They will need to know when an answer is plausible but wrong, when a design works in a demo but fails operationally, and when automation should stop and a human decision should begin.
Cheap code can create expensive systems. That is the architectural risk hiding underneath the productivity story.
When implementation becomes easier, organizations may create more services, more integrations, more agents, more automated decisions, more duplicated functionality, and more permission paths than they know how to govern. A system that was cheap to generate can still be expensive to support. A workflow that was easy to automate can still create audit exposure, privacy risk, operational dependency, or data quality problems that take years to unwind.
This is not a theoretical concern. Over the course of my career, I’ve watched organizations create complexity when the cost of adding one more field, one more automation, one more integration, or one more exception path looked small in isolation. The bill arrived later, through slower delivery, weaker reporting, fragile releases, security reviews, production incidents, and business processes nobody could explain cleanly anymore.
AI increases that risk because it reduces the friction that used to slow some of those decisions down. Friction is not always bad. Sometimes the effort required to build something forced the organization to ask whether the thing should exist at all. If that friction disappears, the missing discipline has to come from architecture, governance, and accountability instead.
The future architect in this environment is not just drawing target-state diagrams. They are designing model and agent boundaries, identity and permission models, human approval checkpoints, evaluation suites, audit trails, data-access rules, cost controls, failure recovery paths, escalation models, and provider-switching strategies. They are deciding not only what the system should do, but what it should not be allowed to do.
To be clear, I am not arguing that every developer needs to become an enterprise architect. I am not arguing that writing code no longer matters. What I am arguing is that the ability to produce code will become a less durable advantage on its own, because the market is making implementation more abundant.
What remains scarce is judgment. Context remains scarce. Trust remains scarce. Accountability remains scarce. The ability to understand a business process, recognize a hidden constraint, challenge a generated answer, and accept responsibility for a production outcome remains scarce.
Five years from now, the most important question may no longer be whether someone can write the code. It may be whether they can design and govern a system in which machines write the code and increasingly perform the work. If that proves directionally correct, the cost of implementation is collapsing, but the cost of poor judgment is not.
This article is part of The Future of Software Engineering When Code Becomes Cheap, a three-part series on how AI changes implementation cost, engineering apprenticeship, and the pace of software work.
Read the series:
- Five Years From Now, Code Will Be Cheap. Judgment Will Not. (current article)
- Who Becomes a Senior Developer When AI Eliminates the Junior Work?
- AI Is Not Like the Internet. It Helps Build Its Successor.