She has newer posts on sub agents
I would love to see other setups, like what MCP, hooks, sub-agents, commands, etc.
Shit’s moving fast and the math works out such that it’s probably better to just find someone at the bleeding edge and offer to pay them really generously to work with us than to recruit for this work normally. If you change your mind you can find my email on my profile!
Edit for more context: We’ve basically had the same thing as Claude’s slash commands (we call them workflows) since November, but then we switched gears and made our cloud IDE/agent sandbox and other components of our infrastructure layer the top priority.
That’s working and the timing is amazing since we should be able to just glue all these new cli (sub) agents in between our workflows and agent infrastructure. I suspect someone who understands terminal agents well could do it about 4x faster than me.
Maybe that's why the guides you see appear a bit out of date? Writing, all kinds of communicating, takes time, both in organizing and compiling your thoughts
I've created a (way smaller) "/hire" command that does something similar, but I should probably turn it into an agent as well, as the commao is only creating agents, and I still need to do further adaptation with individual promoting and edits
It's these little, but crucial insights that make all the difference, so thank you!
I have the exact same feeling about losing time, for me it's starting to turn into an addiction,
I'm buiding a new side product, and the sense of urgency combined with the available capability makes it hard for me to stop working.
Progress is going so fast that it feels like the competition might catch up any time now.
I now restrained myself upfront with predefined timing windows for work, so the I manage to keep my sanity & social life from disappearing...
"What a great time to be alive"
I had started working on an AI devtool product a few months before Cursor took off, I didn't even know about them when I first started, and I hated that such a dumb UX was setting the narrative in this space. LLMs had essentially no ability to decompose and plan tasks at the time, and they weren't fucking sandboxing it!
Terminal agents are actually moving towards the UX I've been building/anticipating for. In March of 2024 I was playing around with GPT4 and saw it oneshot a microservice I asked it to make. I was so excited about the implications of where this stuff could go that I quit my job at google just to start building in this space.
Without getting into all the details, I am pretty convinced there must be some particular way of arranging infrastructure primitives and AI-coding tools in a way that properly decomposes and executes arbitrarily large or complicated tasks (limited only by available time and resources). Claude code is IMO getting closer to that by the week. No iterative change is crazy science or anything but there are some genuinely novel and exciting patterns for computing things underway.
Agents have their own context and can be useful for tasks that can be parallelized, which is a minority of tasks. How are they critical to better performance for you?
Let's consider context. At some level the more context you have is good. At some level, the more irrelevant context you have is bad.
Okay. We have at top level of context, a hook that forces a system prompt on every action.
Next level we have a ./claude/CLAUDE.md then we have the project level CLAUDE.md then we have a possible not required agent setup then we have the instructions you give it
We know that CLAUDE.md gets lost in the context, at any level. The system prompt level hooks don't.
Why does the CLAUDE.md get lost? Why are we losing ability with a longer context.
The problem is irrelevant context to the action. The Documentation agent doesn't require the Golang modernization rules. The Golang agent, doesn't require the planing coordinator rules.
So the question I asked myself last weekend was, what is the experience if you split the contexts to only the required information for the task.
I did head to head battles with agents, reading in the information, versus contextual specific information. The agents with context specific destroyed the competition. Like it was another world.
So then I ran head to head tests on the type of information. Etc etc. My current setup is the best level achieved in those tests.
So my argument is that removing the context that is entirely irrelevant for the agent improves performance dramatically.
But I'm one person doing tests... it's true for me. Maybe it's not true for others. People have to explore the conception and determine that.
I can only tell you what has worked best for me, and for me, it's like a model jump in performance improvements.
I've been exploring the ways in which I could "lazy load" context depending on the task at hand. I've approached this by defining an AI "receptionist", a set of roles and a set of tasks.
The receptionist is the entrypoint of the system. It knows where to find roles/tasks but only loads very basic information about the roles.
Depending on the role I ask for, it then loads the right role file, which in turn loads additional context. Then I ask for whatever i want to do, and it loads specific task files based on what I asked. And the task files load additional context etc.
This works quite well because I end up with just the right context for the task at hand. And each role/task can actually be executed as a sub-task/agent
100% agree on building the optimal context, just have not seen parallel agents do better at sequential tasks. the documentation agent may have better initial context about how to write documentation, but it doesn't have the context of the changes, apart from what is passed to it / can explore. if we don't spawn a new session, and instead throw it a /document command - that would still get all the guidelines and rules for writing documentation, and it should have the same weight since it's at the bottom of the context.
for me the highest 'model jump level' performance booster is externalizing context and controlling the process - having claude initialize a plan file with a pre-defined template that makes it use that as its to do list and documentation place, and getting it to use that as its primary working area
It all builds on each other, so it can be slightly challenging to untangle which part is providing the majority of benefits.
The more I focus the less I have time to read and experiment O want to finish it. What are your sources and how are you balancing it ?
MCP servers and the rest have not provided the type of gains sub-agents have. Hooks and subagents actually provide tangible value. Enough that it's changed my structure entirely to be tool focused, and not output focused.
I didn't release it as open source or anything, just sharing. I don't want to take questions concerning it so I can focus on moving it forward.
Today's goal is to try to build self healing agents that automatically fix the problems they encounter so they only happen once, automating a manual process I successfully use.
Perhaps if that works out well, that is something releasable I can do in a real way as opposed to paste bin.
It destroys the context for readers, making the thread worse for everyone.
However posts like this is valuable for new people to get a basic understanding of how these tools could be used in a very simple, beginner friendly, setup.
- I wouldn’t outsource my brain to CC when it comes to checking CC’s output. Very mixed results in my experience, and it might discourage further exploration/thinking if you’ve already performed the checklist CC has given you (satisficing).
- Slash commands are the idiomatic way to memoize often used prompts, I wonder why author put them in CLAUDE.md?
- I’m also a bit skeptical that, aside from strict rules CC needs to follow, the encouragements/enchantments for writing good code author put in CLAUDE.md really work. But who knows.
- I DO like the caveats section at the end a lot. This is probably the most important piece of the article, when it comes to large codebases. Never just accept the first draft. Review everything with high suspicion and bend the output to your own style and taste. Otherwise, you‘re pushing legacy code.
At the moment they burn a investor money to gain customers by giving us free tools and cheap LLMs.
That will end at some point.
Maybe it does have some valuable content but I will just close it.
That is a bit over the top, but the core statement kind of stands.
Why would you need that?
> CLAUDE.md is a special file that Claude automatically pulls into context when starting a conversation.
https://www.anthropic.com/engineering/claude-code-best-pract...
That CLAUDE.md file that they've posted is also HUGE - Anthropic themselves recommend keeping it on the more concise side. If you need more, consider just creating dedicated subagents for "UI/UX reviewer", "search", etc.
Like "for guidance on Go library selection refer to docs/go.md"
That way the main file stays compact.
This is like 99% of my CC interactions working on top of a well structured codebase and it just works perfectly for almost any task I throw at it.
campbel•6mo ago