We Forgot Why Engineering Exists: AI Is Forcing Us to Remember

Somewhere along the way, software engineering stopped being about building products. It became about building engineering.

We built microservices before we had a single defined domain. We designed for scale before we had a single user. We architected for flexibility before we had market fit. We created layers of abstraction to solve problems we didn't have yet.

And we called it best practice.

It wasn't best practice. It was a slow drift into a rabbit hole of self-referential complexity. Engineering became an end in itself. The product became an afterthought.

AI is forcing us to confront this. Not because AI is particularly wise. But because when you can ship in hours what used to take weeks, all that complexity becomes obviously, painfully unnecessary.

How We Got Here

I've been trying to understand how an entire industry lost the plot. The answer is uncomfortable: we had incentives to lose it.

Career advancement in engineering rewards complexity. Nobody gets promoted for shipping a monolith that just works. You get promoted for designing distributed systems. For introducing new architectures. For solving hard problems, even if those problems didn't need to exist.

Meaning-making played a role too. Engineers want to feel like their work is sophisticated. Building a simple CRUD app doesn't feel sophisticated. Building an event-driven microservices architecture with eventual consistency and a custom orchestration layer feels sophisticated. Never mind that the business needed the CRUD app.

Conference talks and blog posts amplified it. The ideas that spread were the complex ones. Nobody wants to hear about the boring thing that worked. They want to hear about the elegant solution to the self-inflicted problem.

And so we created an ecosystem where complexity was rewarded, simplicity was dismissed as unsophisticated, and the actual purpose of engineering was quietly forgotten.

The Stack Overflow Lesson Nobody Learned

Stack Overflow handled massive traffic. One of the most visited sites on the internet. Millions of developers relying on it daily.

It was a monolith. Written in .NET, one of the supposedly "uncool" technologies. Running on a handful of servers when conventional wisdom said it should need hundreds.

The team was small. The architecture was simple. It worked.

This should have been a wake-up call for the industry. Here was proof that you didn't need microservices. You didn't need infinite horizontal scaling. You didn't need to adopt whatever Netflix was doing. You needed to build something that solved the problem efficiently.

Instead, we treated Stack Overflow as an anomaly. An exception that proved the rule. We kept building complexity because complexity was what serious engineers built.

We were wrong.

What Engineering Is Actually For

Let me say something obvious that apparently needs saying: Engineering exists to build products.

Not to build elegant systems. Not to demonstrate technical sophistication. Not to create job security through complexity. Not to generate conference talks.

To build products.

Products that solve problems. Products that create value. Products that make businesses work. Products that users actually want.

Everything else is overhead. Sometimes necessary overhead. But overhead nonetheless.

When you adopt a microservices architecture, that's overhead. It might be justified overhead if you have genuine scaling needs or organizational constraints. But it's not innovation. It's not progress. It's a cost you're paying for a benefit you may or may not need.

When you build for flexibility before you have market fit, that's overhead. You're paying the complexity cost for optionality you might never use, while slowing down the iteration speed you definitely need.

When you over-engineer for scale before you have users, that's overhead. You're solving imaginary problems while ignoring real ones.

The product is the point. Engineering is in service of the product. Not the other way around.

Why AI Changes This

AI isn't inherently opposed to complexity. You can absolutely use AI to build overcomplicated systems faster.

But AI changes the economics in a way that makes complexity harder to justify.

When you can ship a feature in an afternoon, the argument for "investing in architecture now to save time later" weakens. You're not saving that much time later. The future is already here.

When you can validate an approach in hours, the argument for "building flexibility because we don't know what we'll need" weakens. You can find out what you need and build it. Right now.

When you can refactor confidently with AI assistance, the argument for "getting the abstractions right upfront" weakens. You can change the abstractions when you actually understand the domain.

AI compresses timelines. When timelines compress, premature optimization becomes even more obviously premature. Speculative architecture becomes even more obviously speculative.

The engineers who adapt will stop building for hypothetical futures and start shipping for the actual present.

Innovation Is Product Innovation

I want to be precise about something: I'm not anti-innovation. I'm anti-fake-innovation.

Adopting Kubernetes isn't innovation. It's infrastructure. It might be necessary infrastructure. But you're not changing the world by running containers.

Building a custom event sourcing system isn't innovation. It's architecture. It might solve a real problem. But the innovation was in identifying the problem and its solution, not in the implementation technology.

Real innovation happens at the product level. Finding a new way to solve a user problem. Creating value that didn't exist before. Enabling something that was previously impossible or impractical.

Engineering supports innovation. Engineering isn't innovation. Conflating the two is how we ended up with teams spending six months on "platform modernization" while competitors shipped features that stole their customers.

The Uncomfortable Reckoning

Here's what I think is actually happening: AI is revealing that much of what we built over the past decade was theater.

The complexity wasn't necessary. The overhead wasn't justified. The sophisticated architectures were solutions looking for problems.

We created jobs maintaining complexity we created. We built teams to coordinate across boundaries we invented. We hired consultants to help us understand systems we overcomplicated.

This is uncomfortable because it means a lot of work was, in some sense, wasted. A lot of careers were built on foundations that are now crumbling. A lot of identity was tied to expertise that's becoming irrelevant.

But it's also liberating. Because if you can let go of the complexity theater, you can focus on what actually matters: building great products.

What Great Looks Like Now

The engineers who will thrive aren't the ones who can design the most sophisticated systems. They're the ones who can ship the most valuable products with the least overhead.

That means:

Building the simplest thing that solves the problem. Not the simplest thing that could possibly work, but the simplest thing that actually works well. Fit for purpose. No more, no less.

Validating before architecting. Understanding what users need before deciding how to build it. Letting the domain drive the design, not the other way around.

Treating engineering decisions as costs, not achievements. Every abstraction, every service boundary, every layer of indirection is a cost. Sometimes worth paying. But never free, and never inherently good.

Measuring success by product outcomes, not engineering outputs. Did we ship something valuable? Did users benefit? Did the business grow? Not: did we implement best practices?

This isn't a lower bar. It's a different bar. And it's one that most engineers have never been asked to clear, because the industry was too busy rewarding complexity.

The Product Is the Point

I keep coming back to this because it's so easy to forget.

The product is the point. The product is why engineering exists. The product is what creates value, serves users, builds businesses.

AI is giving us a chance to remember this. To strip away the accumulated complexity. To focus on what matters. To build things that actually work, efficiently, without the overhead we convinced ourselves was necessary.

Not everyone will take this chance. Some engineers are too invested in complexity to let it go. Some organizations are too calcified to change. Some careers depend on maintaining systems that shouldn't exist.

But for those willing to let go, this is an extraordinary moment. We can finally focus on the product again.