AI Writes the Code. Someone Still Has to Architect It.

I've been shipping code with AI in the loop for a while now, and the experience has split cleanly into two halves. One half is the most productive I've ever felt: I describe a component, hand over a few constraints, and a working implementation lands in seconds. The other half is the part nobody is talking about loudly enough — the moment you zoom out from a single file or feature to the whole system, the productivity gap reverses. The agent that just wrote a perfect React component starts making decisions that quietly contradict three other parts of the codebase.

That contradiction is the thing I want to think about. AI is genuinely brilliant at local implementation. It's still surprisingly weak at system-level coherence. And a lot of the practices we used to call "architecture" or "design patterns" — the ones that felt like they might become AI-era casualties — turn out to be exactly the structures that keep AI-generated code from drifting.

Where AI Genuinely Excels: The Local Picture

Give AI a clean problem with clean edges and it's stunning. A focused unit of work — a function, a component, a migration script, a test — is the shape AI was built to fill. Within that frame, it knows the idioms, names things reasonably, handles the obvious edge cases, and writes code that often beats the median junior engineer on the team.

Concretely, this is where I've watched it shine:

A specific component to build, with a specific shape: form, table, modal, queue handler.
A bounded refactor inside one file or one well-typed module.
A new entry point with a clear contract: an API route, a CLI command, a webhook handler.
A spike or prototype where the goal is to learn something fast and throw the result away.

What all of these have in common is that the context that matters fits in the prompt. The decisions are local. The constraints are local. The unintended consequences are local. AI is excellent at reasoning inside a well-fenced field — and giving it that field is genuinely a productivity multiplier.

To be clear: this isn't a small thing. The local picture is where most engineering hours actually go. A tool that compresses that work is a tool that changes how teams ship.

Where the Picture Drifts: System-Level Coherence

Now zoom out.

I'm not the only one feeling it. Martin Fowler, in his ongoing Emerging Patterns in Building GenAI Products, keeps circling back to the same observation: AI accelerates code generation, but architecture, refactoring, and testing matter more in this era, not less. That's the gap. The code works. The tests pass. The integration is wrong.

This is what "architecture by autocomplete" — a phrase that captures the failure mode perfectly — tends to look like in practice:

A new endpoint introduces a fourth way of doing auth, parallel to the three the codebase already has.
A new component re-implements logic that lives in a shared util two folders away.
A new state machine duplicates an existing reducer's responsibilities under a new name.
A new module reaches across a boundary the rest of the codebase has been carefully respecting.

None of these are bugs, exactly. They're decisions — quiet ones — that pull the system in a slightly different direction than every other decision around them. And because they compile, type-check, and pass review-by-vibes, they tend to land. Multiplied across a quarter of shipping, you don't get a broken system; you get a blurry one. Patterns smear. Boundaries soften. The mental model the team had stops matching the code.

The deeper reason is structural. AI agents in 2026 are still fundamentally better at prediction inside a context window than at reasoning across a system. Even with retrieval, even with bigger context windows, the model is choosing the most plausible-looking next token given what it can see — and what it can see is almost never the entire system. Local plausibility is not global coherence.

The cheapest tell that an AI suggestion is local-only is a name collision: it introduces formatDate, useAuth, or apiClient when one already lives somewhere in the repo. Treat that as a tap on the shoulder — there's almost certainly a sibling decision the model didn't see.

The Job That Doesn't Go Away: Pattern Custody

Here's where I land: the architect role — or whatever a given team calls the person who holds the system's shape in their head — has not been deprecated. If anything, AI has sharpened its edges and made it more visible.

The work that still needs human attention, in roughly the order I notice it mattering:

The shape of the system. What are the boundaries? Which modules own which decisions? Where does state live and how does it flow? AI is happy to add a fifth pattern alongside four existing ones; it takes a person to say "no, we're picking one of the four."
The patterns the team commits to. Auth, error handling, data fetching, logging, naming, file structure. These aren't glamorous, but they're the rails AI runs on. A team with explicit rails gets dramatically more value out of AI than a team with implicit ones, because the model has something to align to.
The taste calls. Which complexity to absorb now versus push out. Which abstraction earns its weight. Which feature actually deserves to exist. The recent Pragmatic Engineer conversation with Martin Fowler keeps circling the same shift — from "how do we write this?" to "should we, and how does it fit?" That second question is doing more of the heavy lifting than ever.
Knowing when to stop AI from being efficient. Sometimes the right move is not to accept the working suggestion. The cheapest moment to undo a drift is before it compiles.

I want to be careful here, because the picture isn't static. AI's reach into architectural reasoning has improved meaningfully, and it'll keep improving. There are agents now that can plan across a repo, propose multi-file refactors, and even argue with themselves about trade-offs. That's real progress, and I use those tools daily. But "improving" isn't "solved" — and the gap between local brilliance and system-level coherence is still wide enough that closing it is a person's job.

In The Future of Frontend Is Quietly Changing, I wrote that UI is shifting from a starting point to a byproduct of intent. Architecture is going through a parallel shift, just less loudly: it's moving from something you write to something you enforce — through patterns, boundaries, and the quiet, unglamorous work of saying we already do that, and we do it like this.

Patterns still matter. Maybe more than ever. They're the thing that lets a team accept an AI suggestion at speed and trust that it won't slowly bend the system out of shape.

AI made local implementation cheap. That makes the rare, expensive thing the architecture itself — and the person who keeps it coherent.