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.

This article doesn't mention "subagents" https://docs.anthropic.com/en/docs/claude-code/sub-agents which makes me wonder when it was written. I'm finding that just delegating "scan the memory bank for information relevant to the current task" and "run the unit and functional tests and report back only the failures or coverage" to subagents does a lot to keep the main agent's context from filling up.

It's kinda the same as real life project managers.

Yes, kind of like open AI’s deep research tool. I often find that a number of mistakes are made because no clarification questions or ask or even considered.

I'm only three weeks into using Claude Code but I'm now seeing impressive results using a structured, "role" or "persona" based approach in a large (500K+ SLOC) Elixir / Phoenix codebase. I'm using the $200 Max plan - so my inference costs are fixed.

For certain, the results are better when I use it to build new features into our platform - as opposed to making complicated refactors or other deep changes to existing parts of the system. But even in the latter case, if we have good technical documentation capturing the design and how parts of the system work (which we don't in many places), Claude Code can make good progress.

At first I was seeing a fair amount of what I would consider "bad code" - implementation and code that either didn't follow accepted coding style and patterns or that simply wasn't structured for reusability, maintainability. But after strengthening the CLAUDE.md file and adding an "elixir-code-reviewer" subagent which the "developer" persona had to use - the quality of code improved significantly.

Our platform is open source, you can see our current Claude commands and subagents here: https://github.com/Simon-Initiative/oli-torus/tree/master/.c...

Yeah, unfortunately this is very often the case with articles about AI.

In my own experience, this type of stuff is just wishful thinking right now: for anything non-trivial, you still need to monitor Claude Code closely and interrupt when you discover it goes on the wrong train of thought.

Additionally, for security reasons, you don’t want it to give it too many permissions, and/or actually see which commands it’s executing.

The “frameworks” OP talks about are still far away. Right now the best way to think about it is an intern which is usually wrong but can cramp out code at lightning speed.

looks like either author didn't checked well repos that link or it's indeed redacted deep research output.

Examples: superClaude is not mcp server at all metaGPT looks like is not compatable with Claude code at all

The BMAD system seems similar to the AgentOS mentioned in the post.

This way of context engineering has definitely been the way to go for me, although I’ve just implemented it myself… using Claude to help generate commands and agents and tweaking them to my liking, lately been using json as well as markdown to share context between steps.

What is this? Just a system prompt? What makes it so good for you?

https://github.com/bmad-code-org/BMAD-METHOD

BMAD is mentioned in the QA part, FWIW.

Same with taskmaster, also not there.

The models are still ingesting text, are they not? Those framework are providing textual guidance to what the task at hand should be aim for. Those are formalising part of the context passed to the LLM, regardless of the model itself.

That’s like saying a vim expert would be slower in VS Code - technically the IDE does more, but expertise with your existing tools often beats learning new ones.

Also that study was from early 2025 before Claude 4 which to me was a big break through in productivity, I did not really find these tools too useful before using sonnet 4.

Having occasionally looked into these, the overwhelming issue is that pretty much all of them are built with themselves and the output is what you'd expect - vast quantities of untested functionality, no documentation beyond a wall of Claude-isms about how next generation and feature rich it is, and no thought to applicability beyond the narrow set of projects that interest the author.

> Are you seriously talking about predictable when talking about a non-deterministic

Predictability and determinism are related but different concepts.

A system can be predictable in a probabilistic sense, rather than an exact, deterministic one. This means that while you may not be able to predict the precise outcome of a single event, you can accurately forecast the overall behavior of the system and the likelihood of different outcomes.

https://philosophy.stackexchange.com/questions/96145/determi...

Similarly, a system can be deterministic yet unpredictable due to practical limitations like sensitivity to initial conditions (chaos theory), lack of information, or the inability to compute predictions in time.

Yes, and there is absolutely nothing wrong with that. Living creatures are mostly black boxes. It doesn't mean we don't aim for making medicine with predictable effects (and side effects).

Non-deterministic does not mean not-predictable.

Quantum mechanics is non-deterministic, yet you can predict the motion of objects with exquisite precision.

All these "non-deterministic boxes" will give the same answer to the question "What is the capital of France"

Would you say a top tier human developer produces predictable output? I would, in the sense that it will be well designed and implemented code that meets the requirements. Can we guess every variable name and logic choice? Probably not.

Huh? I guarantee you, if you give two different developers tbe exact sane set of requirements, that you’d get two very different programs. Try it. They likely perform differently also, performance- or resource-wise.

Would you still call that predictable? Of course you would, as long as they meet your requirements. Put it another way, anything is unpredictable depending on your level of scrutiny. AI is likely less predictable than human, doesn’t mean it isn’t helpful. You are free to dismiss it of course.

[dead]