클로드를 소프트웨어 아키텍트로 착각하는 위험성

I’ve seen it three times in the last month. Three different organisations, three different tech stacks, the same pattern. 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. 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. Before you know it, Claude is the architect. The attaboy problem 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. 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.” 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. 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. The Jenga tower Here’s what the AI-designed architecture looks like in practice. 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. 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. 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. 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. 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. The Jira ticket pipeline The bit that really worries me is what happens next. 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. 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. 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. It’s not just inefficient. It’s backwards. ”But someone senior signed off” This is the defence I hear most often. “Claude suggested the approach, but a senior engineer reviewed it.” 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. 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. This is the real danger. Not that AI produces bad architectures — it often produces perfectly reasonable ones. The danger is that it short-circuits the discussion. The messy, argumentative, time-consuming process where three engineers disagree about the approach, where someone says “what about…” and everyone groans but then realises it’s a good point, where the final design is better than anything one person would have produced — that process gets replaced by “Claude said so.” The accountability gap Here’s the question nobody’s asking: when it goes wrong, who carries the bag? Not Claude. Claude doesn’t have a bag. Claude doesn’t get paged at 3am. Claude doesn’t sit in the post-incident review explaining why the architecture couldn’t handle the load. Claude doesn’t have to tell the CTO that the platform needs to be rewritten because the original design assumptions were wrong. Your engineers do. The same engineers who didn’t design it. The same engineers who were implementing tickets written by an entity that’s never operated a system in production. They’re the ones staying late, debugging an architecture they didn’t choose, in a codebase that was scaffolded faster than anyone could understand it. That’s not fair. And it’s not smart. What to do instead I’m not saying don’t use AI agents. I use Claude Code every day. It’s transformed my productivity. But I use it the way you’d use any powerful tool — I tell it what to do, not the other way round. Engineers design. Agents implement. The architecture comes from people who understand the context — the team, the constraints, the production environment, the organisational politics. The AI helps them build it faster. That’s the right division of labour. Challenge the attaboy. When an AI suggests an approach, treat it with the same scepticism you’d apply to a confident junior engineer. It might be right. It might also be pattern-matching against something that doesn’t apply to your situation. Ask “why not the simpler option?” and see what happens. Protect the argument. The messy disagreement between engineers is where good architecture comes from. If AI is short-circuiting that process — if people are deferring to Claude instead of debating with each other — you’ve lost something far more valuable than development speed. Keep humans accountable. If a human’s name isn’t on the architectural decision, nobody owns it. And if nobody owns it, nobody will fight for it when it matters. “Claude designed it” is not an architecture decision record. It’s an abdication. The craft still matters Thirty years ago, when I started in this industry, the tool was a whiteboard and a strong opinion. Today the tool is an AI agent that can produce in minutes what used to take days. The speed is genuinely remarkable. But the craft hasn’t changed. Understanding the problem. Knowing the constraints. Making trade-offs. Defending the simple solution against the exciting one. Saying “no” to the idea that sounds great but doesn’t fit. That’s architecture. No agent does it. If you’ve let Claude take the wheel, take it back. Your engineers have spent years building the judgem