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

Writing a good Claude.md

humanlayer.dev

Post reply on HN
Print view View original

261–270 of 304 posts

Re: Writing a good Claude.md

#261

Post by grayhatter »

adastra22 wrote: post #249
grayhatter wrote: post #228

Earlier quoted context omitted.

> You don’t think people are trying very hard to understand LLMs? We recognize the value of interpretability. It is just not an easy task. I think you're arguing against a tangential position to both me, and the person this directly replies to. It can be hard to use and understand something, but if you have a magic box that you can't tell if it's working. It doesn't belong anywhere near the systems that other humans…

We used the steam engine for 100 years before we had a firm understanding of why it worked. We still don’t understand how ice skating works. We don’t have a physical understanding of semi-fluid flow in grain silos, but we’ve been using them since prehistory. I could go on and on. The world around you is full of not well understood technology, as well as non deterministic processes. We know how to engineer around that…

> We used the steam engine for 100 years before we had a firm understanding of why it worked. We still don’t understand how ice skating works. We don’t have a physical understanding of semi-fluid flow in grain silos, but we’ve been using them since prehistory.

I don't think you and I are using the same definition for "firm understanding" or "how it works".

> I could go on and on. The world around you is full of not well understood technology, as well as non deterministic processes. We know how to engineer around that.

Again, you're side stepping my argument so you can restate things that are technically correct, but not really a point in of themselves. I see people who want to call themselves software engineers throw code they clearly don't understand against the wall because the AI said so. There's a significant delta between knowing you can heat water to turn it into a gas with increased pressure that you can use to mechanically turn a wheel, vs, put wet liquid in jar, light fire, get magic spinny thing. If jar doesn't call you a funny name first, that's bad!

Re: Writing a good Claude.md

#262

Post by grayhatter »

nineteen999 wrote: post #242
grayhatter wrote: post #228

Earlier quoted context omitted.

> You don’t think people are trying very hard to understand LLMs? We recognize the value of interpretability. It is just not an easy task. I think you're arguing against a tangential position to both me, and the person this directly replies to. It can be hard to use and understand something, but if you have a magic box that you can't tell if it's working. It doesn't belong anywhere near the systems that other humans…

> It doesn't belong anywhere near the systems that other humans use Really for those of us who actually work in critical systems (emergency services in my case) - of course we're not going to start patching the core applications with vibe code. But yeah, that frankenstein reporting script that half a dozen amateur hackers made a mess of over 20 years instead of refactoring and redesigning? That's prime fodder for thi…

> Really for those of us who actually work in critical systems (emergency services in my case) - of course we're not going to start patching the core applications with vibe code.

I used to believe that no one would seriously consider this too... but I don't believe that this is a safe assumption anymore. You might be the exception, but there are many more people who don't consider the implications of turning over said intellectual control.

> But yeah, that frankenstein reporting script that half a dozen amateur hackers made a mess of over 20 years instead of refactoring and redesigning? That's prime fodder for this stuff. NOBODY wants to clean that stuff up by hand.

It's horrible, no one currently understands it, so let the AI do it, so that still, no one will understand it, but at least this one bug will be harder to trigger.

I don't agree that harder to trigger bugs are better than easy to trigger bugs. And from my view, the argument that "it's currently broken now, and hard to fix!" Isn't exactly an argument I find compelling for leaving it that way.

Re: Writing a good Claude.md

#263

Post by grayhatter »

orbital-decay wrote: post #243
grayhatter wrote: post #229

Earlier quoted context omitted.

> Yes, during the Wright era aeronautics was absolutely dominated by tinkering, before the aerodynamics was figured out. It wouldn't pass the high standard of Real Engineering. Remind me: did the Wright brothers start selling tickets to individuals telling them it was completely safe? Was step 2 of their research building a large passenger plane? I originally wanted to avoid that specific flight analogy, because it f…

As a matter of fact, commercial passenger service started almost immediately as the tech was out of the fiction phase. The airship were large, highly experimental, barely controllable, hydrogen-filled death traps that were marketed as luxurious and safe. First airliners also appeared with big engines and large planes (WWI disrupted this a bit). Nothing of that was built on solid grounds. The adoption was only constra…

> As a matter of fact, commercial passenger service started almost immediately as the tech was out of the fiction phase. The airship were large, highly experimental, barely controllable, hydrogen-filled death traps that were marketed as luxurious and safe.

And here, you've stumbled onto the exact thing I'm objecting to. I think the Hindenburg disaster was a bad thing, and software engineering shouldn't repeat those mistakes.

> Very well, then Mr Tinkleberry also passes the bar because it's exactly such a trick. That it irks you as a cheap hack that lacks rigor (which it does) is another matter.

Yes, this is what I said.

> there's a critical difference between engineering research, and experimenting on unwitting people.

I object to watching developers do, exactly that.

Re: Writing a good Claude.md

#264

Post by grayhatter »

adastra22 wrote: post #251
grayhatter wrote: post #227

Earlier quoted context omitted.

I am blaming the developers who use AI because they're willing to sacrifice intellectual control in trade for something that I find has minimal value. I agree it's likely to be a complex or intractable problem. But I don't enjoy watching my industry revert down the professionalism scale. Professionals don't choose tools that they can't explain how it works. If your solution to understanding if your tool is still func…

I’m sorry you don’t like it. But this has very strong old-man-yells-at-cloud vibes. This train is moving, whether you want it to or not. Professionals use tools that work, whether they know why it works is of little consequence. It took 100 years to explain the steam engine. That didn’t stop us from making factories and railroads.

> It took 100 years to explain the steam engine. That didn’t stop us from making factories and railroads.

You keep saying this, why do you believe it so strongly? Because I don't believe this is true. Why do you?

And then, even assuming it's completely true exactly as stated; shouldn't we have higher standards than that when dealing with things that people interact with? Boiler explosions are bad right? And we should do everything we can to prove stuff works the way we want and expect? Do you think AI, as it's currently commonly used, helps do that?

Re: Writing a good Claude.md

#265

Post by scelerat »

> we recommend keeping task-specific instructions in separate markdown files with self-descriptive names somewhere in your project.

Should do this for human developers too. Can't count the number of times I've been thrown onto a project and had to spend a significant amount of time opening and skimming files just to answer simple questions that should be answered in high-level docs like this.

Re: Writing a good Claude.md

#266

Post by adastra22 »

grayhatter wrote: post #261
adastra22 wrote: post #249

Earlier quoted context omitted.

We used the steam engine for 100 years before we had a firm understanding of why it worked. We still don’t understand how ice skating works. We don’t have a physical understanding of semi-fluid flow in grain silos, but we’ve been using them since prehistory. I could go on and on. The world around you is full of not well understood technology, as well as non deterministic processes. We know how to engineer around that…

> We used the steam engine for 100 years before we had a firm understanding of why it worked. We still don’t understand how ice skating works. We don’t have a physical understanding of semi-fluid flow in grain silos, but we’ve been using them since prehistory. I don't think you and I are using the same definition for "firm understanding" or "how it works". > I could go on and on. The world around you is full of not w…

> I don't think you and I are using the same definition for "firm understanding" or "how it works".

I’m standing in firm ground here. Debate me in the details if you like.

You are constructing a strawman.

Re: Writing a good Claude.md

#267

Post by abustamam »

scelerat wrote: post #265

> we recommend keeping task-specific instructions in separate markdown files with self-descriptive names somewhere in your project. Should do this for human developers too. Can't count the number of times I've been thrown onto a project and had to spend a significant amount of time opening and skimming files just to answer simple questions that should be answered in high-level docs like this.

There's a funny joke I heard that they made Claude Code only to force developers to write better documentation.

But in all seriousness, it's working. I write cursor rules religiously and I point other devs to them. Its great.

Re: Writing a good Claude.md

#268

Post by adastra22 »

grayhatter wrote: post #264
adastra22 wrote: post #251

Earlier quoted context omitted.

I’m sorry you don’t like it. But this has very strong old-man-yells-at-cloud vibes. This train is moving, whether you want it to or not. Professionals use tools that work, whether they know why it works is of little consequence. It took 100 years to explain the steam engine. That didn’t stop us from making factories and railroads.

> It took 100 years to explain the steam engine. That didn’t stop us from making factories and railroads. You keep saying this, why do you believe it so strongly? Because I don't believe this is true. Why do you? And then, even assuming it's completely true exactly as stated; shouldn't we have higher standards than that when dealing with things that people interact with? Boiler explosions are bad right? And we should…

Because I’m trained as a physicist and (non-software) engineer and I know my field’s history? Here’s the first result that comes up on Google. Seems accurate from a quick skim: https://www.ageofinvention.xyz/p/age-of-invention-why-wasnt-...

And yes we should seek to understand new inventions. Which we are doing right now, in the form of interpretability research.

We should not be making Luddite calls to halt progress simply because our analytic capabilities haven’t caught up to our progress in engineering.

Re: Writing a good Claude.md

#269

Post by vaer-k »

> we recommend keeping task-specific instructions in separate markdown files with self-descriptive names somewhere in your project.

Why should we do this when anthropic specifically recommends creating multiple CLAUDE.md files in various directories where the information is specific and pertinent? It seems to me that anthropic has designed claude to look for claude.md for guidance, and randomly named markdown files may or may not stand out to it as it searches the directory.

You can place CLAUDE.md files in several locations:

> The root of your repo, or wherever you run claude from (the most common usage). Name it CLAUDE.md and check it into git so that you can share it across sessions and with your team (recommended), or name it CLAUDE.local.md and .gitignore it Any parent of the directory where you run claude. This is most useful for monorepos, where you might run claude from root/foo, and have CLAUDE.md files in both root/CLAUDE.md and root/foo/CLAUDE.md. Both of these will be pulled into context automatically Any child of the directory where you run claude. This is the inverse of the above, and in this case, Claude will pull in CLAUDE.md files on demand when you work with files in child directories Your home folder (~/.claude/CLAUDE.md), which applies it to all your claude sessions

https://www.anthropic.com/engineering/claude-code-best-pract...

Re: Writing a good Claude.md

#270

Post by minor3 »

scelerat wrote: post #265

> we recommend keeping task-specific instructions in separate markdown files with self-descriptive names somewhere in your project. Should do this for human developers too. Can't count the number of times I've been thrown onto a project and had to spend a significant amount of time opening and skimming files just to answer simple questions that should be answered in high-level docs like this.

Yeah I do love how many "best practices" we are only implementing because of LLMs, even though they were massively beneficial for humans prior as well.
Post reply on HN