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 the system actually lives at. AI did not make that skill less important. It made it the only skill that still matters.

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 actually 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 is not a code problem. It is an architecture problem. A skill that works for one person but cannot handle a team’s workflow is not a code problem. It is an architecture problem.

For a long time, the bottleneck was that 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. The handoff between them was where most ideas died.

AI tools dissolved that handoff. The person with the architectural view can now also be the person who builds. Which means the architectural view is no longer one input into the work. It is the work.

A VFX Artist Says It Out Loud

The clearest articulation of this I have heard recently came from Niko Pueringer of Corridor Crew. Not a software person. A VFX artist. He was on a podcast 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 real muzzle-flash lighting on camera without a blank-firing weapon. Niko does not know electronics. He built it with Claude.

The part that stuck with me was not the build. It was how he described the skill the build required.

“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 shape of the system, the signal flow, the component relationships. Those had to live in his head. Claude could not assemble them for him, because Claude could not know whether the resulting thing would do what the scene actually 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 three things a good systems thinker has always had to bring.

What Architectural Thinking Actually Is

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

Holding the shape of a system in your head. Not mastery of every component. Enough structural 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 shape.

Knowing what you want before you ask. The bottleneck in most AI interactions I watch people struggle with is not the AI. It 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 enormously, 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 actually care about). Not too high (“build me a thing that does the work”). The right level is the one where the architectural decisions live. The level where the system’s shape is being chosen. This is a skill most people do not practice, because before AI they never had 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 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 actually true?” is not glamorous, but it is where architectural thinking most obviously separates from prompting.

This Is Not a New Skill

Here is the part that matters for the ops and commercial leaders I usually work with: these are not new skills. They are the skills your best people already have. Articulating a messy process. Holding a system end-to-end. Knowing what right looks like when nobody else can see it yet. Catching the wrong assumption before it compounds.

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 want to be more direct now. It is not literacy. It is fluency. The ops leads who can describe a system crisply, reason about its data flows, and notice when a proposed solution breaks the shape. Those people were always architects. They just had no path to act on it, because the build capability sat somewhere else.

Noticing the Shape

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 actually 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 system shape came into focus. All three projects were operating on the same surface. They drew from the same case database, the same knowledge base, the same support platform where agents and customers actually 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 not large. It was 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 entire architectural move. The build that followed was straightforward because the shape 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 surfaced the observation 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 person who writes the best code. It is the person who can hold a conversation with an ops lead, understand the process they are describing, sketch the system shape in their head, and then 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 not really about tool mastery. It is about developing the architectural muscles: 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, what you are actually watching is not their prompting technique. It is the clarity of their architectural thinking made visible. The prompts are downstream of that.

The Throughline

Across the arc so far, the same thread keeps surfacing: as building gets cheaper, the skill that matters is the one 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 place where it always mattered most and was always the hardest to teach. Which might be the good news here. The skill that survives is the one that was always doing the real work.

If you want to build architectural fluency on your ops or commercial team, I run workshops on exactly this. Reach out at hello@escapecommand.com.