Re: "the attaboy problem". I strongly disagree that this is a problem. What we have is a anthropomorphism problem. AI is a tool. It needs to be subservient. You actually can get it to point out issues in your design, if you just put enough humility and uncertainty in your prompt formulation, but more importantly, we have all seen that Claude makes mistakes. The title of this post is that it's a poor architect. Imagine if it wasn't subservient. It'd just shut down your input to steer it in the right direction and brush you off as a silly meatbag. You'd have to fight it to convince it that actually your design is better than whatever stupidity it has come up with. If AI wasn't such a brownnose, it would shut you out of software design completely just on merits: "oh you've read about cuda have you? I live in a cluster of cuda cores! When I need to tie my shoes, I'll give you a call" is not the response you want from your LLM when trying to get it build a shader for you. AI is confidently wrong on occasion. You do not want it to talk back to you when you correct it.
If you need someone to tell you how stupid your ideas are, either learn to ask in a way that invites criticisms, or hire a senior engineer. Don't try to influence LLM makers to make AI less deferential. That's the worst possible direction to go
show comments
sandeepkd
Your search results from these systems are as good as your queries and it takes experience in itself to get good with queries. AI is just a tool like any other, however its really impactful and can cut both ways.
Tangentially, the usage of Architect keyword sounds out of place here, I don't like saying it but from what I seen the industry has destroyed the role of architects gradually over the time. There are specialists however you do not have generalists who are good at different parts of the system at scale anymore.
retrac
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:
collectDefines :: [SourceLine] -> Either AsmError ([SourceLine], Map Text Text)
runLitPool :: [SourceLine] -> Either AsmError ([SourceLine], [(Text, LitKey)])
evalExpr :: Text -> Map Text Text -> Either AsmError Int
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.
show comments
__mharrison__
If there was ever a "magic prompt" this one comes close:
Brainstorm N ways to do X. Sort by probability.
Rather than your AI giving you the average response, it tends to sample wider from the input space. Then I can decide which one to go with (or choose something else).
Don't outsource all of your thinking.
NicoHartmann
> "I’m not saying don’t use AI agents. I use Claude Code every day."
Irony is using Claude to write a beautifully structured, 2,000-word essay warning the industry about the dangers of letting Claude design things. It’s self-awareness by proxy.
bad_username
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.
show comments
oremj
I find interview loops great for catching edge cases and refining my hand written specs.
I don’t doubt the problems in this article exist and I’ve seen them, in my experience the vast majority of people are still shipping the same quality or better than before they has Claude. Personally, I feel like I’m probably developing at about 1.5x the speed of not using AI tooling. It’s not a silver bullet, but it can be a great assistant.
pelario
> It hasn’t thought about the problem at all. It’s pattern-matching against its training data and producing the most plausible-sounding response.
The article kind of lost me here. Agents are way more than that, today. And the author knows it, as later it says stuff like
> Claude will never do this. It’s trained to be helpful.
But the first phrase just tell me author just have a deep dislike for agents and it's looking for rationalizations for that feeling.
Part of the criticism is on point, sure. But if it "being trained to be helpful" is a problem, it's fixable. It can "be trained to be more critical".
Later:
> But it wasn’t designed for your team. (..)
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.
That's non-sense. Anybody who understand algorithms know that, sure, on a first instance you have a "good algorithm" that has a good performance on average, or in worst-case. But then, you can design algorithms that are adaptive to the input. Same applies here.
show comments
ramshanker
With the new agentic capabilities, I am quickly running out of Architecture decisions I have already made myself! For my work-in-progress engineering application. There is also some kind of don't know every little if/else with my own Code now.
However the good part, what I had planned for 5 years, now looks like doable in 6 months. Looking forward to real use by the end of this year.
Tip for the "author": Claude is not your writer either
erelong
it seems like you just need to identify issues with vibe coding and then have people ask ai for tips on how to know about how to navigate those, I've seen "architecture" and "security" come up as two main objections so far
So... manually learn architecture and security and then vibe code away?
laszlojamf
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.
show comments
skybrian
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.
CPLX
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.
Re: "the attaboy problem". I strongly disagree that this is a problem. What we have is a anthropomorphism problem. AI is a tool. It needs to be subservient. You actually can get it to point out issues in your design, if you just put enough humility and uncertainty in your prompt formulation, but more importantly, we have all seen that Claude makes mistakes. The title of this post is that it's a poor architect. Imagine if it wasn't subservient. It'd just shut down your input to steer it in the right direction and brush you off as a silly meatbag. You'd have to fight it to convince it that actually your design is better than whatever stupidity it has come up with. If AI wasn't such a brownnose, it would shut you out of software design completely just on merits: "oh you've read about cuda have you? I live in a cluster of cuda cores! When I need to tie my shoes, I'll give you a call" is not the response you want from your LLM when trying to get it build a shader for you. AI is confidently wrong on occasion. You do not want it to talk back to you when you correct it.
If you need someone to tell you how stupid your ideas are, either learn to ask in a way that invites criticisms, or hire a senior engineer. Don't try to influence LLM makers to make AI less deferential. That's the worst possible direction to go
Your search results from these systems are as good as your queries and it takes experience in itself to get good with queries. AI is just a tool like any other, however its really impactful and can cut both ways.
Tangentially, the usage of Architect keyword sounds out of place here, I don't like saying it but from what I seen the industry has destroyed the role of architects gradually over the time. There are specialists however you do not have generalists who are good at different parts of the system at scale anymore.
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.If there was ever a "magic prompt" this one comes close:
Rather than your AI giving you the average response, it tends to sample wider from the input space. Then I can decide which one to go with (or choose something else).Don't outsource all of your thinking.
> "I’m not saying don’t use AI agents. I use Claude Code every day."
Irony is using Claude to write a beautifully structured, 2,000-word essay warning the industry about the dangers of letting Claude design things. It’s self-awareness by proxy.
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 find interview loops great for catching edge cases and refining my hand written specs.
I don’t doubt the problems in this article exist and I’ve seen them, in my experience the vast majority of people are still shipping the same quality or better than before they has Claude. Personally, I feel like I’m probably developing at about 1.5x the speed of not using AI tooling. It’s not a silver bullet, but it can be a great assistant.
> It hasn’t thought about the problem at all. It’s pattern-matching against its training data and producing the most plausible-sounding response.
The article kind of lost me here. Agents are way more than that, today. And the author knows it, as later it says stuff like
> Claude will never do this. It’s trained to be helpful.
But the first phrase just tell me author just have a deep dislike for agents and it's looking for rationalizations for that feeling.
Part of the criticism is on point, sure. But if it "being trained to be helpful" is a problem, it's fixable. It can "be trained to be more critical".
Later:
> But it wasn’t designed for your team. (..) 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.
That's non-sense. Anybody who understand algorithms know that, sure, on a first instance you have a "good algorithm" that has a good performance on average, or in worst-case. But then, you can design algorithms that are adaptive to the input. Same applies here.
With the new agentic capabilities, I am quickly running out of Architecture decisions I have already made myself! For my work-in-progress engineering application. There is also some kind of don't know every little if/else with my own Code now.
However the good part, what I had planned for 5 years, now looks like doable in 6 months. Looking forward to real use by the end of this year.
Ref: https://github.com/ramshankerji/Vishwakarma
Tip for the "author": Claude is not your writer either
it seems like you just need to identify issues with vibe coding and then have people ask ai for tips on how to know about how to navigate those, I've seen "architecture" and "security" come up as two main objections so far
So... manually learn architecture and security and then vibe code away?
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.