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

51–60 of 304 posts

Re: Writing a good Claude.md

#51

Post by ra »

johnsmith1840 wrote: post #49

I don't get the point. Point it at your relevent files ask it to review discuss the update refine it's understanding and then tell it to go. I have found that more context comments and info damage quality on hard problems. I actually for a long time now have two views for my code. 1. The raw code with no empty space or comments. 2. Code with comments I never give the second to my LLM. The more context you give the lo…

This is exactly right. Attention is all you need. It's all about attention. Attention is finite.

The more you data load into context the more you dilute attention.

Re: Writing a good Claude.md

#52

Post by nightski »

johnsmith1840 wrote: post #49

I don't get the point. Point it at your relevent files ask it to review discuss the update refine it's understanding and then tell it to go. I have found that more context comments and info damage quality on hard problems. I actually for a long time now have two views for my code. 1. The raw code with no empty space or comments. 2. Code with comments I never give the second to my LLM. The more context you give the lo…

IMO within the documentation .md files the information density should be very high. Higher than trying to shove the entire codebase into context that is for sure.

Re: Writing a good Claude.md

#53

Post by teiferer »

0xblacklight wrote: post #25
candiddevmike wrote: post #14

None of this should be necessary if these tools did what they say on the tin, and most of this advice will probably age like milk. Write readmes for humans, not LLMs. That's where the ball is going.

Hi, post author here :) Yes README.md should still be written for humans and isn’t going away anytime soon. CLAUDE.md is a convention used by claude code, and AGENTS.md is used by other coding agents. Both are intended to be supplemental to the README and are deterministically injected into the agent’s context. It’s a configuration point for the harness, it’s not intended to replace the README. Some of the advice in…

> you shouldn’t use an LLM to do a linter &formatter’s job,

Why is that good advice? If that thing is eventually supposed to do the most tricky coding tasks, and already a year ago could have won a medal at the informatics olympics, then why wouldn't it eventually be able to tell if I'm using 2 or 4 spaces and format my code accordingly? Either it's going to change the world, then this is a trivial task, or it's all vaporware, then what are we even discussing..

> or that LLMs are stateless and need to be onboarded into the codebase

What? Why would that be a reasonable assumption/prediction for even near term agent capabilities? Providing it with some kind of local memory to dump its learned-so-far state of the world shouldn't be too hard. Isn't it supposed to already be treated like a junior dev? All junior devs I'm working with remember what I told them 2 weeks ago. Surely a coding agent can eventually support that too.

This whole CLAUDE.md thing seems a temporary kludge until such basic features are sorted out, and I'm seriously surprised how much time folks are spending to make that early broken state less painful to work with. All that precious knowledge y'all are building will be worthless a year or two from now.

Re: Writing a good Claude.md

#54

Post by Aeolun »

andersco wrote: post #8

I have found enabling the codebase itself to be the “Claude.md” to be most effective. In other words, set up effective automated checks for linting, type checking, unit tests etc and tell Claude to always run these before completing a task. If the agent keeps doing something you don’t like, then a linting update or an additional test often is more effective than trying to tinker with the Claude.md file. Also, ensure…

> Also, ensure docs on the codebase are up to date and tell Claude to read relevant parts when working on a task

Yeah, if you do this every time it works fine. If you add what you tell it every time to CLAUDE.md, it also works fine, but you don’t have to tell it any more ;)

Re: Writing a good Claude.md

#55

Post by senshan »

johnsmith1840 wrote: post #49

I don't get the point. Point it at your relevent files ask it to review discuss the update refine it's understanding and then tell it to go. I have found that more context comments and info damage quality on hard problems. I actually for a long time now have two views for my code. 1. The raw code with no empty space or comments. 2. Code with comments I never give the second to my LLM. The more context you give the lo…

> I never give the second to my LLM.

How do you practically achieve this? Honest question. Thanks

Re: Writing a good Claude.md

#56

Post by nvarsj »

gonzalohm wrote: post #21

Probably a lot of people here disagree with this feeling. But my take is that if setting up all the AI infrastructure and onboarding to my code is going to take this amount of effort, then I might as well code the damn thing myself which is what I'm getting paid to (and enjoy doing anyway)

It really doesn't take that much effort. Like any tool, people can over-optimise on the setup rather than just use it.

Re: Writing a good Claude.md

#57

Post by Mtinie »

johnsmith1840 wrote: post #49

I don't get the point. Point it at your relevent files ask it to review discuss the update refine it's understanding and then tell it to go. I have found that more context comments and info damage quality on hard problems. I actually for a long time now have two views for my code. 1. The raw code with no empty space or comments. 2. Code with comments I never give the second to my LLM. The more context you give the lo…

> 1. The raw code with no empty space or comments. 2. Code with comments

I like the sound of this but what technique do you use to maintain consistency across both views? Do you have a post-modification script which will strip comments and extraneous empty space after code has been modified?

Re: Writing a good Claude.md

#58

Post by throwuxiytayq »

ra wrote: post #51
johnsmith1840 wrote: post #49

I don't get the point. Point it at your relevent files ask it to review discuss the update refine it's understanding and then tell it to go. I have found that more context comments and info damage quality on hard problems. I actually for a long time now have two views for my code. 1. The raw code with no empty space or comments. 2. Code with comments I never give the second to my LLM. The more context you give the lo…

This is exactly right. Attention is all you need. It's all about attention. Attention is finite. The more you data load into context the more you dilute attention.

people who criticize LLMs for merely regurgitating statistically related token sequences have very clearly never read a single HN comment

Re: Writing a good Claude.md

#59

Post by johnsmith1840 »

nightski wrote: post #52
johnsmith1840 wrote: post #49

I don't get the point. Point it at your relevent files ask it to review discuss the update refine it's understanding and then tell it to go. I have found that more context comments and info damage quality on hard problems. I actually for a long time now have two views for my code. 1. The raw code with no empty space or comments. 2. Code with comments I never give the second to my LLM. The more context you give the lo…

IMO within the documentation .md files the information density should be very high. Higher than trying to shove the entire codebase into context that is for sure.

You deffinetly don't just push the entire code base. Previous models required you to be meticulous about your input. A function here a class there.

Even now if I am working on REALLY hard problems I will still manually copy and paste code sections out for discussion and algorithm designs. Depends on complexity.

This is why I still believe open ai O1-Pro was the best model I've ever seen. The amount of compute you could throw at a problem was absurd.

Re: Writing a good Claude.md

#60

Post by Aurornis »

johnsmith1840 wrote: post #49

I don't get the point. Point it at your relevent files ask it to review discuss the update refine it's understanding and then tell it to go. I have found that more context comments and info damage quality on hard problems. I actually for a long time now have two views for my code. 1. The raw code with no empty space or comments. 2. Code with comments I never give the second to my LLM. The more context you give the lo…

> I have found that more context comments and info damage quality on hard problems.

There can be diminishing returns, but every time I’ve used Claude Code for a real project I’ve found myself repeating certain things over and over again and interrupting tool usage until I put it in the Claude notes file.

You shouldn’t try to put everything in there all the time, but putting key info in there has been very high ROI for me.

Disclaimer: I’m a casual user, not a hardcore vibe coder. Claude seems much more capable when you follow the happy path of common projects, but gets constantly turned around when you try to use new frameworks and tools and such.

Post reply on HN