From Copper to Code

What infrastructure history teaches us about agentic AI and the future of software production

TLDR

Every era spends money on the infrastructure it assumes is necessary.

The telephone era was spent on copper, poles, switches, and physical reach. Mobile changed the delivery model. In many countries, especially parts of Africa, adoption leapt toward mobile while fixed-line build-out stayed low. The cloud later changed where applications run and who carries much of the infrastructure burden. Agile changed how software teams learned by shortening feedback loops.

Now, agentic AI is changing something deeper. It is changing the production economics of software itself.

The next advantage will not come from merely buying AI tools. It will come from redesigning software delivery around compressed cycles, stronger architectural intent, and faster release of business value.

Introduction

If you want to understand where software is going, it helps to stop looking at software for a moment.

Look up.

Above many streets, even now, the old logic of communication is still hanging in the air. Wires. Poles. The visible remains of a time when reaching a person meant physically reaching their house. The network had to travel to the building before the conversation could begin.

That model made sense for its time. It was expensive. It was labour-intensive. It was slow to expand. It was also necessary.

Then the model changed.

The purpose did not change. People still wanted to talk. Businesses still wanted to connect. Families still wanted access. What changed was the infrastructure model underneath the outcome.

That shift matters because businesses often confuse today’s delivery model with permanent reality. They spend on the current system as if it were the only possible one. Then a new model arrives and makes yesterday’s investment look less like an asset and more like a drag.

That is the real story here. Not telephones. Not cloud. Not AI in isolation.

Capital allocation.

Where money was spent. Why was it spent there? And what happens when the model changes?

The Problem

Most organizations do not miss the future because they are foolish. They miss it because the current operating model still appears rational from the inside.

A landline company could defend every mile of copper it laid.

An enterprise with a private data centre could defend every rack, every cooling system, every network switch, every backup strategy, and every operations team.

A software department with thirty people, layered approvals, sprint rituals, and long release cycles can still defend its structure today.

Each of these systems made sense when the bottleneck was what the system was designed to relieve.

That is the trap.

The moment the bottleneck shifts, the entire cost structure must be reinterpreted.

What used to be prudent now looks heavy.

What used to be necessary begins to look inherited.

What used to be a moat begins to look like ballast.

Historical Context and Existing Approaches

For most of the twentieth century, communications meant fixed infrastructure. The network reached the person through a physical line build-out. That required exchanges, maintenance, installation crews, and last-mile reach into homes and businesses.

Mobile did not eliminate infrastructure. It changed the form of it. The economics moved toward towers, radios, spectrum, and handsets. The important point is not that the infrastructure disappeared. It is that a new infrastructure model changed the cost of access and the speed of expansion.

That mattered especially in countries that never built out large fixed-line networks. In parts of Africa, mobile adoption surged while fixed-line adoption remained low. The world did not stop needing communications infrastructure. It changed the form of the infrastructure required to deliver the outcome.

The customer side of that story matters even more than the carrier side.

The customer did not wake up wanting copper in the ground. The customer wanted a phone.

That distinction is easy to miss and hard to overstate.

People rarely want the infrastructure. They want the outcome that the infrastructure makes possible.

The same pattern showed up again in enterprise software.

For a long time, serious software meant internal infrastructure. Data centres. Servers. Storage. Power. Cooling. Disaster recovery. Network operations. Security layers. Backup systems. Internal support teams. A company that wanted a line of business applications often had to carry much of the machinery required to run them.

Then the cloud changed the frame.

Again, the business did not want racks. It wanted applications.

It wanted order processing, claims handling, billing, customer service, reporting, integration, workflow, and digital reach. The infrastructure burden had become part of the price of getting the outcome. Cloud changed that relationship.

Then, software teams did something important in response to business pressure. They changed how they worked.

Agile did not appear because developers suddenly fell in love with ceremonies. It emerged because organizations needed working software sooner, needed feedback sooner, and needed scope constrained tightly enough to inspect progress repeatedly.

That was a rational response to the production economics of the time.

Where Those Approaches Break Down

Here is where the old lesson starts to matter again.

Agile shortened the feedback loop. It did not remove the labour economics underneath the loop.

A sprint still assumed scarce human throughput.

The organization still assumed that analysis, design, implementation, testing, review, and release had to be paced around the rate at which humans could manually transform intent into code.

That assumption is now under pressure.

Not because AI is magical. Not because quality no longer matters. Not because software somehow writes itself.

Because the production boundary is moving.

Today, coding agents can already research repositories, assemble plans, modify code, run tests, and prepare work for human review. That does not mean software delivery becomes effortless. It means the economics of software production are no longer anchored to the same pacing assumptions.

The mistake many organizations will make is the same mistake made in previous transitions.

They will treat the new capability as an add-on inside the old operating model.

They will bolt AI onto a labour-centric delivery system and call that innovation.

That is like treating a mobile network as a nicer version of a landline.

It misses the point.

When the infrastructure model changes, the winning move is rarely to replace the old model. The winning move is to redesign around the new economics.

The Insight

This is where the story stops being about telecom and starts being about software production.

The real lesson of infrastructure history is not that technology gets better over time.

It is that each era quietly teaches us what the next era will stop paying for.

The world stopped paying for universal fixed-line build-outs as the default for personal communication.

Enterprises stopped carrying all runtime infrastructure as the default answer to business applications.

Now organizations will start paying less for slow, labour-bound software production as the default answer to digital change.

That does not mean expertise becomes irrelevant.

It means expertise moves.

The scarce resource is no longer keystrokes.

It is an architectural judgment.

It is context discipline.

It is deciding what should be built, in what order, with what boundaries, under what controls, and with what evidence that the result is safe to release.

AI does not remove the need for software architecture.

It raises the cost of weak architecture.

When execution accelerates, ambiguity scales with it.

So does waste.

So does rework.

So does plausible noise.

The New Service Surface

There is another downstream effect that matters just as much.

Infrastructure does not automatically own loyalty.

The wire company may have laid the line. The carrier may have carried the call. But the real winner is often the one that captures the customer’s daily use case.

That is why the smartphone changed so many industries at once.

People did not adopt smartphones because they wanted mobile banking. They adopted them because mobility changed the economics of connection. The device was always with them. It connected them to other people. That was enough to make the phone indispensable.

Then the service stack began to pile up.

Camera.

Maps.

Banking.

Payments.

Tickets.

Identity.

Messaging.

Authentication.

Flashlight!

At that point, the device stopped being just a phone. It became the place where services arrive.

That changes loyalty.

No one feels deep attachment to the company laying wire down the street if another player captures the experience, the interaction, the convenience, and the daily usefulness. The infrastructure provider risks becoming invisible. Necessary, but interchangeable.

That is the warning for every industry now.

AI plus mobile is not simply another feature combination. It is a new delivery surface with a new entry speed. When those two combine well, a competitor does not have to rebuild your whole value chain. They only need to capture the customer-facing layer where convenience, judgment, and utility converge.

That is how markets get taken.

Not always by replacing the full stack on day one.

By entering at the point of highest customer utility and then expanding outward.

The Proposed Model or Pattern

The next operating model for line of business software should be understood as a software production infrastructure.

Not tooling in the narrow sense.

Infrastructure.

That model has five parts.

Intent before implementation

The first job is to make the business intent precise enough that software can be produced against it rapidly. If intent is vague, faster execution only produces vaguer output at scale.

Architecture before acceleration

When software cycles compress, architecture becomes more valuable, not less. Clear boundaries, defined contracts, release criteria, and decision ownership stop speed from turning into confusion.

Agents as production capacity

Agentic AI should be treated as production capacity, not as a toy for individual developer convenience. If an agent can research, plan, modify code, and prepare reviewable work, then the organization is dealing with a new production unit.

Validation as the control layer

The faster software is produced, the more important validation becomes. Tests, review, observability, rollback discipline, and release gates serve as stabilizers for compressed execution.

Value as the buying unit

This is the mental shift most firms are not ready for.

If AI folds time, then time stops being a reliable buying unit.

The business should not think first in terms of hours, roles, and effort buckets. It should be thinking in terms of value delivered, risk reduced, and learning cycles completed.

Practical Application

This matters most in line-of-business applications because that is where software historically became heavy.

A request enters the business.

It becomes an analysis.

Then the backlog.

Then prioritization.

Then a sprint plan.

Then implementation.

Then test coordination.

Then review.

Then release scheduling.

Then deployment.

Then user feedback.

Then another request.

Every one of those steps was shaped by the assumption that production was scarce and slow.

Agentic AI does not erase those steps. It compresses several of them and forces the organization to decide which steps still deserve to exist in their current form.

That is the practical question leaders should be asking right now.

Not, should we use AI.

That question is already stale.

The better question is this.

If a meaningful slice of software work can now move from intent to reviewable implementation far faster than our current operating model assumes, which parts of our delivery system are still protecting value, and which parts are only protecting habit?

That is where real transformation begins.

Implications for Architects and Leaders

Architects need to stop thinking only about application architecture and start thinking about production architecture.

How does work enter the system?

How is intent stabilized?

How are agents directed?

How is context carried?

How are outputs validated?

How is release confidence established?

Leaders need to stop treating AI as a productivity perk and start treating it as a change in the economics of delivery.

That shift will alter budgeting, staffing models, release cadence, governance, and vendor expectations.

It will also change the market’s pricing pressure.

The company that can move from idea to releasable software far faster than its competitor is not merely operating more efficiently.

It is learning faster.

That matters more than coding faster.

Because markets reward organizations that reduce the time between insight and response.

Closing Perspective

Look up at the old wires, and the lesson is still there.

Every age builds the infrastructure it thinks it needs.

Then a new model arrives and exposes the old spend as history.

The landline era spent reaching the house.

The mobile era is spent reaching the person.

The on-premises era spent on hosting the application.

The cloud era is spent on consuming the application.

Now the next shift is underway.

Organizations will increasingly spend not only on where software runs, but also on how software is produced.

That is the frontier agentic AI is pushing into.

Not a better autocomplete box.

A different production model.

The companies that understand this early will not merely write code faster. They will reorganize capital, talent, architecture, and release discipline around a world in which software cycles compress sharply and repeatedly.

The rest will continue to fund yesterday’s bottlenecks.

And they will call that prudence right up until it becomes drag.

Continue the Conversation

The next competitive threat may not arrive as a better version of what you already know. It may arrive through a new service surface that captures the customer relationship before you realize the boundary has moved. That is what mobile did to many industries. AI will accelerate the same pattern. If you want to examine how your business can use AI before someone else uses it against you, I provide focused assessments and roadmap planning to help leadership teams identify where the market is shifting, where delivery is too slow, and what to do next.

Next week, I will move from theory to implementation and look at BackTheApp.software, a company building an AI-driven factory line for application delivery. It is based on a simple premise. If AI changes the production economics of software, then organizations need a new operating model for turning business intent into working applications quickly and with control. If that question is already pressing on your business, this is exactly the conversation I help leadership teams work through.