You Didn't Become the Architect. The Handoff Got Cheap.

There is an argument going around about whether AI turned everyone into an architect. It is the wrong argument, and teams are going to pay for it in a specific way.

Someone posted this week that they had become the architect. They make the directional decisions and steer the agents. The best comment underneath asked when architects started writing every line of code, because that was the developer's job.

Both of them are right. That is the problem.

A job title is not one thing. It bundles a set of handoffs under one name, and then people argue about the name.

Architect and developer were never separated by skill. Plenty of architects came up coding. Plenty of developers think structurally about what they build. What separated them was a handoff, right? One person decided, wrote it down, and a different person executed it.

That handoff had a price. It was worth paying for as long as writing a decision down precisely enough for someone else to build it stayed cheaper than building it yourself. So organizations bought it, over and over, until the buying pattern hardened into an org chart with two job titles on it.

AI inverted the price. Describing the work well enough for a machine to execute it is now most of the work.

So both sides of that thread are describing the same event. One says he is the architect now. The other says then he is doing the developer's job. Neither can win, because the boundary they are arguing about stopped charging rent and nobody sent a notice.

If a skill bar had been raised, movement would run one way, toward the harder skill. That is not what is happening.

Architects with an affinity for code are writing and reviewing more of it. Developers who were already strategic are making architectural calls. And the AI product manager job is turning into an AI-focused solutions architect with product capabilities on top. Three directions, one cause. People arriving at the same place from wherever they started is what a removed wall looks like.

Here's the thing. One wall came down, and the conclusion being drawn is that walls are over.

A role boundary sells four things, and only one of them got cheap.

Capacity. Someone else has the hours. This is the one that collapsed. Did you write the ticket only because you did not have time to write the code? Then it is overhead you are still paying for.

Judgment. Someone else knows something you do not. This does not collapse. It inverts. You stop sending a document and start arguing the thing at depth, in the room, with the person who knows it.

Accountability. Someone else is on the hook. Service levels, continuity guarantees, regulatory sign-off. No agent takes this off your hands, and no amount of good engineering turns it into a technical problem.

Veto. Someone else can say no. Security, enterprise architecture, the platform team. A veto is indifferent to how good your reasoning is.

So the question was never whether the boundary is obsolete. It is which of the four you were actually buying, and one question tells you.

Can you verify the output yourself, without the other person?

If yes, it was capacity, and it is already gone whether the org chart has noticed or not. If no, it is one of the other three, and those three behave nothing alike.

I had a list to test this on. A while back I wrote out eight things I actually do on an AI program. I was trying to work out what to call the role, honestly, and I wanted to see it written down. Sorted by what each handoff sells, the list stops being a job description and starts being an answer.

Eight things. One and a half of them are the thing that got cheap.

The split one is worth opening up, because it is where people assume the whole category went. I built a test harness with Claude Code that sits side car with the real code. Then a skill that creates an abstraction over it, so as the code changes the harness evolves instead of rotting. It runs tests designed for probabilistic output and recommends fixes when they complete. Writing and maintaining those tests was capacity, and it collapsed. For a lot of teams that work is kind of the entire reason QA existed as a separate stop on the way to production.

What did not collapse is deciding what correct even means for a probabilistic output. Neither did reading a result that is a distribution instead of a pass. You cannot hand someone a green check when the honest answer is "this is right about as often as it was last week, and here is the shape of the wrong."

Designing that test and reading that result are one judgment. Split it across two people and the number stops meaning anything. So I run them instead of designing them and handing them over. And that is the cheap version of this mistake, because getting it wrong there costs you a bad number. The other three categories cost more, and they bill on their own schedule.

Collapse a boundary you were not buying capacity from and you do find out. The useful part is knowing when.

A veto bills immediately. Someone blocks you and you know that day. This is the cheapest failure in the set. It is also the one people complain about most, which tells you something about how we rank pain. You do not collapse a veto. You go win it, and winning means holding the conversation at their depth long enough to get to yes. You are not going to out-specialize a security architect. You have to stay in the argument with one.

Judgment bills in the middle distance. You make a confident call in a domain you half understand. It surfaces weeks later as something that does not work the way you said it would. This is where the range problem lives. Being wrong about an ingress rule is not the same class of wrong as being wrong about a roadmap slide, and the feedback arrives a lot later. It is also where the second pair of eyes went. A handoff was a review, and deleting it deletes the review, and you will not notice the day it stops catching things.

Accountability bills last, and it punishes silence. Nothing breaks on the day you absorb it. It breaks much later, and by then nobody remembers there used to be a handoff there at all. Absorb it quietly and you have not saved a step, you have moved a liability onto yourself and told nobody. This is the only one of the four where the absence of a problem is not evidence of anything.

Two costs sit underneath all three and never show up on a timeline. You own the pager for everything you collapsed, because nobody else has enough context to take the page. And the work no longer has a written interface. Which is another way of saying nobody can take it over, and that it does not scale past your calendar.

There is no measurement in here. No before and after, no cycle time, no cost per feature, no headcount that moved.

It is a pattern I have watched across the engagements I have led, plus a set of decisions I made in one specific week and a harness that exists and does what I said it does. The four categories are my sort, not a finding. Run it on your own project, and if it comes out differently, your project is better evidence than my argument.

I have asked publicly what to call this job. Twice. Nobody had a good answer, including me, and I spent a while treating that as an interesting puzzle.

I think it was a symptom. A title is a summary of which handoffs a person owns. You cannot summarize handoffs that are still mid-argument, so the naming problem sits downstream of the sorting problem. Everybody keeps trying to solve the naming one first because it is the easier one to have an opinion about.

So the work is not finding a name. It is finding out which of the four you were buying, before you cancel the subscription on all of them.