For years, the decision to build software internally was relatively easy to understand.

If there was a tool on the market that solved a particular problem, you bought it. If the problem was highly specific to your business, you considered building it. The cost of engineering time, maintenance, infrastructure and support meant that building something internally needed a reasonably strong business case.

That calculation is starting to change.

McKinsey's latest State of AI research found that 32% of organisations have decided against buying at least one software product or feature because they believed they could build it internally using agentic coding tools. In technology companies, the figure is even higher.

At the same time, AI coding agents are becoming a normal part of the developer workflow. JetBrains' 2026 Developer Ecosystem Survey, based on more than 15,000 professional developers, found that 90% were using AI coding agents at work at least weekly, while 68% were using them every day.

Put those two things together and something interesting starts to happen.

The question for engineering leaders is becoming less about whether their teams can build a particular piece of software and more about what they should build.

The economics of "build" are changing

There has always been a long tail of software that companies would have liked to build but couldn't justify.

A finance team might want a better internal reporting interface. A sales organisation might want a CRM workflow that actually reflects how its people work. An engineering team might need a small internal platform for monitoring a particular process.

Previously, those ideas could sit in a backlog for years.

They were too niche for a SaaS vendor to solve properly, but too expensive for the company to build itself.

Agentic coding changes the economics.

A developer can now describe a requirement, have an AI coding agent work through a substantial portion of the implementation, review the output, make adjustments and iterate far more quickly than traditional development allowed.

That doesn't mean software development has become effortless. Production systems still require architecture, security, testing, observability, integration and people who understand the consequences of technical decisions.

It does mean the threshold for deciding that something is worth building has moved.

A tool that would previously have required a dedicated project may now be achievable with a small amount of engineering capacity.

And that creates an entirely new category of software.

The rise of disposable software

One of the more interesting consequences could be the growth of software that was never intended to become a major product.

Think internal dashboards, workflow tools, data transformation utilities, prototypes, operational interfaces, testing environments and small applications built around a very specific business problem.

Some of these will become permanent.

Many won't.

That isn't necessarily a problem.

For decades, software engineering has often operated under the assumption that anything worth building should be designed for longevity. If a team was going to spend months creating something, there was a strong incentive to make it reusable, scalable and maintainable.

When development becomes faster, the economics become different.

A company may be able to build a small tool for a specific team, use it for two years and eventually replace it with something else. The value comes from solving the problem quickly rather than creating another piece of permanent enterprise infrastructure.

That could make internal software considerably more experimental.

It could also make organisations much more responsive.

If a team identifies an inefficient process on Monday, it may be possible to have a working internal tool by Friday. The technology department becomes capable of responding to operational problems in much smaller increments.

For businesses that get this right, that is potentially a significant competitive advantage.

But more software creates more responsibility

There is an obvious risk attached to all of this.

If the cost of creating software falls, organisations are likely to create more of it.

A lot more.

That sounds positive until you consider what happens six months later.

Who owns the application?

Who maintains it?

Who understands the architecture?

Where are the credentials stored?

What happens when the original developer moves teams?

Has the application been tested against real production data?

What happens when an AI agent makes a change that technically works but creates a security or compliance problem somewhere else?

The danger isn't necessarily that AI-generated software will be bad.

The more interesting problem is that it can be easy enough to create that organisations start creating software faster than they create the systems needed to govern it.

Engineering leaders therefore have a new balancing act. They need to give developers enough freedom to experiment while maintaining enough visibility to understand what is being built across the organisation.

The companies that benefit most may be those that establish sensible boundaries rather than attempting to control every experiment.

This changes what we need from developers

There is an important consequence for engineering hiring too.

If AI coding agents can increasingly handle portions of implementation, the value of a developer's ability to produce lines of code quickly starts to diminish.

The harder skills become more valuable.

Can they understand an ambiguous problem?

Can they decide whether something should be built at all?

Can they design a system that will still make sense six months later?

Can they identify when an AI-generated solution is technically plausible but fundamentally wrong for the business?

Can they reason about security, performance, data and failure modes?

Can they work with product, operations and commercial teams to understand the problem before reaching for a technical solution?

These are difficult skills to automate because they require context.

McKinsey's research reinforces this broader shift. Its research into agentic software development found significant differences between engineers in how much productivity benefit they are getting from AI, with the strongest performers seeing substantially larger gains than the average.

That distinction matters.

Giving every developer access to the same AI tools does not create the same outcome.

The engineer who knows exactly what to ask, understands the underlying system and can critically assess the result will get considerably more from an agent than someone who treats it as an automated programmer.

Engineering teams may get smaller in some places and more capable in others

It is tempting to translate this trend directly into headcount.

If developers can build more, perhaps companies need fewer developers.

That is too simplistic.

There are organisations where the increased productivity of engineering teams will reduce the amount of work required for certain types of development. There will also be organisations where the lower cost of software makes previously uneconomic projects viable, creating more demand for engineering capacity.

Both things can happen at the same time.

A company that previously employed ten engineers to maintain a collection of internal systems might eventually need fewer people to maintain them.

Another company might decide that, because software is now cheaper to create, it can finally build the internal products it has wanted for years.

The composition of engineering teams could therefore become more important than their raw size.

We may see greater demand for engineers who sit close to product and operations, people who can translate business problems into technical systems and who are comfortable working across architecture, data, AI and software.

That is already beginning to show up in the way modern engineering roles are being defined.

The build-versus-buy decision is becoming a design decision

For CTOs and technology leaders, this could become one of the most important consequences of agentic development.

The old build-versus-buy calculation was largely financial.

How much does the software cost?

How much would it cost to develop?

How long would it take?

How many engineers would we need?

Those questions still matter, but there are now others.

How quickly can we iterate?

How specific is the problem?

How strategically important is the workflow?

How much control do we need over the data?

How deeply does the software need to integrate with our existing systems?

And perhaps most importantly: does building this ourselves give us an advantage?

If the answer is yes, the economics of building become much more attractive.

That could put pressure on parts of the SaaS market that have historically benefited from the assumption that buying software is always cheaper than creating it.

It could also give technology teams a much bigger role in shaping how businesses operate.

The most valuable engineers may be the ones who know what not to build

There is an irony here.

When software becomes easier to create, the ability to create software becomes less of a constraint.

Judgement becomes the constraint.

Every organisation could potentially have hundreds of small applications, automations and internal tools. The challenge will be deciding which ones deserve to exist, which should be maintained and which should disappear.

That puts engineering much closer to the centre of business decision-making.

The strongest teams will probably spend less time thinking about whether something is technically possible and more time thinking about whether it is worth doing.

AI has made the first question dramatically easier to answer.

The second one is still very human.

And as developers gain the ability to build almost anything, knowing what deserves to be built could become one of the most valuable engineering skills of all.