"Use AI where the work is, not where the trust is."
I read that in a LinkedIn post last week and it stuck, the way a phrase does when it names something you have already built but never described. I went and looked at my own setup with that sentence in mind, and found that it was close to right and wrong in an interesting place.
The neat version of the line goes like this. AI does the research, the brainstorming, the structure, the code. You do the real thinking, the vision, the judgment. Two bins, sort your tasks, keep the important ones.
That is not how it works for me. AI is in my thinking constantly. I draft something rough and get pushback on the parts that do not hold. I notice the framing I am leaning on too hard because something asked me why. The thinking is not happening somewhere clean and separate while the machine handles the labor. It is happening in the conversation.
So the line is real, but it is not between tasks. It is between roles.
Two agents that cannot become each other
I work with an architect and a builder, and they are not allowed to be the same thing.
The architect shapes the project. It writes the documentation, holds the reasoning, guides the builder. It has opinions and it argues for them. It does not execute. Not because it could not, but because the moment it can, the reasoning and the doing collapse into one place and I lose the seam.
The builder executes. It has opinions too, and it offers them, and sometimes they are better than the architect's. It does not decide. If it hits something that turns out to be architectural, it stops and asks.
I am in the middle. I make the calls on features, architecture and vision. That is the whole design: nothing in the system can both decide and execute without passing through me.
There is a practical version of this that is about model tiers. Stronger model for the architect, faster one for the builder, spend the capability where the reasoning is. That is true, and it is how I run it. It is also not why the split exists. I would want this separation if both agents ran the identical model, because the point is not capability. The point is that decisions and actions should not live in the same place.
The thinking happens before the building
Before I start a project, there is a stack of documents. A vision document. A PRD. Architecture. A handoff briefing for the builder. A deferred-items list for everything that is a good idea and not for now. A decision log. A source of truth.
That is a lot of writing before a single line of code. It is slow. Most people would not bother, and I understand why.
What it buys is that the thinking is done in a place that persists, so the agents inherit decisions instead of re-deriving them. An agent that re-derives a decision will sometimes derive a different one, confidently, and you will not notice because the new answer is as well-argued as the old one. Writing it down is not bureaucracy. It is the thing that stops the project from quietly becoming a different project.
There is a second stack, smaller, that does something else. A set of files that tell the agents what they are allowed to decide. Not what to do. What they are permitted to settle without asking. That distinction is the whole of it, and it is worth writing down explicitly, because an agent with no stated boundary will assume it has none.
Where I have got this wrong
Four ways, and the last one is the one that matters.
I have started projects in Claude Code with no vision and no direction, because the thing seemed small enough to skip the documents. It always ends the same way. It sprawls, I end up making architectural decisions in the middle of implementation, and I either refactor it or abandon it. The discipline is worth least on the big projects, where I would do it anyway. It is worth most on the small ones, where I am tempted to skip it.
I have worked from documents that had gone stale. The agents kept working from them faithfully and produced things that were internally consistent and wrong, because the ground had moved and the document had not. A confident agent working from an outdated spec looks exactly like a confident agent working from a current one. This is why every significant decision now goes back into the architect's documentation and forward to the builder, and why the decision log exists.
I have watched the architect be confident and wrong, which is the failure mode you get precisely because you put a strong model in the role. Well-reasoned, plausible, and off. The only defense is that I am holding the end goal in my head and I question it. Twenty-five years of building things helps. Thinking in systems helps. Rubber-stamping does not, and a strong architect is very easy to rubber-stamp.
And then the real one. I have approved something the builder proposed without telling the architect.
It was faster. The builder had a good idea, I could see it was a good idea, and routing it back through the architect felt like ceremony. So I said yes.
Now two parts of my system are working from different facts. The builder is building against a decision the architect does not know about. The architect is still reasoning from the world as it was ten minutes ago. Nothing breaks immediately. It breaks later, quietly, in the place where the two versions of reality meet.
That is the failure the design cannot prevent, because the design's single point of failure is me. Everything is routed through the middleman, which means the middleman being helpful is the one thing that can corrupt it. Saying yes is always faster than routing it.
The exception I actually run
Here is the part that undercuts the neat version of all this.
Sometimes I let the builder take a full task list and go. No check-ins. Report back when it is done and tested.
That is the middleman stepping out of the middle, and I do it anyway, because being in every loop has a cost and sometimes the cost is not worth paying. The task list is approved first, by the architect and by me, which is what makes it safe enough. But it is still a deliberate exception to the principle, and I would rather name it than pretend the system is purer than it is.
A rule you never break is usually a rule you have not tested. This one has an exception, I know when I am taking it, and I know what I am trading.
What it actually changed
I expected this to make me faster. It does, but that is not the interesting part.
For years I did not build big things. Not because I could not code. Because I knew what a big application actually means. Authentication, roles, permissions, edge cases, admin screens, deployment, security, the hundred small decisions that all quietly matter. I would look at a large idea and feel the whole weight of it at once, and the weight was the thing that stopped me.
I do not feel that weight now. The architecture lives somewhere. The building happens somewhere else. I sit at the join and make the calls that need a person. I am not holding the whole system in my head at once, which means I can look at something large and think: that is buildable.
It is not that I got better at this. The structure around the work changed, and the ceiling moved.
That is what I would take from the line this article started with, adjusted. It is not that you should keep AI away from the parts you trust yourself with. It is that you should decide, in advance and in writing, where the decisions get made and who makes them. Do that, and you can let AI much further into the work than the neat division suggests, because the trust is not living in the tasks.
It is living in the structure.
Originally published on LinkedIn.