Claude Is Not Your Architect. Stop Letting It Pretend. — HollandTech<br>Get in touch

I’ve seen it three times in the last month. Three different organisations, three different tech stacks, the same pattern.<br>Someone has an idea. Maybe a product manager, maybe a team lead, maybe the CTO after a conference. They open Claude, or ChatGPT, or Copilot — doesn’t matter which — and ask it what they should build. The AI does what it always does: validates the idea enthusiastically, suggests an architecture, and starts sketching components. It’s articulate. It’s confident. It sounds like a very senior engineer who’s thought deeply about the problem.<br>It hasn’t thought about the problem at all. It’s pattern-matching against its training data and producing the most plausible-sounding response. But it sounds so good that nobody pushes back.<br>Before you know it, Claude is the architect.<br>The attaboy problem<br>AI agents are pathologically agreeable. Ask Claude if your idea is good and it’ll tell you it’s good. Ask it if a microservices architecture makes sense for your three-person team and it’ll explain why microservices are an excellent choice. Ask it if you should build a custom ML pipeline instead of using a managed service and it’ll enthusiastically lay out the design.<br>It’s not lying. It’s not even wrong, necessarily. It’s just incapable of the thing that makes a real architect valuable: saying “no.”<br>A good architect’s most important skill isn’t designing systems. It’s knowing which systems not to build. It’s pushing back on complexity. It’s asking “why?” five times until the actual requirement emerges from the aspirational nonsense. It’s telling the CTO that their conference-inspired idea is a terrible fit for the team they actually have.<br>Claude will never do this. It’s trained to be helpful. Helpful means agreeable. Agreeable means you get an attaboy and a Jenga tower that passes for architecture.<br>The Jenga tower<br>Here’s what the AI-designed architecture looks like in practice.<br>It’s technically sound. The components make sense in isolation. The patterns are recognisable — event-driven here, CQRS there, a service mesh because why not. It looks like something a senior architect would produce. It passes the squint test.<br>But it wasn’t designed for your team. It wasn’t designed for your constraints. It wasn’t designed for the boring reality of your production environment — the VPC lockdowns, the legacy integrations, the team that’s never operated Kubernetes in production, the compliance requirements that mean half the managed services are off-limits.<br>It was designed for the median of everything Claude has seen. A generic best practice for a generic problem at a generic company. Which is to say, it was designed for nobody.<br>Real architecture is full of trade-offs that only make sense in context. You pick Postgres over DynamoDB because your team knows Postgres and you’d rather ship in two weeks than spend a month learning a new data model. You skip the service mesh because you’ve got four services, not forty. You use a monolith because the problem is simple and microservices would be career-driven development.<br>These decisions require judgement. They require knowing the team. They require understanding the organisation’s actual constraints, not the ones that look good on a whiteboard. An AI agent has none of this context, and worse — it doesn’t know it doesn’t have it.<br>The Jira ticket pipeline<br>The bit that really worries me is what happens next.<br>Once Claude has designed the architecture, the same people who asked it for the design ask it to break the work down. It produces epics. Stories. Acceptance criteria. Neatly formatted, well-reasoned, ready to drop into Jira.<br>And now the engineers — the people who’ve spent years honing their craft, who understand the domain, who know where the bodies are buried — are no longer solving problems. They’re implementing Claude’s design, one ticket at a time.<br>Think about what’s happened here. The people with the most context, the most experience, and the most skin in the game have been reduced to ticket implementers. The entity with the least context, no experience, and no accountability is making the architectural decisions.<br>It’s not just inefficient. It’s backwards.<br>”But someone senior signed off”<br>This is the defence I hear most often. “Claude suggested the approach, but a senior engineer reviewed it.”<br>Let’s be honest about what “reviewed it” means in practice. A busy tech lead gets handed a well-articulated architectural proposal. It’s coherent. It uses the right terminology. It addresses the stated requirements. The diagrams make sense. It looks like something they might have designed themselves.<br>How much pushback are they going to give? In a world where the response to “I don’t think this is right” is “Claude spent twenty minutes on this and you want to throw it away?”, the path of least resistance is to approve it with minor comments.<br>This is the real danger. Not that AI produces bad...