AI Didn’t Change the Problem. It Exposed It.

I’ve Seen This Movie Before

Years ago, we called it Service-Oriented Architecture. Before that, distributed computing. Before that, object-oriented decomposition and separation of concerns. The vocabulary shifts every few years, but the business question keeps coming back wearing a different hat:

That was the problem then. It’s still the problem now.

When I updated my old SOA Right Away material to map it against today’s AI architecture conversations, the correspondence was almost embarrassing. Standardized service contracts became tool schemas and MCP specs. The Enterprise Service Bus became the AI orchestrator. UDDI service registries became agent registries. Loosely coupled components became model-agnostic interfaces.

The patterns from GRASP — General Responsibility Assignment Software Patterns — and classic OOP didn’t disappear. They just got rebranded.

The reason so many AI workflows feel needlessly complex right now is that teams are rebuilding the same solutions to the same problems without recognizing the map they already have. This is one of the core tensions between business architecture, enterprise architecture, and development: each layer tends to rediscover the wheel rather than inherit the lessons above it.

The Hype Cycle Is Not New. But AI Made It Worse.

Here’s a pattern that repeats in IT every few years: a new technology arrives, the industry loses its mind, and suddenly every interview, every team standup, and every conference talk becomes a trivia contest about tooling.

We’re deep in that cycle right now.

Instead of asking what business problem are we actually solving, conversations devolve into debates about which orchestration framework to use, which model won the latest benchmark, or whether you’re current on whatever was released four Tuesdays ago. The stack changes so fast that even experienced engineers feel behind — and that anxiety drives people toward tool mastery instead of problem clarity.

This has always been a challenge in IT. But AI made it significantly worse for two reasons.

First, the tooling changes faster than any previous cycle. Not annually. Not quarterly. Sometimes weekly. Second — and this is the part people aren’t saying loudly enough — AI has made it easier than ever to generate code without understanding the problem underneath it.

We used to call it copy-paste coding. You grabbed something from a book, a forum, or a blog post, dropped it in, and shipped it. The code worked, mostly, but no one could tell you why. Now we call it vibe coding. The delivery mechanism changed. The temptation didn’t.

Coding Is No Longer the Bottleneck. That Should Terrify You.

Here’s the part that doesn’t get said in polite company: writing code used to be the candy.

You sat through the ambiguous requirements meetings, tolerated the ticket backlog, dealt with the organizational friction — and eventually you got to the fun part. You got to build. That reward loop kept a lot of engineers motivated through everything else.

AI just took a big bite out of that reward.

The model can write most of the code for you now. Which means code is rapidly becoming what it probably should have been in many contexts all along: a black box hidden behind a contract.

But here’s the critical difference. AI-first programming works only if you can articulate the business problem clearly before you generate a single line of code. It requires product requirement documents. System architecture definitions. Clear thinking about what a service is supposed to do, what its inputs and outputs are, and where the boundaries live.

That work was always necessary. But it was easy to skip because you could just start coding and figure it out along the way. That shortcut is closing.

The Real Obstacle to AI Adoption Nobody Is Talking About

There’s a question underneath all of this that most AI conversations never reach:

Not in a philosophical sense. In a documented, operational sense.

Do you have your workflows mapped? Your value streams identified? Your capabilities defined? Do you know which of your processes are deterministic — rules-based, repeatable, automatable — and which are stochastic, requiring judgment, context, and human discretion?

Most organizations don’t. Not because the work isn’t important, but because it was never required to ship software. You could build around the gaps, paper over them with tribal knowledge, and move on.

AI doesn’t let you do that.

To deploy an AI system that reliably executes a business process, you have to be honest about what that process actually is. You have to separate the parts that follow rules from the parts that require judgment. You have to define the contract before the model can honor it.

That is hard work. It’s not glamorous. It doesn’t come with a cool GitHub repo or a demo you can post on LinkedIn. But it is now the work.

This is the real obstacle to enterprise AI adoption — not model quality, not compute costs, not security concerns. It’s the fact that most organizations haven’t documented their standard work well enough to automate it cleanly. The old SOA material I’ve been updating put it plainly: the risk in tactical, project-by-project approaches is duplicate investments, incompatible infrastructure, and brittle solutions. That warning landed in 2008. It lands just as hard today.

What This Means for IT Leaders and Architects

If you’re a CIO, CTO, or enterprise architect, the AI conversation in your organization isn’t primarily a technology decision. It’s an architectural honesty question.

Before you invest in another model, another platform, or another proof of concept, ask four questions:

• Do your teams understand the business problem well enough to define the contract before touching the code?
• Have you mapped which processes are rules-based and which require judgment?
• Do you have value streams and capabilities documented at a level where an AI system could act on them reliably?
• Are your architects and engineers being evaluated on problem-solving — or on tooling trivia?

If the answers are uncomfortable, that’s useful information. The AI conversation is premature until the architecture conversation happens first.

The Shiny Nouns Will Keep Changing

SOA became microservices. Microservices became serverless. Serverless became AI-native. The vocabulary will keep shifting.

But the underlying question — how do we build modular, reusable, loosely coupled systems that align to what the business actually needs — has not changed and will not change.

The teams that recognize that pattern will stop chasing every new framework and start building the architectural foundation that makes any framework work.

That’s what SOA Right Away was about when it was written. It’s what the updated SOAi framing is about now.

Tags: #AIArchitecture #SOA #SOAi #EnterpriseAI #AIFirstProgramming #VibeCoding #ContractFirst #BusinessArchitecture #ITLeadership #AIAdoption #GRASP #OOP