I think the article has the correct message, but I disagree with this:
> It’s just incapable of the thing that makes a real architect valuable: saying “no.”
From my experience Claude is excellent at saying "no". It won't say "no" if the prompt doesn't call for it (it won't say "no" to your direct request to do something, usually). But it offers good critique and happily pushes back if you make it clear that that's a first class option.
I keep hearing that claude is supposedly so agreeable. This doesn't agree with my experience. Claude will often tell me that I'm wrong, and insist on its own solution being right even when I tell it it's wrong.
Sometimes it will make a mess, but a coding agent is also very useful during the cleanup phase.
Yes, that's assuming you take time to clean up now and then. If you don't, that's on you.
I agree with the article, but I feel like this is something that anyone who uses AI aggressively for a while picks up on pretty quickly.
The thing that I find Claude incredibly good at when I'm designing architecture is working more like a research assistant on briefing decisions. It has the ability to read the entire code base and draw some conclusions. It can pull from lots of best practices and the millions of blog posts about this or that pretty effortlessly, which would take me a lot more time.
And then if asked, it can do a really good job of laying out the landscape around decisions and walking through the trade-offs. Like the author of this post, I found that if you let it, it will certainly be happy to just come up with some architecture and run with it, often in ways that will paint you quite rapidly into a corner.
But if you ask it to present you with all the trade-offs and let you make the judgment calls, it's great for that too.
That's certainly how I use it. And I think, just like anything else, working with AI is a skill, and similar to working with libraries, SaaS providers, service providers, frameworks, or anything else that's a "helper." You learn how something that could work but will fail silently is a problem, or you learn how depending on a fly-by-night SaaS company for a key framework is different than depending on a well-populated open source project, etc.
In the same way, you learn that relying on Claude's judgment is a bad idea, while relying on Claude's ability to summarize, brief, and research can be incredibly efficient.
[flagged]
For fun I've been vibe coding something I know well: toolchains. Maybe not the right thing to vibe code. But I can more or less judge the quality of the output.
When left to its own devices with the instructions "make an assembler for the architecture in ISA.md" -- well it picked Python as the implementation language. Tokens lifted through a bunch of regex. No expression parser! Oh dear. My first assembler was like that too, to be fair.
However, when I described the desired passes and their types:
etc. It was almost one-shot. About 20 minutes until I was happy. Assembles all the test programs correctly. Code is mediocre in many places. But it would have taken me weeks to implement.