The Economics of Experience in the AI Era — how AI is reshaping the relationship between expertise and software creation

For most of the history of software engineering, expertise and implementation gradually drifted apart.

As engineers became architects, managers, directors and executives, their impact grew but their direct involvement in building software naturally decreased. This was not a flaw in the system. It was a consequence of scale. Organizations became larger, systems became more complex and leadership became increasingly focused on coordination, prioritization, hiring, budgeting and decision making.

A VP Engineering spending months without opening an IDE was not unusual. In many organizations it was expected. The value of senior leaders came from helping teams succeed, making strategic decisions and creating alignment across increasingly complex systems and organizations.

The trend AI began to reverse

What I did not expect is that AI would start reversing part of that trend.

Not because leadership suddenly has more time. Not because software engineering became easier. And certainly not because experience became less important.

If anything, I believe the opposite is happening.

Over the last year I have probably built more prototypes, internal tools, automations and experiments than I did in many years before. I am not talking about production features replacing the work of engineering teams. I am talking about the countless ideas that normally sit somewhere between a conversation and a backlog item. Small improvements, operational tooling, proofs of concept, integrations, workflows and experiments that would rarely justify dedicated engineering capacity on their own.

What changed is that many of these ideas can now be explored directly.

A few years ago, validating an idea often required organizational commitment. Someone needed to prioritize it, allocate time, coordinate resources and eventually implement it. Today a first version can often be built before any of those conversations happen. Sometimes the idea proves valuable. Sometimes it reveals unexpected complexity. Sometimes it fails completely. But the feedback loop is dramatically shorter.

The wrong metric

This is why I think many discussions about AI productivity focus on the wrong metric.

The industry spends a lot of time debating whether developers are becoming 20%, 30% or 50% more productive. Those discussions are understandable, but they miss a more interesting change that is happening inside software organizations.

The question I find myself asking is not how much faster developers are becoming.

It is who can contribute directly to software creation.

One of the common narratives around AI is that it is making everyone a programmer. I am not convinced that this is what is happening. What I see is that AI is reducing the friction between expertise and implementation.

• A newly hired engineer can become productive faster.
• A product manager can validate a workflow before asking a team to invest in it.
• An architect can explore design alternatives through rapid prototyping.
• An engineering manager can automate operational tasks.
• A CTO can transform an intuition into a working system and evaluate its potential before it consumes organizational resources.

The important point is not that all these people suddenly became software engineers.

The important point is that they can contribute directly to the creation of software.

The distinction matters because implementation has never been the only scarce resource inside a software company. In many cases, the scarcest resource is understanding which problems are worth solving in the first place.

Experience, not just code

One of the misconceptions around AI is that it primarily amplifies coding skills.

What I observe is different.

It amplifies accumulated experience. The more years someone has spent designing systems, operating platforms, managing incidents, understanding customers, scaling teams and making technical trade-offs, the more valuable AI becomes as a leverage mechanism.

Writing code was never the hardest part of software engineering. Understanding what should be built, why it matters and which compromises are acceptable has always been harder. AI helps with implementation, but it does not reduce the value of judgment. If anything, it increases it.

For many engineering leaders, this creates an interesting dynamic.

The experience accumulated over years of building systems, scaling organizations and making decisions can now be translated into working software much more directly than before. In the past, that experience primarily influenced implementation through planning, architecture reviews, organizational processes and technical leadership. Today it can also be expressed through prototypes, automations, internal tools and experiments built directly by the people who accumulated that experience.

A different phase for engineering

This is one of the reasons why I believe engineering organizations are entering a different phase.

For years we optimized around the assumption that implementation capacity was the primary constraint. Every experiment competed with production work. Every prototype consumed engineering resources. Every new initiative carried a significant opportunity cost.

That assumption is becoming less absolute.

The challenge is increasingly shifting toward identifying the right opportunities, making good decisions and creating environments where ideas can be validated quickly without compromising quality, security or maintainability.

Using AI well is an organizational capability

At the same time, there is another reality that software companies are starting to discover.

Using AI effectively is becoming an organizational capability in its own right.

Most discussions still focus on models. Which one performs better. Which one scores higher on benchmarks. Which one generates better code.

Those questions matter, but they are becoming less strategic than they once were.

More and more companies have access to the same frontier models. The real differentiator is increasingly how those models are integrated into workflows, how they are governed, how they are measured and how they are used across the organization.

At Lansweeper we invested heavily in this area. We quickly realized that simply providing access to AI tools would not be enough. We wanted control over model selection, orchestration, governance, observability and experimentation. We wanted to understand where value was being created and how different models could be used effectively across different types of work.

As AI adoption grows, these capabilities become increasingly important. Not because they improve benchmark scores, but because they allow organizations to scale AI usage in a deliberate and sustainable way.

A personal change

For me, however, the most visible change remains a very personal one.

For the first time in many years, I spend a meaningful part of my week building software again.

Not because my role has changed.

Not because management became less important.

But because the distance between expertise and implementation has become smaller than at any point in my career.

Many ideas will still fail. Some prototypes will never leave the experimentation phase. Others will reveal that the original problem was not worth solving.

That has always been true.

What has changed is that those ideas no longer need to remain ideas for very long.

And that may turn out to be one of the most important organizational changes AI brings to software engineering. Not that software gets written faster, but that the experience distributed across an organization can participate much more directly in creating it.