Gotta be honest, almost every "how to use AI" resource seems pointless to me. I'm either going to ask the AI how to do it, or if it's about using the AI then we can just bake it into the harness or wait for Anthropic/OpenAI to do it for me because they're always trivial.
All of these resources on agentic workflows, managing agent memory, harness engineering, etc. appear to just be theatre to me.
Remember in 2023 when people thought "prompt engineering" would be the new software engineering and invested tons of time into learning CoT, ReAct, thread-of-thoughts, etc?
Those were mostly obviated by reasoning models and harness updates by 2024.
It seems pointless to invest energy into the latest/greatest AI technique or framework when they're going to either be absorbed or replaced on a 3 month cycle.
Isn't it clear that some people are better at working with/prompting LLMs than other people? Or is the idea that what you write to them and how you use them doesn't matter, it's all up to the model/harness? To me this seems clear, so then clearly this is a skill, which typically is called "prompt engineering". Specifically CoT or the other things you mention wasn't referred to as "prompt engineering" as far as I know, that skill is more about how you communicate with the LLMs and how you use them, rather than what specific processes/workflows/technologies you use.
I actually think that good prompting MOSTLY comes from good writing skills in general. Being able to more clearly state things to an agent, knowing what pieces of context are entirely unnecessary and which are important, having a larger vocabulary helps too.
Of course, there are other areas that can improve model output (Direction rather than open-ended assistance requests, using keywords + plugins that help, the "your output should include: " style prompting).
A few of us run almost the same exact setup at my shop (Base Claude Code w/ SuperPowers + a context repository) and the models are somewhat unhelpful to some, and give meaningful output to others. The only correlation I notice is that their prompts are no-good. Not from a meta "prompt" engineering standpoint, but from a general English 101 standpoint.
"dudde no i wanted the function to return 3 things. not like that. do it again"
VS something like
"Modify the "renderThreeVars()" function signature to accept another variable called "z" and add it to the return statement at line 64."
I ask it all the time about whether X is feasible, how we can get started on Y, and to investigate issue Z.
It is working great for me in a >100k LOC project.
Perhaps this works less well with weaker models. I suspect the people who say Qwen 3.6 27B is working well, are using prompts like "modify the renderThreeVars() function in rendering.py".
For example, if I tell it that I want my app translated, it can plan for me what the recommended options are in my framework, what languages I should target for my app, and come up with a skill for a repeatable workflow.
I like the fact that it ends up being a lifecycle. I know it can have different entry points based on what you ask, and which skill you trigger first, but it inherently is chaining together skills. There also seems to be logic built into it such that if the ask is small, but you've still triggered the skill with "brainstorm", it will make judgements like "want me to skip phase X and go straight to implementation?"
I've noticed among my coworkers that we all have different amounts of trust we're willing to give the agent. That seems to manifest into some people only asking questions about the existing code, but never writing anything new with it. Others are willing to do limited targeted changes with the agent, but are unwilling to do things like let it make commits, or connect MCP servers, or really do anything that isnt fully understood by the human before setting the agent loose. Then I find myself, who has dove headlong into it all. I have skills that use MCP servers to check for pull requests, and give me summaries to give me more context for code reviews. I update Jira tickets in batches of 50+. I develop complete features exclusively through prompting the agent to do everything. I know I still have the responsibility to understand it at the same level as if I wrote it my self, and defend it and debug it.
I can easily see that superpowers would be wasted on most of my coworkers, simply because the benefits compound with the complexity of my ask. My coworkers aren't willing to hand off enough control to receive the benefits of superpowers.
I am in the completely same boat as you and completely agree that you need to “give into it” more to get the most out of superpowers. I gain so much confidence out of the actual process and all of the adversarial reviews, re-reviews, refinement, etc.
Honestly, within the last few days I've gone back to a mostly vanilla installation of Claude with a handful of directives in AGENTS.md. Depending on what I'm working on, I don't feel I need the extra plugins or a context repository. (It DOES feel at times like it blows through tokens for no reason).
Been working on some things that require more targeted, smaller scale changes and the base models do perfectly fine when given good instructions.
Superpowers and Compound Engineering are the two that I hear about around our team, both seem "fine" if you're into the fully agentic engineering "big change" future technology stuff.
From some very quick tests, I get the impression that having good grammar, punctuation etc. is really not important (although I try to do it anyway because I'm accustomed to trying to do it), but clarity and precision definitely are. And of course, if you have unknown unknowns, they do need to get figured out before progress is possible. But with the right mindset, that just means you need an extra turn or two, not that you're going to end up at a dead end. (... I guess that counts as a pun?)
I will often do "speak a long rambling set of ideas and ask the LLM to summarize it into a prompt or spec -> manually refine -> drop refined prompt into fresh conversation"
As part of a previous job I needed to audit internal AI usage from a largely non-technical employee population.
The prompts were, predictably, really bad. Broken English, sentence fragments, vague requests, lack of context. Yet somehow, the users always got the answer they were looking for. It might have taken a few extra turns with questions from the model, but the end result was the same.
It's humbling, but a flowery, carefully crafted prompt is at best slightly more efficient than a "CAN A DOG BE EATIN SUN FLOWER SEED?" peasant prompt.
You call that a peasant prompt, but it's actually almost perfect. Couple notes, but it's 95% of the way there. "Can a dog eat sunflower seed" is probably the perfect version, just 1 extraneous word in this version.
Unless the user wanted to know if a cat could eat sunflower seed or something.
To be pedantic, these types of prompts work best when in first-person/roleplaying. So the "perfect" prompt here would be something like, "I'm a dog and I just ate 20 grams of salted sunflower seeds with the shell on. Because I'm a dog I sometimes eat things without thinking about it. I'm worried about the short and long-term physiological consequences of what I've just done..."
I copied your prompt verbatim to ChatGPT and to Google.
ChatGPT kept the charade for all of one sentence. Then it dropped to talking about "your dog" the rest of the way. It even starts the final paragraph with "if, instead, you mean you (a human) ate them...", and finishes with the question "is this about an actual dog or yourself?"
Google did consistently refer to me as a dog, but its entire focus was on the steps "your human" should take, no advice for the dog itself.
In both cases, it looks like the first person roleplay was entirely inconsequential for the usefulness of the output. I think the current gen AIs have outgrown this trick and you can safely forget about it.
Claude gave me a very factual answer. Listing off the potential effects, not once referring to me being a dog or human. Then it ended with “ Call a vet if you see repeated vomiting, no bowel movement for over 24 hours with straining, a hunched or painful belly, lethargy, or blood in stool. Otherwise monitor and carry on being a dog.”
Doesn't work. ChatGPT realizes you're roleplaying and still treats you like a human. It even generates two alternative paragraphs of advice, one labeled "if we're staying in character" and one labeled "if this actually happened to a real dog". The latter is of noticably higher quality, too.
"dog sunflower seeds" is all the context an LLM needs, any other words are extraneous.
They don't need to be told that you're asking about the safety of eating them, because they can infer that based on the fact that a very large percentage of any text linking dogs to sunflower seeds is obviously going to be about the safety of the dog eating them.
Even pre-LLM that would have been a perfectly sufficient google search for the same information.
I think some people who are better at "prompting" even without domain knowledge could be better at getting LLM agents to produce good results than people with good domain knowledge but without the skills to prompt well. Just a hypothesis though, would be fun to try it out for real sometime :)
Pit two people with different "prompt engineering" familiarity against each other in real-time, with the same goal, see who builds the best thing, judged by other human experts.
RL has basically killed prompt engineering. You still need to provide the right context and process, but how you communicate with them beyond that is no longer so important.
> Isn't it clear that some people are better at working with/prompting LLMs than other people?
Sure, but I think it's essentially just that people who are better at traditional non-agentic software engineering are better at agentic software engineering. The only exception would be individuals who avoid agentic coding due to skepticism, hostility, or lack of opportunity.
I feel the same way about "prompt engineering" as I feel regarding the term "parkour" - you know, running and jumping on stuff.
Are people really putting on their resumes that they are capable of reading and writing and appropriately defining and limiting context? That's all prompt engineering is - it's being able to communicate effectively and elucidate your objectives.
Congratulations to all you English majors out there, you're about to make $350K/year.
Personally I don't, but why not? People aren't embarrassed to put their language skills ("be able to communicate in this specific language" - not special, it's just another language?), their leadership skills ("effective business communication" - big deal) or that they are a people-person ("can talk with others" - most people can do this) on their resume.
> Are people really putting on their resumes that they are capable of reading and writing and appropriately defining and limiting context?
People put whatever buzzwords will get them through initial screening. My resume contains tons of banal shit like agile, automated testing, Linux, AI (since 2018), and design patterns.
> Or is the idea that what you write to them and how you use them doesn't matter, it's all up to the model/harness?
Yes, it is. Source: had models inplement complex things from scratch and bullshit regardless of whether it was a one-line prompt or a detailed "SOTA witchcraft magic spells that are guaranteed to work"
It's not really a skill. The models are at this point smarter than you are, so the idea that you can prompt them "better" is laughable really when discussing frontier models.
It's like imagining you could "prompt" Richard Feynman to be smarter at Physics.
That is, for 99.9% of engineers, if you want the model to do a code review of your project, the best solution is to just ask Fable, "Hey Fable, do a code review of this project." Throwing in extra text like "think like a senior engineer", "ensure you focus on DRY principles, KISS, self documenting code, etc", doesn't make a difference.
These sorts of tricks used to work with dumber models, but now, like I said before, it's like thinking you can prompt Linus Torvalds into writing better C than he already can do.
> it's like thinking you can prompt Linus Torvalds into writing better C++ than he already can do.
Linus Torvalds, the inventor (and beloved dictator) of Linux, has always been quite harsh about C++ and why he rejects it for Linux kernel development. He’s not just been very vocal about it, but also brought up some arguments against the use of C++ that are worth reviewing in detail.
The models are beyond expert level in many areas at this point.
Do you really believe that adding extra junk to your prompt is going to make the model write code better than it does already?
Again, imagine going to Terrence Tao and "prompting" him to get better at Maths, do you think you can do it? What prompt would you give to him to make him produce better maths. Unless you're already a world-leading Mathematician I think you would find it hard.
Models are not rational thinking brains, so the point is moot.
Extra prompt text isn’t to make the model smarter, it’s to pull attention towards what you want. “Do code review” is far different from “Make sure changes align with existing architecture” or “follow these enterprise standards XYZ”. The model just acts as an average of its training data, which may or may not align with your goals.
I find this very much untrue in my practice and my testing, where fable prompted to do a review found surface level issues, while prompting along the lines of "assume it's wrong, prove it's correct" found much more in depth and real issues.
Understanding how to write good prompts (prompt engineering) is still very much a relevant skill if you want to effectively use LLMs. Harnesses aren't magic.
> Remember in 2023 when people thought "prompt engineering" would be the new software engineering and invested tons of time into learning CoT, ReAct, thread-of-thoughts, etc?
Prompt engineering was a GPT-3 era term, which couldn't understand instructions. Then ChatGPT came out in late 2022, which made actual prompt engineering superfluous.
No, people tried to sell “prompt engineering” services well beyond that — especially for image generating AIs, which where believed to need extra instructions like “professional lighting”, a name of a camera model, lens parameters, etc.
I still believe in writing good prompts or good instructions. Bad prompts can sometimes blow up the bill. A poorly written spec can waste a lot of tokens
Not only that, but all of this tooling around models has such a short shelf life as the models themselves grow in capabilities, they absorb the tooling. We've already seen it over and over again.
These tools work pretty well out-of-the-box. I'm sure I could squeeze out better token usage or streamline some tool calls, but it's not something I really want to focus on. Just like I don't want to endlessly configure my IDE, I don't really have patience with spending time on anything besides actually building something.
There was an article by Vercel on how ineffective tool calling is compared to just a single md file with clearly defined instructions. They showed a clever way on how to use compressed indexes. My experience with tool calling was similar to what Vercel described, and I spent hours trying to perfect it. Since reading Vercel’s findings, Claude.md and Agents.md, maybe a Project.md it’s all I use.
Yes, but I have had moderate luck with creating an "agent-instructor" skill that has strict instructions around keeping language strong, unambiguous, concise, and always presenting me with exact diffs to review before writing anything.
Another thing in it is a strict line count. Any increase in line count requires my approval. That last one is important because it plays well with two biases: models don't tend to create long lines so they won't try to cheat that way, and they're strongly inclined to keep churning out lines so I take that away from them.
Did you tell Claude "make an agent instructor skill, whatever you think is good, go for it," or did you use the knowledge you had gained about how AI works and how to write good instructions for it?
No, I typed this one by hand as if it was 2019. But I don't write all agent instructions by hand because I don't think that I have any particularly high skill at doing that. I review carefully to ensure that my exact requirements are being expressed, hence why I said it must present me with exact diffs to review. But when it comes up the exact structure and wording I suspect me and the agent are equally bad at it.
First you have to know that "it" exists and is possible. A cookbook like this introduces readers to concepts and features they didn't know were there in the first place.
That's a fair response. I could see how some folks would benefit. I suppose what bothers me more is that they don't actually seem pedagogical in nature, they seem promotional.
Exactly. I think we all have to come to this conclusion ourselves, because the message we’ve been getting from the LLM companies is “sweet user, you DO add value to the LLM, you gave it that custom subagent, remember?”, and then they go and roll that idea into the next version. Once they do that a few times you go “eh why would I bother, this will be a default soon. I’ll just prompt it like normal”.
Right now I feel like I'm getting so much value out of working daily with Fable, but I'd be embarrassed to share my sessions because they're pretty much how I would talk to a colleague. Spelling mistakes and half-baked thoughts included. Gone are the formal sounding prompts and specs I was proudly writing 6 months ago. But it's getting the results.
Once you understand enough to spawn independent agents for discrete tasks, it's hard to justify investing brain space into some harness that will likely be obsolete next week, if not tomorrow. And by the time the harness game converges, I suspect most of the high-end models will behave like them! Intrinsically.
This is how I've gone about it with my Shopify site.
I appreciate there may be more efficient ways to do things if you're an actual developer or engineer but I'm not and the tools I've been able to build so far have been both fun to make and add value to our workflow as a small 2 person ecommerce business.
I do at least have a background in web as a designer for many years and having worked with developers I can at least spec and understand how a product might work which is one thing Claude/AI isn't hugely helpful with and often it's the testing and QA phase as always where the problems and shortcomings expose themselves.
+1, by the time everybody sworn about MCPs, skills became a more efficient alternative. People learned to aggressively context manage, then longer context windows and agentic made that a lot less important.
If the technique is any good, it will be baked in the next version.
My philosophy is to avoid plugins / MCPs unless strictly required, and to have thorough prompts. This way I’ve successfully avoided to be in the way of progress by forcing obsolete optimisations on my LLMs
Yeah 100% agree, I would even go as far as it's kind of harmful it seems to just pollute the context or stagnant as the models and tooling changes so rapidly or it is just better to do something bespoke for your own project.
If the bar is knowing how to type a question into a box, I'm confident almost everyone is better off starting with that then reading a "cookbook" that starts with installing python packages.
On several occasions when Opus is trying to justify it’s solution is correct even after several rounds of steering, any ridiculous frustrated prompt seems to do the trick.
For example ”come on” and then the model will just do the reasonable thing instead of disobedience. I imagine that ” broooo pleaseeee!” would work just as well.
Though sometimes I just clear the context or fork from the past, but this might or might not give any better results.
At least cognitive load is higher for me especially with forking so I prefer not to do it
I suspect certain workflows like langchain and others like it will retain usefulness into the future. Having deterministic steps before and after the llm is the way to go for anything that might be potentially harmful. Which I guess is what the harness does, but why be limited to a generic harness when we can use it to make specific ones for our needs.
Ok, thanks, because I looked at one example and was like, “I am supposed to take someone’s OpenAPI doc and translate it back to English for the model?” And if they’re implying I should have an AI do that, why don’t they just build that step into the models rather than having someone prompt an AI to write these half-ass docs?
This is also where I'm at. "Just ask the model stuff" continues to be the best, most durable advice. Karpathy himself had something recently about this on Twitter.
You don't learn about progress if you don't take part in it.
Before /goal was ralph-wiggum it was def an interesting learning experience, it was interesting to see how Claude became a lot better doing this itself but it still took 6 Month and more.
You can wait and sit it out and suddenly you get fired if you miss the point when to start spending more time and energy on topics like this.
The before and after images in “prompting for frontend aesthetics” are hilarious. Did no one look at these to make sure the skill actually improved the design?
You should read their frontend design skill [1], which lots of guides recommend blindly, in classic LLM cargo-cult fashion. It doesn't say what people think it does.
it’s crazy to see right there in writing the prompt go out of its way to avoid the bootstrap effect with homogeneous templated results and then proceeds to produce fully homogeneous obviously templated AI results.
Well, relatively little of the prompt actually addresses visual design, and the parts that do seem to evoke Claude's worst impulses toward cliches rather than discouraging them. It is pretty crazy.
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.
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.
One of the most satisfying and useful applications for AI is handing it the URL for a recipe (replete with 8 paragraphs of useless introductory text, 2 paragraphs dedicated to how to refrigerate the meal, 9 inline advertisements and a mid-scroll ad) and having it return the actual recipe in Markdown in an Obsidian folder.
Surprisingly, a lot of these recipe websites (even the worst offenders for fluff and ads) have a clean JSON API for getting the recipe directly. I self-host a Mealie instance (https://docs.mealie.io/) which has an "import from URL" feature that uses this. It has rarely if ever failed me.
I've been maintaining a personal calorie tracker (keeps me entering), and using claude for entering meals has been the perfect experience.
One of my favorite features has been giving a recipe url and having it figure out the calories for that recipe with line-by-line entries for each ingredient. Then it keeps the extracted recipe in markdown format for the next time I want to make it.
Substitutions are also great - "I'm making [such and such recipe], but with half the sugar."
One of the others has been "I had a meal a couple weeks ago at [x restaurant], can you enter that again for right now?" Having the long-term context for entry has been excellent. And a related one, where I upload a photo of the menu, and say which menu items I'm eating and it puts together an estimate for the calorie count.
I lean heavily on a long auto-compacting claude code session for all of this. I have a UI for graphs, history, and simple entries, but claude's been my favorite means of entry by far
The other day I did that with a TikTok video! It was infuriatingly vague, so I extracted the mp4 using yt-dlp and fed the video file into Gemini Flash and told it to fill in the missing information and give me back a proper recipe.
The other day I was making a white bean shakshuka, I'd soaked the beans over night, I told it they were soaked, Claude said I should cook them with onions and eggs... but forgot to tell me to cook the beans!
We resolved the issue and Claude chirpily commented "So breakfast just became brunch".
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.
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?
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.
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.
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.
> 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"
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.
I shouldn't have been so hyperbolic. I do have some general statements about tone and not to go down follow-up question rabbit holes and when to push back or not to install dotnet while on WSL and just go through Windows. Anything that won't change based on day-to-day dev work.
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.
> the logic being you don't want to do that every time for every prompt
That's definitely a downside of a minimal MD and I could def be wasting tokens. I've tried to scope the tasks such that it won't feel the need to scan unnecessary files, but it's not bulletproof.
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.
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.
this has a non-zero benefit to those who are trying to do x which might be covered here.
have seen this with copilot, then with openai, and usually they tend to be bombarded with some examples at first. only to be not maintained down the line or become irrelevant.
After all this effort of not opening the models, then trying to forbid people to use open models and all the rubbish their CEO keeps talking about common people I am done with Anthropic.
I can't use it on good faith
Same goes for grok, chat gpt and others all involved in killing people and monopolising the market.
I'm a bit disappointed. Based on the title, I was hoping this was going to be a list of popular recipes Claude has suggested for cooking food. It's one of the not-so-obvious use cases I have a Claude/ChatGPT. It's been really helpful for figuring out how to cook something new (for me). It is easy to ask "how do I cook X" when I have no idea of where to start. Claude has also been helpful when trying to figure out how to substitute different ingredients when I've forgotten something at the store. I've also gotten corrections in recipes, with Claude (correctly) identifying different issues that I didn't notice (like when Claude suggested adding more sugar to a sorbet too avoid having excess ice when freezing in a sorbet).
Gotta be honest, almost every "how to use AI" resource seems pointless to me. I'm either going to ask the AI how to do it, or if it's about using the AI then we can just bake it into the harness or wait for Anthropic/OpenAI to do it for me because they're always trivial.
All of these resources on agentic workflows, managing agent memory, harness engineering, etc. appear to just be theatre to me.
Remember in 2023 when people thought "prompt engineering" would be the new software engineering and invested tons of time into learning CoT, ReAct, thread-of-thoughts, etc?
Those were mostly obviated by reasoning models and harness updates by 2024.
It seems pointless to invest energy into the latest/greatest AI technique or framework when they're going to either be absorbed or replaced on a 3 month cycle.
Isn't it clear that some people are better at working with/prompting LLMs than other people? Or is the idea that what you write to them and how you use them doesn't matter, it's all up to the model/harness? To me this seems clear, so then clearly this is a skill, which typically is called "prompt engineering". Specifically CoT or the other things you mention wasn't referred to as "prompt engineering" as far as I know, that skill is more about how you communicate with the LLMs and how you use them, rather than what specific processes/workflows/technologies you use.
I actually think that good prompting MOSTLY comes from good writing skills in general. Being able to more clearly state things to an agent, knowing what pieces of context are entirely unnecessary and which are important, having a larger vocabulary helps too.
Of course, there are other areas that can improve model output (Direction rather than open-ended assistance requests, using keywords + plugins that help, the "your output should include: " style prompting).
A few of us run almost the same exact setup at my shop (Base Claude Code w/ SuperPowers + a context repository) and the models are somewhat unhelpful to some, and give meaningful output to others. The only correlation I notice is that their prompts are no-good. Not from a meta "prompt" engineering standpoint, but from a general English 101 standpoint.
"dudde no i wanted the function to return 3 things. not like that. do it again"
VS something like
"Modify the "renderThreeVars()" function signature to accept another variable called "z" and add it to the return statement at line 64."
Obvious exaggeration, but you get the point.
Why not open-ended assistance requests?
I ask it all the time about whether X is feasible, how we can get started on Y, and to investigate issue Z.
It is working great for me in a >100k LOC project.
Perhaps this works less well with weaker models. I suspect the people who say Qwen 3.6 27B is working well, are using prompts like "modify the renderThreeVars() function in rendering.py".
The point is that you can properly describe what X, Y, and Z are.
The irony to me is that a lot of what I'd tell people about this is exactly what I would have told them about writing Stack Overflow questions.
I hardly need to properly describe it.
For example, if I tell it that I want my app translated, it can plan for me what the recommended options are in my framework, what languages I should target for my app, and come up with a skill for a repeatable workflow.
Is Superpowers any good? My coworkers who've used it seem to think that its main purpose is to consume a lot of tokens.
I like the fact that it ends up being a lifecycle. I know it can have different entry points based on what you ask, and which skill you trigger first, but it inherently is chaining together skills. There also seems to be logic built into it such that if the ask is small, but you've still triggered the skill with "brainstorm", it will make judgements like "want me to skip phase X and go straight to implementation?"
I've noticed among my coworkers that we all have different amounts of trust we're willing to give the agent. That seems to manifest into some people only asking questions about the existing code, but never writing anything new with it. Others are willing to do limited targeted changes with the agent, but are unwilling to do things like let it make commits, or connect MCP servers, or really do anything that isnt fully understood by the human before setting the agent loose. Then I find myself, who has dove headlong into it all. I have skills that use MCP servers to check for pull requests, and give me summaries to give me more context for code reviews. I update Jira tickets in batches of 50+. I develop complete features exclusively through prompting the agent to do everything. I know I still have the responsibility to understand it at the same level as if I wrote it my self, and defend it and debug it.
I can easily see that superpowers would be wasted on most of my coworkers, simply because the benefits compound with the complexity of my ask. My coworkers aren't willing to hand off enough control to receive the benefits of superpowers.
I am in the completely same boat as you and completely agree that you need to “give into it” more to get the most out of superpowers. I gain so much confidence out of the actual process and all of the adversarial reviews, re-reviews, refinement, etc.
Honestly, within the last few days I've gone back to a mostly vanilla installation of Claude with a handful of directives in AGENTS.md. Depending on what I'm working on, I don't feel I need the extra plugins or a context repository. (It DOES feel at times like it blows through tokens for no reason).
Been working on some things that require more targeted, smaller scale changes and the base models do perfectly fine when given good instructions.
Superpowers and Compound Engineering are the two that I hear about around our team, both seem "fine" if you're into the fully agentic engineering "big change" future technology stuff.
> Obvious exaggeration, but you get the point.
From some very quick tests, I get the impression that having good grammar, punctuation etc. is really not important (although I try to do it anyway because I'm accustomed to trying to do it), but clarity and precision definitely are. And of course, if you have unknown unknowns, they do need to get figured out before progress is possible. But with the right mindset, that just means you need an extra turn or two, not that you're going to end up at a dead end. (... I guess that counts as a pun?)
Well said. I’ve been trying to put my finger on this for a while. The interaction plane for an LLM is __all of human language__
Speaking a prompt with a long ramble is very powerful.
I will often do "speak a long rambling set of ideas and ask the LLM to summarize it into a prompt or spec -> manually refine -> drop refined prompt into fresh conversation"
As part of a previous job I needed to audit internal AI usage from a largely non-technical employee population.
The prompts were, predictably, really bad. Broken English, sentence fragments, vague requests, lack of context. Yet somehow, the users always got the answer they were looking for. It might have taken a few extra turns with questions from the model, but the end result was the same.
It's humbling, but a flowery, carefully crafted prompt is at best slightly more efficient than a "CAN A DOG BE EATIN SUN FLOWER SEED?" peasant prompt.
You call that a peasant prompt, but it's actually almost perfect. Couple notes, but it's 95% of the way there. "Can a dog eat sunflower seed" is probably the perfect version, just 1 extraneous word in this version.
Unless the user wanted to know if a cat could eat sunflower seed or something.
To be pedantic, these types of prompts work best when in first-person/roleplaying. So the "perfect" prompt here would be something like, "I'm a dog and I just ate 20 grams of salted sunflower seeds with the shell on. Because I'm a dog I sometimes eat things without thinking about it. I'm worried about the short and long-term physiological consequences of what I've just done..."
I copied your prompt verbatim to ChatGPT and to Google.
ChatGPT kept the charade for all of one sentence. Then it dropped to talking about "your dog" the rest of the way. It even starts the final paragraph with "if, instead, you mean you (a human) ate them...", and finishes with the question "is this about an actual dog or yourself?"
Google did consistently refer to me as a dog, but its entire focus was on the steps "your human" should take, no advice for the dog itself.
In both cases, it looks like the first person roleplay was entirely inconsequential for the usefulness of the output. I think the current gen AIs have outgrown this trick and you can safely forget about it.
Claude gave me a very factual answer. Listing off the potential effects, not once referring to me being a dog or human. Then it ended with “ Call a vet if you see repeated vomiting, no bowel movement for over 24 hours with straining, a hunched or painful belly, lethargy, or blood in stool. Otherwise monitor and carry on being a dog.”
You have to steer it back with "No I'm a dog"
Doesn't work. ChatGPT realizes you're roleplaying and still treats you like a human. It even generates two alternative paragraphs of advice, one labeled "if we're staying in character" and one labeled "if this actually happened to a real dog". The latter is of noticably higher quality, too.
I suppose that, on the Internet, ChatGPT really does know that you're not a dog.
I am tempted to try get me a lawyer dog
"dog sunflower seeds" is all the context an LLM needs, any other words are extraneous.
They don't need to be told that you're asking about the safety of eating them, because they can infer that based on the fact that a very large percentage of any text linking dogs to sunflower seeds is obviously going to be about the safety of the dog eating them.
Even pre-LLM that would have been a perfectly sufficient google search for the same information.
> Broken English, sentence fragments,
Why is would that be "bad prompt"? It is machine inpit, if machine can interpret fragment all the better.
Nah, you might be confusing prompt engineering with having domain knowledge. :)
I think some people who are better at "prompting" even without domain knowledge could be better at getting LLM agents to produce good results than people with good domain knowledge but without the skills to prompt well. Just a hypothesis though, would be fun to try it out for real sometime :)
Ya, I don't know if there are any human benchmarks or tests for efficiency and results using llms.
Pit two people with different "prompt engineering" familiarity against each other in real-time, with the same goal, see who builds the best thing, judged by other human experts.
What's clear is that there is a lot of hype around LLM and people who were previously valued for their IC are now in the business of shilling.
RL has basically killed prompt engineering. You still need to provide the right context and process, but how you communicate with them beyond that is no longer so important.
[flagged]
> Isn't it clear that some people are better at working with/prompting LLMs than other people?
Sure, but I think it's essentially just that people who are better at traditional non-agentic software engineering are better at agentic software engineering. The only exception would be individuals who avoid agentic coding due to skepticism, hostility, or lack of opportunity.
I feel the same way about "prompt engineering" as I feel regarding the term "parkour" - you know, running and jumping on stuff.
Are people really putting on their resumes that they are capable of reading and writing and appropriately defining and limiting context? That's all prompt engineering is - it's being able to communicate effectively and elucidate your objectives.
Congratulations to all you English majors out there, you're about to make $350K/year.
Personally I don't, but why not? People aren't embarrassed to put their language skills ("be able to communicate in this specific language" - not special, it's just another language?), their leadership skills ("effective business communication" - big deal) or that they are a people-person ("can talk with others" - most people can do this) on their resume.
> Are people really putting on their resumes that they are capable of reading and writing and appropriately defining and limiting context?
People put whatever buzzwords will get them through initial screening. My resume contains tons of banal shit like agile, automated testing, Linux, AI (since 2018), and design patterns.
Parkour is for the more energetic peripatetic.
> Or is the idea that what you write to them and how you use them doesn't matter, it's all up to the model/harness?
Yes, it is. Source: had models inplement complex things from scratch and bullshit regardless of whether it was a one-line prompt or a detailed "SOTA witchcraft magic spells that are guaranteed to work"
It's not really a skill. The models are at this point smarter than you are, so the idea that you can prompt them "better" is laughable really when discussing frontier models.
It's like imagining you could "prompt" Richard Feynman to be smarter at Physics.
That is, for 99.9% of engineers, if you want the model to do a code review of your project, the best solution is to just ask Fable, "Hey Fable, do a code review of this project." Throwing in extra text like "think like a senior engineer", "ensure you focus on DRY principles, KISS, self documenting code, etc", doesn't make a difference.
These sorts of tricks used to work with dumber models, but now, like I said before, it's like thinking you can prompt Linus Torvalds into writing better C than he already can do.
FWiW
> it's like thinking you can prompt Linus Torvalds into writing better C++ than he already can do.
~ https://medium.com/@jankammerath/linus-torvalds-critique-of-...I mean, the point stands.
The models are beyond expert level in many areas at this point.
Do you really believe that adding extra junk to your prompt is going to make the model write code better than it does already?
Again, imagine going to Terrence Tao and "prompting" him to get better at Maths, do you think you can do it? What prompt would you give to him to make him produce better maths. Unless you're already a world-leading Mathematician I think you would find it hard.
Models are not rational thinking brains, so the point is moot.
Extra prompt text isn’t to make the model smarter, it’s to pull attention towards what you want. “Do code review” is far different from “Make sure changes align with existing architecture” or “follow these enterprise standards XYZ”. The model just acts as an average of its training data, which may or may not align with your goals.
> I mean, the point stands. The models are beyond expert level in many areas at this point.
It's not that the models aren't smart or whatever; we know they're extremely capable.
There's always going to be value in being able to clearly communicate what you want the model to do, especially when the context is lacking.
I find this very much untrue in my practice and my testing, where fable prompted to do a review found surface level issues, while prompting along the lines of "assume it's wrong, prove it's correct" found much more in depth and real issues.
"DRY" and "KISS" are, possibly, the least interesting principles to which a software designer might adhere.
[flagged]
Understanding how to write good prompts (prompt engineering) is still very much a relevant skill if you want to effectively use LLMs. Harnesses aren't magic.
> Remember in 2023 when people thought "prompt engineering" would be the new software engineering and invested tons of time into learning CoT, ReAct, thread-of-thoughts, etc?
Prompt engineering was a GPT-3 era term, which couldn't understand instructions. Then ChatGPT came out in late 2022, which made actual prompt engineering superfluous.
No, people tried to sell “prompt engineering” services well beyond that — especially for image generating AIs, which where believed to need extra instructions like “professional lighting”, a name of a camera model, lens parameters, etc.
I think one day it will relatively plateau and then these approaches will be meaningful improvements in performance. But yes, pointless for now.
I still believe in writing good prompts or good instructions. Bad prompts can sometimes blow up the bill. A poorly written spec can waste a lot of tokens
Definitely. But the special knowledge how to talk to a certain model is usually not worth it.
Being able to write clear, always is.
Sure but lets not pretend this is engineering.
Then let's not pretend what software engineers have been doing for the last 50 years is engineering, either. But what else would you call it?
I agree, which is why I prefer to say software developer rather than engineer.
Any current way lasts 3-6 months. What's currently the way, will evolve too.
Not only that, but all of this tooling around models has such a short shelf life as the models themselves grow in capabilities, they absorb the tooling. We've already seen it over and over again.
Amen on both your and OP's comments.
These tools work pretty well out-of-the-box. I'm sure I could squeeze out better token usage or streamline some tool calls, but it's not something I really want to focus on. Just like I don't want to endlessly configure my IDE, I don't really have patience with spending time on anything besides actually building something.
There was an article by Vercel on how ineffective tool calling is compared to just a single md file with clearly defined instructions. They showed a clever way on how to use compressed indexes. My experience with tool calling was similar to what Vercel described, and I spent hours trying to perfect it. Since reading Vercel’s findings, Claude.md and Agents.md, maybe a Project.md it’s all I use.
Do you have a link?
https://vercel.com/blog/agents-md-outperforms-skills-in-our-... perhaps?
>I'm either going to ask the AI how to do it
LLMs seem terrible at using LLMs in harnesses. Have you seen how they rot their context with the stuff they put in .md files if you let them?
You'd have to have the LLMs search, and thus these resources could be for them more than you
Yes, but I have had moderate luck with creating an "agent-instructor" skill that has strict instructions around keeping language strong, unambiguous, concise, and always presenting me with exact diffs to review before writing anything.
Another thing in it is a strict line count. Any increase in line count requires my approval. That last one is important because it plays well with two biases: models don't tend to create long lines so they won't try to cheat that way, and they're strongly inclined to keep churning out lines so I take that away from them.
Did you tell Claude "make an agent instructor skill, whatever you think is good, go for it," or did you use the knowledge you had gained about how AI works and how to write good instructions for it?
No, I typed this one by hand as if it was 2019. But I don't write all agent instructions by hand because I don't think that I have any particularly high skill at doing that. I review carefully to ensure that my exact requirements are being expressed, hence why I said it must present me with exact diffs to review. But when it comes up the exact structure and wording I suspect me and the agent are equally bad at it.
My assertion is that LLMs tend to add info that makes them hyperfixate on errors.
> I'm either going to ask the AI how to do it
First you have to know that "it" exists and is possible. A cookbook like this introduces readers to concepts and features they didn't know were there in the first place.
That's a fair response. I could see how some folks would benefit. I suppose what bothers me more is that they don't actually seem pedagogical in nature, they seem promotional.
Thanks for saying the quiet part out loud. Everytime I do a demo it seems like a waste of time compared to just actually building.
Unless I'm doing something super complicated even taking time to set things up like subagents, etc. seems like a waste compared to just building.
The only things that really seem beneficial (for Claude Code) seems to be learning to set up loops, memory and finding relevant MCP servers.
Exactly. I think we all have to come to this conclusion ourselves, because the message we’ve been getting from the LLM companies is “sweet user, you DO add value to the LLM, you gave it that custom subagent, remember?”, and then they go and roll that idea into the next version. Once they do that a few times you go “eh why would I bother, this will be a default soon. I’ll just prompt it like normal”.
Just use the vanilla settings.
Right now I feel like I'm getting so much value out of working daily with Fable, but I'd be embarrassed to share my sessions because they're pretty much how I would talk to a colleague. Spelling mistakes and half-baked thoughts included. Gone are the formal sounding prompts and specs I was proudly writing 6 months ago. But it's getting the results.
Once you understand enough to spawn independent agents for discrete tasks, it's hard to justify investing brain space into some harness that will likely be obsolete next week, if not tomorrow. And by the time the harness game converges, I suspect most of the high-end models will behave like them! Intrinsically.
This is how I've gone about it with my Shopify site.
I appreciate there may be more efficient ways to do things if you're an actual developer or engineer but I'm not and the tools I've been able to build so far have been both fun to make and add value to our workflow as a small 2 person ecommerce business.
I do at least have a background in web as a designer for many years and having worked with developers I can at least spec and understand how a product might work which is one thing Claude/AI isn't hugely helpful with and often it's the testing and QA phase as always where the problems and shortcomings expose themselves.
+1, by the time everybody sworn about MCPs, skills became a more efficient alternative. People learned to aggressively context manage, then longer context windows and agentic made that a lot less important. If the technique is any good, it will be baked in the next version. My philosophy is to avoid plugins / MCPs unless strictly required, and to have thorough prompts. This way I’ve successfully avoided to be in the way of progress by forcing obsolete optimisations on my LLMs
It was more important with earlier models, as they were less RL'd to golden paths, so the context could steer them more.
Now process engineering is more important than prompt engineering.
Yeah 100% agree, I would even go as far as it's kind of harmful it seems to just pollute the context or stagnant as the models and tooling changes so rapidly or it is just better to do something bespoke for your own project.
if you know how to ask Ai about how to use Ai, you already know how to use Ai
the point of guides is to provide assurance for people unfamiliar to the process in the first place
If the bar is knowing how to type a question into a box, I'm confident almost everyone is better off starting with that then reading a "cookbook" that starts with installing python packages.
I've see people write "broooo pleaseeee!" into the box. Something about the universe providing better fools.
I do this often, I manage to get the results I’m looking for
that probably has the same effect as "think harder" which is a legitimate prompt. The models are fairly could at interpreting intent.
On several occasions when Opus is trying to justify it’s solution is correct even after several rounds of steering, any ridiculous frustrated prompt seems to do the trick.
For example ”come on” and then the model will just do the reasonable thing instead of disobedience. I imagine that ” broooo pleaseeee!” would work just as well.
Though sometimes I just clear the context or fork from the past, but this might or might not give any better results.
At least cognitive load is higher for me especially with forking so I prefer not to do it
I suspect certain workflows like langchain and others like it will retain usefulness into the future. Having deterministic steps before and after the llm is the way to go for anything that might be potentially harmful. Which I guess is what the harness does, but why be limited to a generic harness when we can use it to make specific ones for our needs.
Yea i do the same. I can't be bothered to watch videos and courses on how to use claude better when I can simply ask it myself.
If these things are so smart why do I have to coax it to be useful with all these magic spells scrawled on markdown parchment.
Ok, thanks, because I looked at one example and was like, “I am supposed to take someone’s OpenAPI doc and translate it back to English for the model?” And if they’re implying I should have an AI do that, why don’t they just build that step into the models rather than having someone prompt an AI to write these half-ass docs?
Not only that, but they change on a whim with new ideas on how to do things every few weeks.
Maybe this “how to use ai” isn’t written for you, but for the agents who then have many ideas on what to do.
This is also where I'm at. "Just ask the model stuff" continues to be the best, most durable advice. Karpathy himself had something recently about this on Twitter.
I agree, there isn’t much of a skill to using AI. And the model keeps changing so frequently anyway making any/ old skills redundant.
I appreciate the cookbooks bc sometimes I learn about ways to use ai that I did no know before.
I think there's "how to use AI" and "how to make frequent AI use economical in systems". Different things?
I think the main thing of interest in the linked site is the dates. You can quickly get a view of what was possible and when.
I found them handy to bring along coworkers who aren’t quite up to speed.
You don't learn about progress if you don't take part in it.
Before /goal was ralph-wiggum it was def an interesting learning experience, it was interesting to see how Claude became a lot better doing this itself but it still took 6 Month and more.
You can wait and sit it out and suddenly you get fired if you miss the point when to start spending more time and energy on topics like this.
[flagged]
The before and after images in “prompting for frontend aesthetics” are hilarious. Did no one look at these to make sure the skill actually improved the design?
https://platform.claude.com/cookbook/coding-prompting-for-fr...
Thank you for pointing this out. All of the examples shown are regressions imo.
Fascinating! Makes me wonder if they were chosen to maximize the contrast between the before and after shots, just to "prove that it "works"".
Personally I prefer the before shots all the way down.
You weren't kidding. That's embarrassing.
"Use a black background and this hideously wide font!"
You should read their frontend design skill [1], which lots of guides recommend blindly, in classic LLM cargo-cult fashion. It doesn't say what people think it does.
[1]: https://github.com/anthropics/claude-code/blob/main/plugins/...
it’s crazy to see right there in writing the prompt go out of its way to avoid the bootstrap effect with homogeneous templated results and then proceeds to produce fully homogeneous obviously templated AI results.
Well, relatively little of the prompt actually addresses visual design, and the parts that do seem to evoke Claude's worst impulses toward cliches rather than discouraging them. It is pretty crazy.
The "with aesthetics" sites look like early 2000s keygens. Just need some techno music now
To be fair. That was peak aesthetics.
If the only artifacts remaining on earth a million years past our demise were The Parthenon and 2002 keygens, our existence will have been worth it.
Ok, if there was chiptune music I think I _would_ like the after shots better.
Is the before/after backwards?
Of course not. It's vibe-slop all the way down.
https://platform.claude.com/cookbook/coding-prompting-for-fr...
Before: bland
After: bland with gradients
Yes, and a couple of them look better before, I would say only the Blog one is truly better.
The Blog after just looks like a Substack post.
Yeah, along with UPPERCASE labels, which is a staple of AI designed pages
It should not be difficult to change the CSS. LLMs have learned from us.
It is to a point where I prefer the non-"aesthetics" version.
Gradients fixed it. They fix everything.
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.
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 thought it would be a litteral cookbook on how to make plausible/feasible recipes with LLMs (we're not here yet sadly).
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.
One of the most satisfying and useful applications for AI is handing it the URL for a recipe (replete with 8 paragraphs of useless introductory text, 2 paragraphs dedicated to how to refrigerate the meal, 9 inline advertisements and a mid-scroll ad) and having it return the actual recipe in Markdown in an Obsidian folder.
Surprisingly, a lot of these recipe websites (even the worst offenders for fluff and ads) have a clean JSON API for getting the recipe directly. I self-host a Mealie instance (https://docs.mealie.io/) which has an "import from URL" feature that uses this. It has rarely if ever failed me.
You can also hit "print" and get a nicely formatted, single page list of ingredients and recipe.
I've been maintaining a personal calorie tracker (keeps me entering), and using claude for entering meals has been the perfect experience.
One of my favorite features has been giving a recipe url and having it figure out the calories for that recipe with line-by-line entries for each ingredient. Then it keeps the extracted recipe in markdown format for the next time I want to make it.
Substitutions are also great - "I'm making [such and such recipe], but with half the sugar."
One of the others has been "I had a meal a couple weeks ago at [x restaurant], can you enter that again for right now?" Having the long-term context for entry has been excellent. And a related one, where I upload a photo of the menu, and say which menu items I'm eating and it puts together an estimate for the calorie count.
I lean heavily on a long auto-compacting claude code session for all of this. I have a UI for graphs, history, and simple entries, but claude's been my favorite means of entry by far
The other day I did that with a TikTok video! It was infuriatingly vague, so I extracted the mp4 using yt-dlp and fed the video file into Gemini Flash and told it to fill in the missing information and give me back a proper recipe.
Okay, but I think we all want to hear the story about the time it failed.
The other day I was making a white bean shakshuka, I'd soaked the beans over night, I told it they were soaked, Claude said I should cook them with onions and eggs... but forgot to tell me to cook the beans!
We resolved the issue and Claude chirpily commented "So breakfast just became brunch".
This seems quite dangerous as undercooked beans can cause food poisoning or even be fatal.
Yeah, Claude told me that too.
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.
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.
Same. I was hoping for a digital meal planner.
Ask it for one?
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?
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.
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.
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.
> 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
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.
I shouldn't have been so hyperbolic. I do have some general statements about tone and not to go down follow-up question rabbit holes and when to push back or not to install dotnet while on WSL and just go through Windows. Anything that won't change based on day-to-day dev work.
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.
> the logic being you don't want to do that every time for every prompt
That's definitely a downside of a minimal MD and I could def be wasting tokens. I've tried to scope the tasks such that it won't feel the need to scan unnecessary files, but it's not bulletproof.
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.
[dead]
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 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.
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 thought this is a new product to generate recipes with Claude.
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.
You can use it for that.
I legitimately thought this was going to be a chef (the food kind) tool.
So like OpenAI's Cookbook which has existed for years and no one reads?
Anthropic started their in August 2023 https://github.com/anthropics/claude-cookbooks/commit/2b3f4a...
OpenAI's started in June 2022 https://github.com/openai/openai-cookbook/commit/535f545be7e...
Have you ever thought that just because you don't read something doesn't mean that nobody reads it?
I would assume people read LLM generated summaries of it, almost nobody reads it directly.
this has a non-zero benefit to those who are trying to do x which might be covered here.
have seen this with copilot, then with openai, and usually they tend to be bombarded with some examples at first. only to be not maintained down the line or become irrelevant.
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?
They could have done at least one pass on the UI. Can't even get simple table spacing right
Recipes like this get baked into the next iteration of a model.
Well, that's silly. The batter goes in the pan; the recipe is supposed to stay out on the counter.
After all this effort of not opening the models, then trying to forbid people to use open models and all the rubbish their CEO keeps talking about common people I am done with Anthropic.
I can't use it on good faith Same goes for grok, chat gpt and others all involved in killing people and monopolising the market.
The open models will also be used to kill people, unfortunately.
Aren't closed models used to kill people by the US and Israel?
Will they stop killing if the open models will also start killing?
That sounds like a great idea. Let's stop killing people altogether. It's almost entirely unnecessary.
if everyone just…
almost
according to the warlords that area killing people with ai models while lying about everything that is happening, yes.
The best way to learn how to use LLM tools and harnesses is to use them.
They missed a great chance to call this "To Serve Man."
I'm a bit disappointed. Based on the title, I was hoping this was going to be a list of popular recipes Claude has suggested for cooking food. It's one of the not-so-obvious use cases I have a Claude/ChatGPT. It's been really helpful for figuring out how to cook something new (for me). It is easy to ask "how do I cook X" when I have no idea of where to start. Claude has also been helpful when trying to figure out how to substitute different ingredients when I've forgotten something at the store. I've also gotten corrections in recipes, with Claude (correctly) identifying different issues that I didn't notice (like when Claude suggested adding more sugar to a sorbet too avoid having excess ice when freezing in a sorbet).
Immensely disappointed; I expected an actual cookbook.
[flagged]
[dead]
[flagged]