There's a pattern showing up in engineering teams everywhere: a developer pastes a half-formed problem into Claude, gets back a confident, well-structured architectural proposal, and ships it. Six months later, that architecture is a liability.
A post from Holland Tech makes the argument directly: Claude is not your architect, and treating it like one is a mistake that compounds over time.
The Difference Between Code and Architecture
Code generation and architectural decisions are fundamentally different problems. Claude is genuinely impressive at the former - it can write a working authentication module, translate a function between languages, or spot a bug in your logic faster than most engineers. That part is real and useful.
Architecture is something else. It's a set of decisions about how a system should be structured given constraints that exist outside the codebase - your team's actual skill level, your budget, how fast your requirements change, what you'll need to scale in 18 months, which parts of the system are likely to be thrown away. Claude has none of that context. It has training data.
The danger isn't that Claude produces bad code. It's that Claude produces architecturally confident-sounding recommendations with no grounding in your specific situation. A confident wrong answer is worse than an uncertain one, because it skips the part where you think critically.
Where This Goes Wrong in Practice
The failure mode looks like this: you're building something new and ask Claude to recommend a database architecture. It gives you a detailed, reasonable-sounding answer - maybe microservices with separate data stores for each service. You follow it. Later you find out your team has never operated microservices in production, your data access patterns make cross-service queries painful, and you've just chosen maximum operational complexity for a team of four.
Claude didn't know any of that. It gave you an answer that fits a large class of problems, not your problem.
This also applies to technology choices, API design decisions, and anything where the right answer depends on organizational context rather than universal software principles. Claude can tell you the tradeoffs between REST and GraphQL. It can't tell you which one your team will actually maintain well.
What to Actually Use It For
None of this means stop using Claude Code or similar tools - the productivity gains on implementation work are real. The right mental model is that these tools are excellent senior contributors on well-scoped tasks:
- Implementing a design decision you've already made
- Writing tests for existing code
- Refactoring a function with a clear spec
- Explaining what unfamiliar code does
- Finding edge cases in logic you wrote
Architectural decisions - which systems to build, how to decompose a problem, what dependencies to take on - need a human who knows the context. You can use Claude to stress-test your thinking once you've formed a position. "Here's my proposed architecture; what are the failure modes?" is a much better prompt than "What architecture should I use?"
The broader point is about calibration. AI coding tools have gotten good enough that it's easy to mistake fluency for judgment. Claude can write about architectural tradeoffs with authority because it has absorbed enormous amounts of text about software engineering. That's not the same as understanding your specific product, team, and constraints. Keep that distinction clear and these tools stay useful. Blur it and you're outsourcing decisions that shouldn't be outsourced.