←back to thread

The Claude Code Framework Wars

(shmck.substack.com)
125 points ShMcK | 2 comments | | HN request time: 0.609s | source
Show context
grim_io ◴[] No.45159935[source]
I've tried some of those "frameworks" for claude code, but it's difficult to measure any objective improvement.

I tend to lean towards them being snake oil. A lot of process and ritual around using them, but for what?

I don't think the models themselves are a good fit for the way these frameworks are being used. It probably goes against their training.

Now we try to poison the context with lots of (for my actual task at hand) useless information so that the model can conform to my superficial song-and-dance process? This seems backwards.

I would argue that we need less context poisoning with useless information. Give the model the most precise information for the actual work to be done and iterate upon that. The song and dance process should happen outside of the context constrained agent.

replies(3): >>45160140 #>>45160921 #>>45163521 #
1. bicx ◴[] No.45160921[source]
I adopted a couple practices (using dev containers and worktrees) just to make life a little easier. I also built my own shell script “framework” to help manage the worktrees and create project files. However, that took me just a couple days to do on my own (also using CC), and it didn’t lock me into a specific tool.

I do agree that context poisoning is a real thing to watch out for. Coincidentally, I’d noticed MCP endpoint definitions had started taking a substantial block of context for me (~20k tokens), and that’s now something I consider when adopting any MCP.

replies(1): >>45161259 #
2. grim_io ◴[] No.45161259[source]
I'm considering removing serena MCP, since cc got better with its own tools.

The new /context cc command is great for visualizing what uses how much of the context.

On the other hand, I'm curious about dagger's container-use MCP. https://container-use.com/agent-integrations