AI Wasn’t Always This Good. We Just Got Used to It.

💡 TL;DR: Key Takeaways

• AI is not only making software development faster. It is expanding the range of ideas a company can afford to test.
• Judging past teams with today’s tools is wrong. But running today’s company with yesterday’s cost and capacity assumptions is equally wrong.
• Scarcity is moving. As code gets cheaper, problem selection, customer knowledge, distribution, and judgment become more valuable.
• More software is not the goal. The goal is to reach evidence sooner and make better decisions.

A leader watches one capable person produce a substantial product in a few weeks. Only a few years ago, the same work appeared to require a team and months of budget.

The tempting conclusion is immediate:

Our software team worked for years. If one person can produce this much now, perhaps the old team achieved very little.

That conclusion is wrong. But the change behind it is real.

The team working in 2023 did not have the tools available in 2026. We cannot apply today’s technology retroactively and call it a performance measure. Yet many companies now make the opposite mistake. They still budget, staff, and sequence software work as if the new tools had never arrived.

After nearly three decades in software, I am cautious about calling every new tool a fundamental shift. This one changes a real boundary: the size of the work we can sensibly delegate to AI.

As that boundary grows, so does the range of ideas a company can economically test.

The change is not merely speed

Until a few months ago, working with a coding model required constant supervision. I broke work into small pieces, repeated the constraints, corrected mistakes, and often completed the difficult part myself.

Today, with the right context and a clear brief, I can delegate much larger pieces of work. I still review the result. Critical systems still require serious human oversight. But the delegable unit has grown from a function toward an entire feature.

That sounds like a technical improvement. Its more important consequence is economic.

A ten per cent productivity gain makes an existing project slightly cheaper. Crossing a threshold can make a previously uneconomic idea worth testing. Some work no longer stays at “AI can help.” It can be delegated, reviewed, and turned into useful evidence much sooner.

We adapt to this change remarkably quickly. A model completes something that seemed almost impossible a few months earlier. We are surprised for a day. Within weeks, we treat it as normal. When the next model arrives, we rewrite our memory: “AI could already do this.”

Usually, it could not—not with the same reliability, on tasks of the same size, with the same low level of intervention.

Recency bias, hindsight bias, and a shifting baseline help explain this. The terms matter less than the consequence. We normalise a new capability, then remember it as if it had always existed. That distorts both our view of past performance and our estimate of current capacity.

Do not rewrite the past with today’s tools

We have lived through similar shifts before. IDEs removed mechanical work. Stack Overflow shortened the search for technical knowledge. Modern frameworks standardised common problems. Cloud services reduced weeks of infrastructure work to hours.

An infrastructure team that needed weeks to create an environment fifteen years ago was not necessarily failing. The fact that we can now do the same work in an afternoon does not change that. The team had different tools and constraints.

The same logic applies to AI. A lower-cost prototype in 2026 is not evidence that the 2023 team performed badly.

But historical fairness does not mean preserving the old operating model. It is not a defence of today’s inertia.

Judge past performance with the tools of its period. Set current expectations with the tools that genuinely exist now.

Value accumulates in domain knowledge and ownership

Software development is moving beyond the software department. A logistics specialist knows the routing exceptions. A finance specialist understands the reconciliation rules. A marketing operator can see campaign friction earlier than a generic product team.

For bounded problems, a strong domain expert using capable AI may produce a better result than an average software team. The expert knows what must be true in the real operation.

Strong engineering returns to the centre as risk and dependency grow. Customer-facing, regulated, or revenue-critical systems still require reliability, data integrity, security, and support.

The conclusion is not that developers are unnecessary. Value is moving from translating a defined request into code toward choosing the right intervention, setting safe boundaries, and owning the outcome.

More software does not mean more value

Some ideas that once appeared in a plan as “three developers for six months” can now be tested in weeks.

Tested is the important word. This is not a claim that one person replaces a team. It means the company can answer important questions before making a large investment. Do customers want it? Does the workflow remove a real cost? Does it improve speed, quality, or revenue?

Producing hundreds of features in three months proves only that software was produced. It does not prove that anyone wants it or that the result deserves years of maintenance.

As code gets cheaper, the scarce resources change. Understanding the customer, finding the right problem, earning trust, and reaching the market become more valuable. I have argued elsewhere that AI may change companies through the hires that never need to happen. The same leverage also lets smaller teams test ideas that could never previously win a budget.

Models still make mistakes. A convincing demo is not dependable software. Data, integration, adoption, support, maintenance, and accountability sit between the two. Faster production makes verification and ownership more important. Otherwise, speed becomes comprehension debt.

AI is easing the problem of producing more software. In return, it makes another question more important: which software is worth producing?

Within a few months, today’s capabilities will feel ordinary. That is precisely why the baseline is worth recording now.

Judge the past with the tools it had. Run today’s company with the tools it has. The leadership task is to decide where cheaper software should create faster learning—and where it would merely create another system to maintain.