Part of an ongoing series examining how AI is reshaping enterprise technology decisions.

There is a conversation happening in boardrooms right now that feels both new and strangely familiar. It usually starts with a burst of optimism: with AI-powered development tools, companies can finally build the software they’ve always needed. No large teams. No long timelines. Maybe no outside help at all.

The conclusion comes quickly.

We should just build it.

The instinct isn’t wrong.

But it isn’t new, either.

The answer to whether companies should build software to solve their most important operational problems has been “yes” for a long time. In many cases, it was yes ten years ago. What’s changed is not the answer—it’s the confidence with which people are saying it.

And that confidence deserves a closer look.

Most organizations already know exactly where software could move the needle. There is almost always a problem sitting in plain sight—expensive, persistent, and oddly tolerated.

A pricing system that quietly leaks margin.

A rebate process that consumes a team and still produces errors.

A quoting workflow is slow enough to cost deals.

These are not edge cases.

They are known problems, often quantified, often discussed, and almost always deferred.

At some point, someone inside the company—usually someone close to the pain—did the math. They proposed building something to fix it. The economics were sound. The payback period was short.

And nothing happened.

Not because the idea was wrong.

Because something else always won.

ERP migrations. Integration work. Internal priorities that were easier to justify or harder to challenge. The organization chose, quite rationally, to do something else.

So now it’s 2026, and AI has entered the picture. The cost of building software appears lower. The barrier to entry looks smaller. And the conversation starts again, this time with more urgency.

But there’s an uncomfortable question sitting just beneath the surface.

If you didn’t do it then, why are you so sure you’ll do it now?

Because the cost of writing code was never the real constraint.

AI has, without question, changed how software gets built. The tools are impressive. They accelerate code generation, testing, and documentation. They reduce the friction of getting from idea to working prototype. Tasks that once took weeks can now be completed in days.

That part is real.

And it matters.

But it’s also incomplete.

Writing code has never been the hard part of delivering enterprise software. It’s the visible part. The part that feels tangible. The part that people tend to overestimate.

The rest of the work is less glamorous—and far more difficult.

It’s defining what should actually be built when different parts of the business disagree. It’s reconciling multiple versions of the same process that all “have to stay.” It’s figuring out which system is the source of truth, and discovering that the answer changes depending on who you ask.

It’s data that looks clean until you try to use it.

It’s systems that behave differently from what is documented.

It’s users who don’t adopt what you build.

And then there’s everything else.

Security.

Compliance.

Scalability.

Change management.

This is where projects spend their time.

This is where they succeed—or fail.

AI has made the mechanical act of writing code faster. It has not made this part easier.

There is also a question of ownership that tends to get glossed over in these conversations. Building software is not just about producing code. It is about taking responsibility for a system that must operate reliably, securely, and predictably over time.

That includes decisions about architecture, data integrity, system performance, and long-term maintainability. It includes supporting that system years after it is first deployed, when the original context has faded, and the complexity has not.

For organizations that are not, at their core, software companies, this is not a small undertaking.

It is a shift in what the organization is choosing to be.

And the tools that make development feel easier do not remove that responsibility. In some cases, they amplify the risk. AI-generated code is often functional. It works. It produces results quickly.

What it often lacks is judgment.

The kind of judgment that shapes systems over time, keeps them coherent, and makes them adaptable as the business evolves.

There is already evidence of a familiar pattern.

Teams move quickly at the beginning.

Progress feels undeniable.

And then, gradually, things slow down.

Not because the tools stopped working—but because the system underneath them becomes harder to understand, harder to change, and harder to trust.

Code is being generated faster than it can be properly absorbed.

That is not acceleration. That is accumulation.

The gap becomes most visible in what might be called the last mile of software delivery.

The early stages of a project have never looked better. Prototypes come together quickly. Demos are compelling. The system appears to do exactly what it is supposed to do.

It all makes sense—until it meets reality.

The three pricing rules become fourteen.

The ERP behaves in ways no one documented.

The system needs to scale beyond what anyone planned for.

Edge cases multiply.

This is the point where many projects stall.

Or quietly degrade.

Because this work depends on experience.

Not just technical skill, but context. Pattern recognition. The ability to anticipate problems before they surface and to make decisions that hold up under pressure.

AI is not designed for that kind of work.

If AI has not fundamentally altered these dynamics, what has changed?

Two things, and they pull in opposite directions.

The economics have improved. When used well, AI can compress timelines and reduce costs. It can make a disciplined team more effective. It can remove friction from the parts of development that should never have been slow in the first place.

But the cost of getting it wrong has also increased.

Because it is now easier than ever to build something that looks right.

And much easier to build something that will not hold up over time.

Technical debt is not a new problem. But AI is making it easier to create—and faster to accumulate. Systems can reach a breaking point before organizations fully understand what they’ve built.

So yes, the conclusion remains the same.

You should build the software.

In many cases, you should have built it years ago.

But that was never the real decision.

The real question is who is accountable for the outcome.

Because the organizations that succeed in this environment will not be the ones that simply adopt AI tools. Those tools will become ubiquitous. The advantage will not come from access.

It will come from how they are used—and by whom.

The winners will be the organizations that combine speed with discipline. That pair AI capabilities with domain expertise. That treat software not as a project, but as a system that must perform, evolve, and deliver measurable results over time.

In other words, the fundamentals still matter.

They just matter faster now.

If this resonates—or if you see it differently—it’s a conversation worth continuing. The most useful insights will come from technology and business leaders comparing notes in the open.