Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • They could have done at least one pass on the UI. Can't even get simple table spacing right
  • Somehow all the with/without cookbook design examples look vibe coded on both sides to me.

    I'm not enough of a designer to be able to point exactly at what makes it so, but Claude does seem to have a somewhat limited repertoire of styles.

    Maybe if you could point more precisely at the required changes, you could discourage it?

  • So like OpenAI's Cookbook which has existed for years and no one reads?
  • Have you ever thought that just because you don't read something doesn't mean that nobody reads it?
  • I thought this is a new product to generate recipes with Claude.
    by brkn
  • I legitimately thought this was going to be a chef (the food kind) tool.
  • You can use it for that.
  • I was hoping too, because I use a Claude project for recipes and it’s great for suggestions and adapting recipes for what’s in the pantry.
  • This is definitely controversial, but I think the best CLAUDE.MD is no CLAUDE.MD at all. Every time I found myself wanting to put information into that file, I asked myself "Why isn't this already obvious from the code itself?"

    I don't need to tell the agent my tech stack, what DB access library I'm using, the way in which I write my tests, etc. Why? Because it's all very clearly spelled out within the code itself. I've gone great lengths to make sure that my fairly complex domain can be understood by a person with little domain knowledge, which means it should certainly be understood by a tool that has a wealth of it.

  • if i don't write "use podman instead of docker" it will go on journey to install docker. so there is some use for it.
  • I don't think that is controversial.

    My system CLAUDE.MD spells out my preferences in stack and architecture, and how I expect the agent to interact with me.

    I have it generate a summary doc in large repos so it doesn't need to slurp in the world to review a PR or work on a corner of it.

  • It is more like make the CLAUDE.MD file as small as possible. What is the least amount of info it needs to be more efficient for the repo. I think the best thing is to point out where important things are so Claude is not just reading random files.
  • I've found CLAUDE.md (etc.) make more sense when the agent is doing more generalized tasks rather than just coding.

    If you're just having an agent produce code, then I'd agree. I'd argue that any additional context it might need ought to be included in README.md anyways, just like a human.

    But I have projects where agents do more than just code, and retaining context about how I want the agents to operate, keeping track of gotchas, avoiding unnecessary steps in the future, etc., just ends up going into CLAUDE.md. It's not for me; it's for the agents. I also never edit this file directly. I may review it every once in a while to make sure there isn't anything weird in there, but I leave it to the agent to add what it thinks is necessary (or I'll tell it that something will be relevant in the future and that it should add it, etc.).

    Although even this pattern isn't necessarily future-proof. Seems like skills are kind of taking that role. Still, I end up with a CLAUDE.md in these kinds of scenarios to catch all the little pieces of context that don't fit nicely anywhere else.

  • I think that's something that has changed in the last 6 months. It used to be standard practice to let Claude scan everything once and describe your repo in the CLAUDE.md - the logic being you don't want to do that every time for every prompt. But now I think the tooling has gotten so good at just grepping around your repos, and maintaining memory from previous sessions, that the best practice is only use CLAUDE.md for things that aren't obvious from the code.
  • I had to create some workarounds to avoid this bug where they include a "this might not be relevant" preamble to the CLAUDE.MD file: https://github.com/anthropics/claude-code/issues/18560 - I ended up switching to Codex and it just straight up follows the AGENTS.MD instructions, it's nice to see.

    This is to say, Anthropic seems to be going down the path you are describing to make the CLAUDE.MD unnecessary. But I think that's the Claude Code harness.

  • > Because it's all very clearly spelled out within the code itself.

    You're probably burning tokens. A markdown file with a summary, structure of your project, rules, and even goals prevents Claude from hunting for and reading files over and over. Each new session (or after compact) would be starting from scratch. I take it a step further and create a HANDOFF.md file between compacting that gives the next session full context of what was done and how to continue.

    Also:

    "Treat CLAUDE.md as the place you write down what you’d otherwise re-explain. Add to it when:

    Claude makes the same mistake a second time

    A code review catches something Claude should have known about this codebase

    You type the same correction or clarification into chat that you typed last session"

    https://code.claude.com/docs/en/memory#claude-md-files

  • Does anybody here have a frontend development workflow that works well with coding agents? In my experience coding agents ship buggy, broken, incomplete, or awkward frontend features at a way higher frequency than they do for backend features. The reason seems obviously to be the difference in verifiability between the two. Basic test suites dont seem to help much. I assume something like Garry Tan’s gstack is the right direction but I dont know if that particular tool is mature enough to adopt yet. I was surprised too see here on HN recently that gemini 3.5 flash may outperform Opus/gpt-5.5 on frontend tasks (maybe because of Gemini’s supposed edge w.r.t. multimodality? or maybe it understands Chrome more deeply?), can anyone here second that take?
  • Agents aren't great at complex async state updates, mostly because it's hard to represent what's happening in their context. They're fine at creating complex components in isolation and implementing decoupled stuff like animations.
  • There may be good options coupled with agents like Claudes Front End Design skill, I haven't used it.

    I have been using Magic Patterns which is very good at generating initial prototypes, especially when driven by an agent familiar with it's facilities and constraints.

    I assume the service is just a wrapper plus scaffolding but I like it. You have to push it though to get anything particularly creative but it's good at standard front end designs.

    https://www.magicpatterns.com/

    That's not necessarily what you're after because I only use it for piloting stuff, not for adhoc feature addition and fixes.

  • I thought it would be a litteral cookbook on how to make plausible/feasible recipes with LLMs (we're not here yet sadly).
  • Same. I was hoping for a digital meal planner.
  • I've been using ChatGPT to learn how to cook, specifically Italian cuisine, and with a few bumps here and there it has been working surprisingly well.
  • I have actually cooked with LLMs, specifically Gemini, few times this year.

    Works surprisingly well, can even tell it "I have so and so ingredients in my pantry, I want a keto-friendly meal, what can I make?" followed with some narrowing down dialogue-style.

    by p_l
  • I've been cooking with the help of LLMs a few times a month for over a year now. It's worked out well 9/10 times.

    It turns out the "average" version of a recipe that's baked into the weights is usually a solid recipe, and they're really good at offering substitutions for things like "I don't have ingredient X" or "make it vegetarian".

    It's also fun promoting "make it tastier" once or twice after each recipe just to see what happens.

  • Thanks! I also like the OpenAI Cookbook: https://developers.openai.com/cookbook

    Other AI labs also tend to publish examples and cookbooks on GitHub and Hugging Face, so it's always worth keeping an eye on those as well.

  • I've been using Matt Pocock's skills at home, and they seem pretty great. He makes a great case for them vs other skills in his videos. I don't remember the exact arguments, but basically they're designed to be called by the user instead of called automatically, and that makes them take less context merely because they exist.

    I've also found that they tend to coerce the programmer into thinking about the end result, rather than try to push them out of that role. His grill skills are about making sure the actual requirements are known, and his prototype skill can help explore things that need to be experienced to make a hard decision on.

  • Gradients fixed it. They fix everything.
  • It is to a point where I prefer the non-"aesthetics" version.