A post titled "Claude is not your architect. Stop letting it pretend" hit 182 points on Hacker News this week, and the title is doing most of the work. The argument underneath it is the right one — but the framing makes it sound like a model limitation, and after six months running ~70 MCP tools with the agent driving roughly 80% of my code, I think that framing lets teams off the hook for the actual failure.
The post's claim is simple: Claude will confidently produce an architecture when you ask it to, and that confidence is unearned, because it has none of the context an architecture decision actually requires — your traffic shape, your team's on-call tolerance, the three integrations that will break, the migration you half-finished last quarter. So it pattern-matches to the most common shape in its training data and hands it back with the tone of a senior staff engineer. Agree completely. But "stop letting it pretend" reads as if the fix is to distrust the model. The fix is to fix your own boundary.
The agent doesn't decide where the boundary is — you do
Here is the line that matters in practice: an agent will make exactly as many architecture decisions as your workflow lets it make. If you open a fresh session and type "design the auth system for this app," you have already handed it the decision. It did not seize it. You delegated it and then got surprised that the delegate had no context.
In my own setup the boundary is not a vibe, it is mechanical. I run five channel servers, each with its own brain prompt, and not one of those prompts lets a subagent pick an architecture. The Swayam automation brain, for example, has a hard rule that it does not write code or edit files unless a routine prompt explicitly asks — and architecture changes are never what a routine prompt asks for. When a subagent hits something that needs a structural decision, the rule is to escalate with a Needs code fix: line back to me, not to invent the structure and ship it. That is one line of prompt doing the entire job the HN post is asking a human to do by force of will.
Where I let it decide, and where I don't
Six months of logs gave me a fairly crisp split. The agent decides freely inside a decision someone already made. It does not get to make the framing decision.
It writes the SQL once I have decided the table exists and what it holds. It does not get to decide whether that data lives in Postgres or in a per-user event log — I made that call across the whole memory layer and the agent inherits it. It picks the variable names, the error-handling shape, the test cases. It does not pick whether a new capability is a fifth MCP server or a tool on an existing one, because that decision ripples across the brain prompts, the SSE filters, and the push-notification routing, and the agent can see exactly one file at a time.
That last point is the real mechanism, and the HN post under-sells it. The reason the agent makes bad architecture calls is not that it is dumb. It is that an architecture decision is the one kind of decision defined entirely by what is not in the current context window — the constraint two repos over, the incident from March, the thing you decided never to do again. The agent is structurally blind to exactly the inputs that decision needs. Asking it to architect is asking the one actor in the room with the least context to make the most context-dependent call.
The discipline that actually works
I wrote a few months ago that Claude Code's large-codebase guide stops where the hard part starts — the moment you cross a repo boundary, the model is working from a keyhole. Architecture is the same problem one level up. So the rule I run is: the agent gets the decision after the boundary is drawn, never the boundary itself.
Concretely, that means three things. I write the one-paragraph "here is the shape and here is why" myself before any session that touches structure — not because the agent can't draft it, but because writing it forces me to hold the off-screen constraints. I let the agent generate two or three implementations of a decided shape and argue them against each other, because that is genuinely where it is strong. And I treat any session where the agent proposes a new structural shape unprompted as a signal that I under-specified the task, not as helpful initiative.
That third one took the longest to internalize. The agent volunteering an architecture feels like a feature. It is a tell that you left the boundary undefined and it filled the vacuum with the median of its training set.
Why this matters
"Stop letting it pretend" is good advice aimed at the wrong layer. The agent is not pretending — it is answering the question you asked, with the only context it has, which is almost none of the relevant context. The pretending, if there is any, is on the human side: pretending that delegating a decision is the same as the decision being made well.
The portable version of the lesson is cheap to apply. Draw the boundary in writing before you open the session. Keep the framing decisions — what lives where, what is a new server versus a new tool, what you decided never to do again — on your side of the line, in a place the agent reads but does not author. Everything downstream of a drawn boundary is fair game, and the agent is genuinely excellent there. The architecture is not a thing it should pretend to do. It is a thing you should stop pretending you delegated.