AI changed who can build.

It did not remove the need for judgment, it moved where judgment matters.

A few years ago, building a working application was itself proof of technical capability. Today, a non-technical person can describe an idea to an AI tool and have a surprisingly credible application running in a weekend.

That is a real shift, and architects should not pretend otherwise.

But it has also created a new assumption: if almost anyone can build software now, perhaps we no longer need the developers, architects, and specialists who used to make it possible.

I think that conclusion gets the change exactly half right.

The question is no longer whether you need an architect, but when.

AI makes experimentation cheaper and more accessible. That means more ideas can be validated, more prototypes can become real products, and more systems will eventually reach the point where architecture, judgment, and specialist expertise matter.

---

Quick index

1. The implementation barrier moved
2. The demo boundary
3. Existing systems create a different problem
4. The architect’s role is moving upward
5. What business leaders should do differently

---

The implementation barrier moved

The old boundary was implementation. You needed technical expertise simply to get an application working.

AI has pushed that boundary much further out. It can generate interfaces, APIs, data models, authentication flows, integrations, tests, and deployment configurations very quickly.

For a prototype, an internal tool, or an idea that still needs to prove its value, that may be all you need. And that is a good thing.

The mistake is assuming that because the implementation barrier has fallen, the engineering risk disappeared with it.

The demo boundary

A demo mainly proves that the happy path works.

The real questions tend to appear later, when the software starts dealing with production conditions.

• A payment flow can work perfectly until a retry creates a duplicate transaction.
• A multi-tenant application can look complete until tenant isolation fails.
• An integration can work until the provider rate-limits requests, changes behaviour, or partially fails.
• Authentication can exist while the authorization model underneath it is still wrong.
• A system that performs perfectly for 20 users may behave very differently at 20,000.

This is the part that is easy to miss because the UI may look exactly the same. The architectural difference is underneath.

None of this means every AI-built application needs enterprise architecture. In many cases, the right thing to do is the opposite: build quickly, validate the idea, and avoid adding complexity before it is justified.

Managed platforms and AI tooling also remove a lot of problems we used to solve manually.

The question is which decisions are easy to reverse, and which become very expensive once users, data, and other systems depend on them.

Tenancy, data ownership, authorization, transaction behaviour, critical integration boundaries, and compliance requirements are examples of decisions where early judgment can save a lot of pain later.

Existing systems create a different problem

Greenfield applications are only part of the story. Most enterprise technology work happens inside systems that already exist.

Here, I do not think the useful distinction is legacy versus modern. A better distinction is documented versus undocumented, and conventional versus highly specific to the business.

A 15-year-old system with clear documentation and contracts may be easier for AI to work with than something built last year where the real meaning of the system lives in a few people’s heads.

I recently saw this in a data-science use case involving thousands of fields and billions of records. AI was able to explore behavioural hypotheses, combinations, and edge cases at a speed that would be extremely difficult to reproduce manually.

But it also made mistakes. Sometimes the problem was statistical: something looked meaningful but was really noise. Other times the problem was semantic. A field was interpreted incorrectly, or a relationship between two fields was inferred in a way that made sense technically but not in the actual business context.

Those are not the same problem. Statistical errors need statistical validation. Semantic errors need context: better field definitions, lineage, contracts, and domain knowledge. And this is where the human role gets more interesting.

If the specialist simply reviews AI output one item at a time, review becomes the bottleneck. A better approach is to ask why the result was wrong. If dozens or hundreds of hypotheses depend on the same incorrect interpretation of a field, fixing that assumption can correct an entire class of downstream results.

But only if that correction becomes part of the context the AI uses next time. Otherwise, we just keep correcting the same mistake. That is why I increasingly see the specialist less as a reviewer and more as a diagnostician.

The goal is not only to say, “this is wrong”. It is to understand why it is wrong, what else depends on the same assumption, and how to prevent the same class of mistake from repeating.

The architect’s role is moving upward

This is where I think the role of the architect is changing most.

The value is shifting further away from implementation expertise and toward defining what must be true, what can safely be delegated, which decisions are difficult to reverse, and how the result should be verified.

In existing systems there is another responsibility: make implicit knowledge explicit.

• Document the constraints.
• Define the contracts.
• Encode the semantics.
• Build the safety net.

That may make some of the architect’s personal knowledge less unique, but it makes the whole organization stronger. Architects should also be using the same AI tools aggressively.

AI does not only give a non-technical builder more implementation capacity. It gives an experienced architect more capacity as well.

The architect can move from decision to implementation to validation much faster than before. So I do not think the right response is to defend the work AI is replacing.

The better response is to move toward the work that becomes more valuable because of it.

What business leaders should do differently

For business leaders, the message is not “always bring in an architect.”

• Use AI.
• Prototype quickly.
• Test ideas cheaply.

But recognize when the experiment is becoming a real system.

Specialist involvement matters more when real money is moving, sensitive data is involved, several systems interact, multiple teams depend on the solution, failure has material business impact, or the system is expected to live and evolve for years.

The same applies when you are modifying an existing system that nobody fully understands end to end.

The cheapest time to identify a bad assumption is before production data, integrations, and teams depend on it.

For architects, the message is equally important.

Do not defend the role by saying AI cannot build. It can. And it will keep getting better.

The differentiator is increasingly understanding where the model’s assumptions stop matching the reality of the business, the system, the organization and knowing what to do about it.

The question used to be:

Can we build it?

Increasingly, the harder question is:

Will it survive reality?