Comment by _pdp_

Comment by _pdp_ 3 days ago

24 replies

There is far much easier way to do this and one that is perfectly aligned with how these tools work.

It is called documenting your code!

Just write what this file is supposed to do in a clear concise way. It acts as a prompt, it provides much needed context specific to the file and it is used only when necessary.

Another tip is to add README.md files where possible and where it helps. What is this folder for? Nobody knows! Write a README.md file. It is not a rocket science.

What people often forget about LLMs is that they are largely trained on public information which means that nothing new needs to be invented.

You don't have to "prompt it just the right way".

What you have to do is to use the same old good best practices.

dhorthy 3 days ago

For the record I do think the AI community tries to unnecessarily reinvent the wheel on crap all the time.

sure, readme.md is a great place to put content. But there's things I'd put in a readme that I'd never put in a claude.md if we want to squeeze the most out of these models.

Further, claude/agents.md have special quality-of-life mechanics with the coding agent harnesses like e.g. `injecting this file into the context window whenever an agent touches this directory, no matter whether the model wants to read it or not`

> What people often forget about LLMs is that they are largely trained on public information which means that nothing new needs to be invented.

I don't think this is relevant at all - when you're working with coding agents, the more you can finesse and manage every token that goes into your model and how its presented, the better results you can get. And the public data that goes into the models is near useless if you're working in a complex codebase, compared to the results you can get if you invest time into how context is collected and presented to your agent.

  • theshrike79 2 days ago

    > For the record I do think the AI community tries to unnecessarily reinvent the wheel on crap all the time.

    On Reddit's LLM subreddits people are rediscovering the very basics of software project management as some massive insights daily or very least weekly.

    Who would've guessed that proper planning, accessible and up to documentation and splitting tasks into manageable testable chunks produces good code? Amazing!

    Then they write a massive blog post or even some MCP mostrosity for it and post it everywhere as a new discovery =)

    • dkubb 2 days ago

      I can totally understand where you are coming from with this comment. It does feel a bit frustrating that people are rediscovering things that were written in books 30/40/50 years ago.

      However, I think this is awesome for the industry. People are rediscovering basic things, but if they didn't know about the existing literature this is a perfect opportunity to refer them to it. And if they were aware, but maybe not practicing it, this is a great time for the ideas to be reinforced.

      A lot of people, myself included, never really understand which practices are important or not until we were forced to work on a system that was most definitely not written with any good practices in mind.

      My current view of agentic coding is that it's forcing an entire generation of devs to learn software project management or drowning under the mountain of debt an LLM can produce. Previously it took much longer to feel the weight of bad decisions in a project but an LLM allows you to speed-run this process in a few weeks or months.

johnfn 3 days ago

So how exactly does one "write what this file is supposed to do in a clear concise way" in a way that is quickly comprehensible to AI? The gist of the article is that when your audience changes from "human" to "AI" the manner in which you write documentation changes. The article is fairly high quality, and presents excellent evidence that simply "documenting your code" won't get you as far as the guidelines it provides.

Your comment comes off as if you're dispensing common-sense advice, but I don't think it actually applies here.

datacynic 2 days ago

Writing documentation for LLMs is strangely pleasing because you have very linear returns for every bit of effort you spend on improving its quality and the feedback loop is very tight. When writing for humans, especially internal documentation, I’ve found that these returns are quickly diminishing or even negative as it’s difficult to know if people even read it or if they didn’t understand it or if it was incomplete.

bastawhiz 3 days ago

This is missing the point. If I want to instruct Claude to never write a database query that doesn't hit a preexisting index, where exactly am I supposed to document that? You can either choose:

1. A centralized location, like a README (congrats, you've just invented CLAUDE.md)

2. You add a docs folder (congrats, you've just done exactly what the author suggests under Progressive Disclosure)

Moreover, you can't just do it all in a README, for the exact reasons that the author lays out under "CLAUDE.md file length & applicability".

CLAUDE.md simply isn't about telling Claude what all the parts of your code are and how they work. You're right, that's what documenting your code is for. But even if you have READMEs everywhere, Claude has no idea where to put code when it starts a new task. If it has to read all your documentation every time it starts a new task, you're needlessly burning tokens. The whole point is to give Claude important information up front so it doesn't have to read all your docs and fill up its context window searching for the right information on every task.

Think of it this way: incredibly well documented code has everything a new engineer needs to get started on a task, yes. But this engineer has amnesia and forgets everything it's learned after every task. Do you want them to have to reonboard from scratch every time? No! You structure your docs in a way so they don't have to start from scratch every time. This is an accommodation: humans don't need this, for the most part, because we don't reonboard to the same codebase over and over. And so yes, you do need to go above and beyond the "same old good best practices".

  • callc 2 days ago

    This CLAUDE.md dance feels like herding cats. Except we’re herding a really good autocorrect encyclopedic parrot. Sans intelligence

    Relating / personifying LLM to an engineer doesn’t work out

    Maybe the best though model currently is just “good way to automate trivial text modifications” and “encyclopedic ramblings”

    • saturatedfat 2 days ago

      unfair characterization.

      think about how this thing is interacting with your codebase. it can read one file at a time. sections of files.

      in this UX, is it ergonomic to go hunting for patterns and conventions? if u have to linearly process every single thing u look at every time you do something, how are you supposed to have “peripheral vision”? if you have amnesia, how do you continue to do good work in a codebase given you’re a skilled engineer?

      it is different from you. that is OK. it doesn’t mean its stupid. it means it needs different accomodations to perform as well as you do. accomodations IRL exist for a reason, different people work differently and have different strengths and weaknesses. just like humans, you get the most out of them if you meet and work with them from where they’re at.

  • _pdp_ 3 days ago

    You put a warning where it is most likely to be seen by a human coder.

    Besides, no amount of prompting will prevent this situation.

    If it is a concern then you put a linter or unit tests to prevent it altogether, or make a wrapper around the tricky function with some warning in its doc strings.

    I don't see how this is any different from how you typically approach making your code more resilient to accidental mistakes.

    • mvkel 3 days ago

      Documenting for AI exactly like you would document for a human is ignoring how these tools work

      • anonzzzies 3 days ago

        But they are right, claude routinely ignores stuff from CLAUDE.md, even with warning bells etc. You need a linter preventing things. Like drizzle sql` templates: it just loves them.

      • CuriouslyC 3 days ago

        You can make affordances for agent abilities without deviating from what humans find to be good documentation. Use hyperlinks, organize information, document in layers, use examples, be concise. It's not either/or unless you're being lazy.

      • notachatbot123 2 days ago

        Sounds like we should call them tools, not AI!

        • theshrike79 2 days ago

          Agentic AI is LLMs using tools in a loop to achieve a goal.

          Needs a better term than "AI", I agree, but it's 99% marketing the tech will stay the same.

    • bastawhiz 3 days ago

      > no amount of prompting will prevent this situation.

      Again, missing the point. If you don't prompt for it and you document it in a place where the tool won't look first, the tool simply won't do it. "No amount of promoting" couldn't be more wrong, it works for me and all my coworkers.

      > If it is a concern then you put a linter or unit tests to prevent it altogether

      Sure, and then it'll always do things it's own way, run the tests, and have to correct itself. Needlessly burning tokens. But if you want to pay for it to waste its time and yours, go for it.

      > I don't see how this is any different from how you typically approach making your code more resilient to accidental mistakes.

      It's not about avoiding mistakes! It's about having it follow the norms of your codebase.

      - My codebase at work is slowly transitioning from Mocha to Jest. I can't write a linter to ban new mocha tests, and it would be a pain to keep a list of legacy mocha test suites. The solution is to simply have a bullet point in the CLAUDE.md file that says "don't write new Mocha test suites, only write new test suites in Jest". A more robust solution isn't necessary and doesn't avoid mistakes, it avoids the extra step of telling the LLM to rewrite the tests.

      - We have a bunch of terraform modules for convenience when defining new S3 buckets. No amount of documenting the modules will have Claude magically know they exist. You tell it that there are convenience modules and to consider using them.

      - Our ORM has findOne that returns one record or null. We have a convenience function getOne that returns a record or throws a NotFoundError to return a 404 error. There's no way to exhaustively detect with a linter that you used findOne and checked the result for null and threw a NotFoundError. And the hassle of maybe catching some instances isn't necessary, because avoiding it is just one line in CLAUDE.md.

      It's really not that hard.

      • girvo 3 days ago

        > There's no way to exhaustively detect with a linter that you used findOne and checked the result for null and threw a NotFoundError

        Yes there is? Though this is usually better served with a type checker, it’s still totally feasible with a linter too if that’s your bag

        > because avoiding it is just one line in CLAUDE.md.

        Except no, it isn’t, because these tools still ignore that line sometimes so I still have to check for it myself.

        • bastawhiz 2 days ago

          > Yes there is? Though this is usually better served with a type checker, it’s still totally feasible with a linter too if that’s your bag

          It's not, because you would have to implement a full static analyzer that traces where the result of a `findOne` call is checked for `null` and then check that the condition always leads to a `NotFoundError`. At best you've got a linter that only works some of the time, at worst you've just made your linter terribly slow and buggy.

          > these tools still ignore that line sometimes so I still have to check for it myself.

          this is _literally_ the point of the article

  • theshrike79 2 days ago

    1. Create a tool that can check if a query hits a prexisting index

    In step 2 either force Claude to use it (hooks) or suggest it (CLAUDE.md)

    3. Profit!

    As for "where stuff is", for anything more complex I have a tree-style graph in CLAUDE.md that shows the rough categories of where stuff is. Like the handler for letterboxd is in cmd/handlerletterboxd/ and internal modules are in internal/

    Now it doesn't need to go in blind but can narrow down searches when I tell it to "add director and writer to the letterboxd handler output".

  • gitgud 3 days ago

    > 1. A centralized location, like a README (congrats, you've just invented CLAUDE.md)

    README files are not a new concept, and have been used in software for like 5 decades now, whereas CLAUDE.md files were invented 12 months ago...

    • bastawhiz 2 days ago

      You can also use your README (and in my own private project, I do!). But for folks who don't want their README clogged up with lots of facts about the project, you have CLAUDE.md

  • victorbuilds 2 days ago

    Learned this the hard way. Asked Claude Code to run a database migration. It deleted my production database instead, then immediately apologised and started panicking trying to restore it.

    Thankfully Azure keeps deleted SQL databases recoverable, so I got it back in under an hour. But yeah - no amount of CLAUDE.md instructions would have prevented that. It no longer gets prod credentials.

avereveard 2 days ago

Well, no. You run pretty fast into context limit (or attention limit for long context models) And the model understand pretty well what code does without documentation.

Theres also a question of processes. How to format code what style of catching to use and how to run the tests, which human keep on the bacl of their head after reading it once or twice but need a constant reminder for llm whose knowledge lifespan is session limited

  • uncletaco 2 days ago

    I’m pretty sure Claude would not work well in my code base if I hadn’t meticulously added docstrings, type hints, and module level documentation. Even if you’re stubbing out code for later implementation, it helps to go ahead and document it so that a code assistant will get a hint of what to do next.

0xblacklight 3 days ago

I think you’re missing that CLAUDE.md is deterministically injected into the model’s context window

This means that instead of behaving like a file the LLM reads, it effectively lets you customize the model’s prompt

I also didn’t write that you have to “prompt it just the right way”, I think you’re missing the point entirely