Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude is not your architect. Stop letting it pretend

hollandtech.net

Post reply on HN
Print view View original

11–20 of 209 posts

Re: Claude is not your architect. Stop letting it pretend

#11

Post by allthetime »

mlinhares wrote: post #6
retrac wrote: post #2

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 Claude picked Python as the implementation language. Tokens lifted through a bunch of regex. No expression parser! Oh dear. My first assembler was li…

I keep telling people that they have to design and think about it first and then go to the tool, but they keep saying “Claude can plan too” and obviously it produces some shit that requires a lot of changes while when I get it to go I can almost always one shot the stuff I want because I am actually putting in the time to give it a detailed plan of what to do. Even just saving me the time to deal with CI is worth it.

Effective planning with LLMs isn’t prompting “design me a system” - it’s asking “how would a system to accomplish x be designed” and then engaging in dialogue and research with the LLM as an assistant and critic - running outputs through other agents for further critique and refinement - asking for justifications of decisions you are not informed enough to evaluate properly yourself. It is entirely possible to develop strong systems outside of your current skill and knowledge with methods like this. When done properly your own knowledge should have grown to meet the product you end up with.

Re: Claude is not your architect. Stop letting it pretend

#12

Post by brookst »

bad_username wrote: post #9

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…

Same here. And I find that inviting research and dissent makes it even stronger. “I’m thinking we need to model prompt assembly as a graph, with versioning for graph configs. Please do some research on best practices in this area and see if you think it makes sense for this app.”

Re: Claude is not your architect. Stop letting it pretend

#14

Post by bluegatty »

retrac wrote: post #2

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 Claude picked Python as the implementation language. Tokens lifted through a bunch of regex. No expression parser! Oh dear. My first assembler was li…

So where AI has deterministic inputs and outputs it is extremely good to the point I think that there's a theoretical issue around computational there.

Like - it can do the work for us.

It jives with post training and verifiable rewards.

The reason AI doesn't do well at 'architecture' is 1) are are bad at it and have given it a lot of mush and 2) we don't have good abstractions for it.

The result is - you stick to 'very strong conventions' and if you walk of that path you're risking a lot.

Toolchains are very deterministic, the AI can take it apart and re-assemble like Lego - and each level of the space is also deterministic. It's perfect for AI.

Re: Claude is not your architect. Stop letting it pretend

#15

Post by tempest_ »

allthetime wrote: post #11
mlinhares wrote: post #6

Earlier quoted context omitted.

I keep telling people that they have to design and think about it first and then go to the tool, but they keep saying “Claude can plan too” and obviously it produces some shit that requires a lot of changes while when I get it to go I can almost always one shot the stuff I want because I am actually putting in the time to give it a detailed plan of what to do. Even just saving me the time to deal with CI is worth it.

Effective planning with LLMs isn’t prompting “design me a system” - it’s asking “how would a system to accomplish x be designed” and then engaging in dialogue and research with the LLM as an assistant and critic - running outputs through other agents for further critique and refinement - asking for justifications of decisions you are not informed enough to evaluate properly yourself. It is entirely possible to develo…

> It is entirely possible to develop strong systems outside of your current skill and knowledge with methods like this.

If this is true how can you confidently make this assertion.

You yourself are not in a position to evaluate it, you are just running it through a couple times hoping for a "oh wait, you're right to call me out on that, that is not correct at all".

Re: Claude is not your architect. Stop letting it pretend

#17

Post by __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.

Re: Claude is not your architect. Stop letting it pretend

#18

Post by amarant »

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

Re: Claude is not your architect. Stop letting it pretend

#19

Post by 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?

Re: Claude is not your architect. Stop letting it pretend

#20

Post by spacedcowboy »

bad_username wrote: post #9

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…

It actually got quite snippy with me, when I was trying to get it to debug some issues. It kept on saying that the "burn rate" wasn't progressing and "we" should refocus our efforts somewhere else. Eventually I got something like "I have told you three times now that this is not the best approach to be taking to reduce the burn-rate and you have not taken that advice". And it stopped helping out.

So I was blunt, and said "I don't care about the burn-rate on some hypothetical chart that you produced at the start. I care about removing bugs and having a robust product, which this approach is satisfactorily doing. We will continue along this path, if the tests are not showing gain, then the tests are poorly designed".

At which point it got all apologetic, wrote new memories, and we didn't have a problem thereafter.

The issue was that I was attacking a huge bug-surface, and although each bug-fix was valid, correct, and helped move the dial, it didn't move the dial on the test-bed that Claude had created to measure its work against. There were too many inter-connected bugs for a single fix to really make a difference to these higher-level tests. I knew it was going to take a while to get through them, but apparently Claude didn't.

You try changing the size of a pointer from 2 bytes to 3 bytes on a compiler[1] for a 6502 while introducing automatically-tracked bank-switching on your memory-managed pointers, and see how many code-sites that impacts [grin].

[1]: https://atari-xt.com

Post reply on HN