Software Engineering is Dead. Long Live Software Engineering.

Low-code was supposed to do it. Then no-code. Before that, Visual Basic, RAD platforms, and “configuration over code”. Even CASE tools in the 80s were meant to generate entire systems from diagrams. All promised to make coding unnecessary.

Now it’s AI-powered “vibe coding”. Describe what you want, watch an app appear, tweak it in real time.

It feels like magic. Say the incantation, wave the software wand, and the ideas in your head show up as something real. It collapses the distance between idea and execution in a way that would have been unthinkable just a few years ago.

That shift matters. It’s already changing how teams approach building software and what stakeholders expect from it.

But it’s also where the story often gets oversimplified.

The New Superpower Is Real

The cost of experimentation has collapsed. Teams can explore ideas, build internal tools, and test assumptions faster than ever. Conversations that used to stall out in planning documents can now move forward with something tangible on the table.

This is a meaningful shift in how ideas become software.

For prototypes, accelerators, and early discovery work, it opens the door for more people to move from just talking to actively participating in building solutions.

The trouble starts when that success gets mistaken for a full replacement.

Enterprise Software Isn’t a Thin Layer

Much of the current hype assumes enterprise software is mostly superficial. A thin interface. Some business logic. Easy to reproduce once you have the right tools.

That assumption breaks down quickly in practice.

Enterprise systems are dense because they have to be. They encode years, sometimes decades, of decisions about how an organization operates. Regulatory constraints. Audit requirements. Edge cases discovered only after something went wrong. Integrations that exist because the business couldn’t afford to stop operating while the system evolved.

This complexity isn’t accidental, and it isn’t the result of indecision. It’s the accumulated shape of real organizations solving real problems over time.

Even leaders experimenting aggressively with AI internally push back on the idea that enterprise platforms are suddenly obsolete. After Klarna made headlines for moving away from Salesforce, CEO Sebastian Siemiatkowski was quick to clarify the broader takeaway:

“No, I don’t think it is the end of Salesforce; it might be the opposite.” — Sebastian Siemiatkowski, CEO of Klarna

(— Sebastian Siemiatkowski (@klarnaseb) March 3, 2025 )

Even when companies push the boundaries of what they build themselves, that doesn’t translate into a mass replacement of enterprise systems. What’s being disrupted first is how software is created, not the role it plays inside complex organizations. The economics, risk profiles, and operational realities simply don’t line up for most organizations.

You can rebuild something that looks similar on the surface. Rebuilding something that behaves correctly under stress is a very different challenge.

Speed Isn’t the Primary Goal

In early-stage products, speed can be everything. In enterprise environments, speed is rarely the primary constraint over time.

Trust matters more than velocity.

These systems move money, enforce policy, and shape how people work every day. When they fail, the consequences are real. Financial. Legal. Reputational.

That’s why enterprise software tends to move more carefully. Not because organizations lack ambition, but because the cost of being wrong is high and because the hardest decisions aren’t technical ones.

The Hard Parts Were Never the Code

AI-assisted development hasn’t changed where most software efforts struggle.

The hardest parts of software rarely show up in demos. They don’t look like code, and they don’t feel technical. Most of them only become visible once a system is under real pressure.

The hard parts live in:

• Managing organizational change when software forces people to work differently
• Navigating conflicting priorities across teams with different incentives
• Making trade-offs when time, budget, and risk can’t all be optimized
• Deciding what “good enough” actually means in regulated, high-stakes environments
• Earning and maintaining trust from the people who rely on the system every day

These challenges don’t announce themselves upfront. They surface slowly and unevenly. A “simple” change requires six approvals. One team optimizes for speed while another optimizes for safety. A system technically works, but no one trusts its output enough to use it. The cheapest solution on paper becomes the most expensive one a year later.

None of this shows up in a demo. But it’s what ultimately determines whether software succeeds or fails.

This is why the value of enterprise software was never just the code itself. As analyst Ben Thompson has argued for years, organizations don’t pay simply for software artifacts. They pay for everything that comes with them: reliability, integration, and long-term stewardship.

“Companies don’t just want the code — they want a product with everything that entails: support, compliance, integrations, and long-term maintenance.”
— Ben Thompson, Stratechery
https://stratechery.com/

No tool eliminates those challenges. Faster building can surface them sooner, but it doesn’t resolve the underlying complexity.

The Real Cost of Building Software

There’s another reality that often gets overlooked in the excitement: where the cost actually shows up.

Enterprise software is often expensive from the start, not because teams are slow or organizations are difficult, but because the work sits at the intersection of systems, people, and risk. Aligning stakeholders, navigating regulatory requirements, integrating with existing platforms, and establishing trust all take time. All this has to happen before a system goes live.

And the cost doesn’t stop once it does.

Maintenance. Security. Compliance changes. Integrations. Support. Documentation. Turnover. The gradual loss of context as people move on. Decisions made early, often for good reasons at the time, compound into constraints that shape what’s possible years later.

For organizations that are not software companies, this matters.

Most organizations don’t win by owning payroll systems, compliance platforms, or industry-specific tooling. Building and maintaining those systems rarely strengthens their competitive advantage. That’s why trusted partners and platforms exist. They specialize. They absorb complexity. They spread the ongoing cost across many customers.

Building custom software makes sense when it differentiates your business or enables it to operate in ways off-the-shelf tools can’t. The challenge isn’t building custom software. It’s doing it with a clear understanding of the trade-offs, long-term costs, and organizational impact involved.

What Actually Changes

Software engineering isn’t dead.

What’s changing is who gets to build, how quickly ideas can be tested, and where human effort creates the most value.

As Dan Gallagher wrote in The Wall Street Journal, the disruption isn’t existential, but it is structural:

“AI won’t kill the software business. But the persistent belief that it will can still do a lot of damage.”
— Dan Gallagher, The Wall Street Journal
https://www.wsj.com/tech/ai/ai-wont-kill-the-software-business-just-its-growth-story-05673e07

AI will continue to lower the barrier to creation. It will reshape experimentation and change productivity curves.

What it won’t do is eliminate the need for judgment, stewardship, and organizational alignment. As the tools become more powerful, the cost of poor decisions rises, and navigating those trade-offs becomes a discipline in its own right, one that benefits from experience across many organizations, systems, and failure modes.

The organizations that win won’t be the ones chasing every new tool or reflexively building everything themselves. They’ll be the ones that approach this moment with clarity, experience, and a willingness to make deliberate choices about what to build, what to buy, and where to invest their limited time and attention.

Software engineering is dead.

Long live software engineering.

‍