Hacker News Reader

I'm also skeptical partially because I don't like the huge essays generated by any llm. CLAUDE.md/AGENTS.md/README.md that are 5+ pages long are all equally bad imo. I prefer following the idea that if something is too verbose for me to want to get anything useful out of it, then the llm should behave similarly. Even if it's not true, why waste 2 paragraphs explaining something that could be explained in one short sentence?

My CLAUDE.md or AGENTS.md is usually just a bulleted list of reminders with high level information. If the agent needs more steering, I add more reminders. I try not to give it _too_ broad of a task without prior planning or it'll just go off the rails.

Something I haven't really experimented with is having claude generate ADRs [1] like your RFC/ idea. I'll probably try that and see how it goes.

[1]: https://adr.github.io/

One of the main things I put in my instructions is "hey I'm a solo dev and it's just you and me working on this stuff, so I'm looking for all responses to be concise." I think it helps to give your situation so that the output can be in the proximity of "solo dev" content - which is going to be more concise and practical by nature.

Kind of like telling it to generate Ghibli pics. These things are best at imitation.

That's probably a good one to keep in there, I'll try it too. Maybe it'll help with the "Here's the plan:" where it starts listing phases and hours/days/weeks for each phase even though it's going to be doing most of the work asap

You don't need subagent, I shared this on ClaudeCode sub as well https://www.reddit.com/r/ClaudeCode/s/barbpBxG78

Subagents do not work well for coding at all

Subagents are literally built into Claude Code via a built-in tool where it can recursively call itself

Yes I know, but subagent suffer from context amnesia during context handouts which is why this subagent use is flawed for purpose of coding product features. I've been using these tools a lot and installed every ai agent out there i could find.

Yup, this is the killer. Subagents SEEM good when you use them on greenfield projects, you can grind out a whole first pass without burning through much of your main context, it seems magical. But when you have a complex project that handoff is the kiss of death.

I'm wondering if in large projects, you want subagents to avoid having tasks flush out the main context?

If you're working with large source files, you might want to do each piece of work in an independent context with the information discarded afterwards?

Is the context a sliding window, or are there tiers of importance?

No the context going out of control is overblow. Lemme example why. First you need to work at feature level. It shouldn't be too large of a feature in one go.

Let's say in my workflow, first agent must know where it needs to make changes? So it greps bunch of files and reads them. We do not need these read calls or grep calls to be part of history, the knowledge gained by doing these is what needs to be part of context

Finally, we do some risk analysis and then just code it right away.

No sliding window needed for this

After this you reset context /reset and u start on new feature.

> No the context going out of control is overblow. Lemme example why. First you need to work at feature level. It shouldn't be too large of a feature in one go.

As a meta point, why write ' Lemme example why.' ?

If someone is still with you at this sentence, that person was ready to understand why.

Otherwise, it delays (and thus endangers the visibility of) whatever your explanation was going to be.

So maybe the solution is to make all subproblems greenfield products?

By this I mean treat features as isolated plugins. I get that there are cross-cutting features that touch multiple pieces of functionality, and those probably need special treatment, but a large class of functionality can be developed in an isolated way with a common set of design tokens and APIs to tie them all together.

This might play better to coding agent strengths.

Full disclosure: this is very much an armchair view. I have all of 2 weeks of experience coding via agents (vs manually), but this thread is nerd sniping me into trying it myself.

I do try to do this, from an architectural standpoint it starts with modular monoliths to avoid coupling, then I try to decompose problems in a way that is very sandboxed so the blast radius of an agent going of the rails is contained.

So the things people hate Java for will make a big comeback then? Hexagonal architecture with domain driven design,a big fetish for inversion of control, so the LLM never needs to figure out how the system works, it just magically does. And errors have just the right amount of stack trace, this being 500++ lines

A lot of old school "java-ish" paradigms are going to come back with AI for the same reason people used them with Java back in the day - they put golden handcuffs on implementors, which is a bad tradeoff for competent, agile humans but a very good tradeoff for sometimes off the rails agents. This includes waterfall, spec driven development, front loaded planning, extensive automated testing suites, formal verification, etc.

Subagents suffer from the same overriding problem with "Claude Contexting", which is context wrangling. Subagents "should" help to compartmentalize and manage your context better, but not in my experience so far. I found I was jumping through a lot of hoops with special instructions, manual compacts, up front super detailed plans, and MCPs just to manage my context. So subagents is probably the same, where you want to have it handle tasks that do not require context from your main thread.

P.S. I know they added 1m context to their API, with a price increase, but AFAIK the subscription still uses the 200k context.

> Subagents do not work well for coding at all

Subagents can work very well, especially for larger projects. Based on this statement, I think you're experiencing how I felt in my early experience with them, and that your mental model for how to use them effectively is still embryonic.

I've found that the primary benefit for subagents is context/focus management. For example, I'm doing auth using Stytch. What I absolutely don't want to do is load https://stytch.com/docs/llms.txt and instructions for leveraging it in my CLAUDE.md. But it's perfect for my auth agent, and the quality of the output for auth-related tasks is far higher as a result.

> your mental model for how to use them effectively is still embryonic.

Well

> I've found that the primary benefit for subagents is context/focus management. For example, I'm doing auth using Stytch. What I absolutely don't want to do is load https://stytch.com/docs/llms.txt and instructions for leveraging it in my CLAUDE.md.

> But it's perfect for my auth agent, and the quality of the output for auth-related tasks is far higher as a result.

What about just using a sub agent specifically to fetch llms.txt and find the answer to the question for the parent agent? Instead of handing a full task off to it

I'm unsure if this also qualifies as incompetence/embryonic understanding, though I've used LLMs for hundreds of hours on development tasks and have also found that sub-agents are not good at programming. They're more suitable for research tasks to provide informed context to the parent agent while isolating it from the token consumption which retrieving that context cost.

Zooming out, my findings on LLMs with programming is that they work well in specific patterns and quickly go to shit when completely unsupervised by a SME.

  * Prototyping

  * Scaffolding (i.e. write an endpoint that does X that I'll refine into a sustainable implementation myself)

  * Questions on the codebase that require open-ended searching 
 
  * Specific programming questions (i.e. "How do I make an HTTP call in ___ ?")

  * Idea generation ("List three approaches for how you'd ____" or "How would you refactor this package to separate concerns?")

The LLMs all fuck up on something in every task that they perform due to the intersection of operating on assumptions and working on large problem spaces. The amount of effort it takes to completely eliminate the presence of assumptions in the agent make the process slower than writing the code yourself. So people try to find the balance they're comfortable with.

You didn't not bother reading my actual criticism against subagent model: https://www.reddit.com/r/ClaudeCode/s/weQIbVtAtG

Let me say it again, subagent model does not work for things which most developer do 90% of their time they want to implement a feature in their app.

> You didn't not bother reading my actual criticism against subagent model:

Nope, I did. It's why I was under the impression that you hadn't yet figured out how to use them successfully. That's why I posted a specific example where a subagent is useful and why, hoping you and others might benefit from that.

If the subagent model does not work 90% of the time, why does the workflow model you recommend in another Reddit post you linked to specifically recommend delegating work to sub-agents throughout?

I've been using sub agents for long time now, see: https://www.reddit.com/r/ClaudeCode/comments/1nh75k2/3_phase...

I highly recommend to check how agents are used in this project: https://github.com/humanlayer/humanlayer/tree/main/.claude/a...

I found this out after this YouTube video that explains the rationale behind it: https://www.youtube.com/watch?v=IS_y40zY-hc

I found a study a while ago that measured the effect of defining personas, and the effect was significant, but not very big. I like defining roles because I think it makes setting boundaries a bit easier. When I assign the role of architect for brainstorming, I expect the model to be a bit less eager to immediately jump into implementation. I'll still tell it explicitly to not do that, so the effect is probably extremely small.

So far, I find it much more important to define task scope and boundaries. If I want to implement a non-trivial feature, I'll have one role for analyzing the problem and coming up with a high-level plan, and then another role for breaking that plan down into very small atomic steps. I'll then pass each step to an implementation role and give it both the high-level plan and the whole list of individual steps as context, while making it clear that the scope is only to implement that one specific step.

I've had very good results with this so far, and once the two main documents are done, I can automate this with a small orchestration script (that does not depend on an LLM and is completely deterministic) going through the list and passing each item to an implementation agent sequentially, even letting the agent create a commit message after every step so I can trace its work afterwards. I've had very clean long-running tasks this way with minimal need for fixing things afterwards. I can go to bed in the evening and launch it and wake up to a long list of commits.

With the new 6 dollar subscription by Z.ai which includes 120 prompts (around 2000 requests) every 5 hours, I can pretty much let this run without having to worry about exceeding my limits.

I too am skeptical about the personas, but I still use them to organize context and instructions for different types of work. I use a top-level .agents dir, with commands, roles, and rules, sub-dirs.

CLAUDE.md is kept somewhat lean, with pointers to individual files in ./docs/ and .claude/commands is a symlink to .agents/commands.

After starting Claude, I use /commands to load a role and context, which pulls in only the necessary docs and avoids, say, loading UI design or test architecture docs, when adding a backend feature.

I don't want to have to do any of this, but it helps me try and keep the agents on the rails and minimize context rot.

This concept is in the novel Accelerando - so I think once again it's just AI-fans LARPing, just like the rest of the current LLM hype

Ive been struggling to get frontend/backend aware claude code working in a way I like. So are you saying you plan it out with the parent one, and then have it output a file in some format that you then pass to the frontend and backend claude’s individually? but those “sub claudes” don’t actually have the other repo’s context?

Agreed, the roles seem more cerenonial than anything else.