The Architecture Was Always the Job

Most of what gets written about AI coding tools is about building. How to prompt better. How to get Claude to write the function. How to stitch together a skill, an MCP server, a webapp. I have written a bunch of that. Those pieces are useful but they share a hidden assumption: that the hard part is getting the AI to produce the thing.

That has not been the hard part for a while. The hard part is knowing what should exist, understanding how the pieces fit together, and being able to describe what you want at the level where the system runs. AI made that skill more important, not less.

The word for that skill is architecture.

The Hard Part Was Never the Code

If you have worked in ops or commercial engineering for long enough, you already know this. The hardest parts of most projects were never the code. They were the upstream questions. What does this system need to do, how does the data flow, what happens at the boundaries? Where are the risks, who owns each piece, what breaks if this component fails?

A spreadsheet that grows into a tangle of nested VLOOKUPs is not a code problem. It is an architecture problem. A process that sends CSVs between two teams because they cannot agree on a shared system has the same diagnosis. A skill that works for one person but cannot handle a team’s workflow: also an architecture problem.

For a long time, the people who could see the architecture were usually not the people who could build the fix. Engineers had the build capability. Ops leads had the architectural view. Most ideas died in the handoff between them.

AI tools dissolved that handoff. The person with the architectural view can now also be the person who builds. The architectural view went from being one input into the work to being the work itself.

A VFX Artist Says It Out Loud

Niko Pueringer of Corridor Crew put this plainly on a podcast recently. Not a software person. A VFX artist. He was talking about an Arduino-based rig he built for a short film: a microphone detects the sound of an airsoft gun firing, and a dimmable light triggers a bright flash a fraction of a second later, giving actors actual muzzle-flash lighting on camera without a blank-firing weapon. Niko does not know electronics. He built it with Claude.

How he described the skill the build required says more than the build itself.

“You need to have a full, top-to-bottom understanding of how the system works,” he said. “Like, how is my weird electronic microphone light detector thing going to actually work? I need to know top to bottom exactly how it works. But writing the actual code and which exact module to buy, I can work through that. I can figure that out.”

That is architectural thinking stated plainly. The code and the module numbers are interchangeable parts, sourceable from an AI. The structure of the system, the signal flow, the component relationships. Those had to be in his head. Claude could not assemble them for him, because Claude could not know whether the resulting thing would do what the scene needed.

He had other language for the same idea, borrowed from his own world: “You have to bring a very strong vision, even if you don’t know any of the specific answers.” And: “You wanna constantly question your assumptions the whole way through one of these things.”

Strip the film-world vocabulary and what is left is architecture, problem description, and skepticism: the standard kit for a systems thinker.

What Architectural Thinking Is

“Architecture” is one of those words that can mean almost anything if you let it. In this context I mean something specific.

Keeping the structure of a system in your head. Not mastery of every component. Enough grasp to know what the pieces are, how they connect, what data moves between them, and where the edges are. If you cannot sketch the system on a napkin, you cannot direct an AI to build it correctly. You will not notice when the AI’s suggestion subtly breaks the structure.

Knowing what you want before you ask. The bottleneck in most AI interactions is that the person has not yet decided what good looks like. They know something is off. They cannot say what. AI tools raise the value of this skill sharply, because they do exactly what you ask for. Vague asks produce vague results.

Describing problems at the right level. Not too low (micromanaging implementation details you do not care about). Not too high (“build me a thing that does the work”). The level you want is the one where the architectural decisions get made, where the system’s structure is being chosen. This is a skill that rarely gets practiced, because before AI there was no need to. You used to describe problems to a person who already knew the domain. Now you describe them to a tool that does not, and getting the level right matters enormously.

Questioning assumptions while the work is happening. AI will confidently produce plausible-looking answers to the wrong question. If you are not checking whether the premises it is building on are still correct, you will not catch the drift. You end up three layers deep in a polished-looking answer that was solving the wrong problem from step one. The work of noticing “wait, is that true?” is not glamorous, but it is where architectural thinking most obviously separates from prompting.

This Is Not a New Skill

For the ops and commercial leaders I usually work with, these are not new skills. Your best people already have them: articulating a messy process, tracking a system end-to-end, knowing what done looks like when nobody else can see it yet, catching the wrong assumption before it spreads.

In a previous piece I used the phrase “architectural literacy” to describe what ops teams need in order to work effectively with AI tools. I would use a stronger word now: fluency. Ops leads who can describe a system crisply, reason about its data flows, and notice when a proposed solution breaks the structure: those people were always architects. They just had no path to act on it, because the build capability sat somewhere else.

Three Apps, One Platform

Recently I was working on a stack of related problems for a customer support operation. Three discrete projects, each born from a different request. The first was about finding patterns in case volume: what were customers asking, and which themes were missing from the knowledge base. The second was a deflector: given a new incoming case, suggest the right knowledge base article before a human had to touch it. The third was an audit layer for the replies support agents were sending out, so the quality of those responses could be scored and improved over time.

I built each of them with Claude, one at a time, as the requests came in. They worked. But somewhere in the middle of the third one I stepped back, and the structure of the whole came into focus. All three projects were working against the same back end. They drew from the same case database, the same knowledge base, the same support platform where agents and customers met. I had been treating them as three apps because that was how they had been requested. Architecturally they were one platform with three modules.

The refactor that followed was small, and it started with a description. I told Claude, plainly, what I had just noticed. These are not three projects but one platform with a shared data layer and a set of independently runnable modules. The workflow needs to decide which module fires for which case at which point in the interaction. That sentence was the architectural move. The build that followed was straightforward because the structure was right.

What the AI could not have done, at any point in that process, was the stepping-back. Each project, asked on its own, produced a perfectly competent answer. None of them would have noticed that the three projects shared a single interaction surface and should collapse into one. That observation is what architectural thinking looks like in the wild. The work it unlocks is not visible until someone does it.

What This Means for Teams

If that is the work, a few things follow.

It means the person you want building internal tools is not necessarily the one who writes the best code. The better fit is someone who can sit down with an ops lead, understand the process they are describing, picture the system in their head, and direct an AI to build the piece that is missing. That is closer to a solutions architect who ships than to a traditional engineer.

It means training ops and commercial teams on AI tools is about developing the architectural muscles, not tool mastery: how to describe a system, how to notice an assumption, how to articulate what good looks like. The tool itself is the easy part to teach.

And it means that when you watch someone work with AI well, you are watching the clarity of their architectural thinking made visible. The prompts are downstream of that.

The Arc So Far

The same thread keeps showing up across these pieces: as building gets cheaper, the hard part moves upstream of building. Knowing when to graduate a tool. Knowing whether to build it at all. Knowing what to ask for, and knowing enough about the answer to tell when it is wrong.

That upstream skill is architecture. The work did not get easier. It moved one step earlier, to the part of the job that was always hardest to teach. Which might be the good news here. What survives is the hard part itself.

I run workshops on building architectural fluency for ops and commercial teams, and you can reach me at [email protected].