>I can bet that a single standard instance of existing tool like codex and Claude Code

This is a perfect example of what I'm saying. You'd bet that, because you don't have enough experience with the tooling to know when you need more than a "standard instance of existing tool"

Here's a real-world case: Take some 20 year old Python code and have it convert "% format" strings to "f strings". Give that problem to a generic Claude Code setup and it will produce some subtle bugs. Now set up a "skill" that understands how to set up and test the resulting f-string against the %-format, and it will be able to detect and correct errors it introduces, automatically. And it can do that without inflating the main context.

Many of those items I mention are at their core about managing context. If you are finding Claude Code ends up "off in the weeds", this can often be due to you not managing the context windows correctly.

Just knowing when to clear context, when to compact context, and when to preserve context is a core component of successfully using the AI tooling.

I agree completely.

I don't need to trust you, I've done my own testing and using newer tooling features is dramatically better than not. One of the things about the AI tooling is that it's very inexpensive to run experiments (this week I've had it build a particular tool in Python, Go, Rust, and Zig, for example).

Using skills, multiple models, MCPs and agent teams is significantly improving the results I'm seeing in real world problems.

You haven't really given me any reason why I should trust you, but I'll tell you it's going to be hard for me to trust advice that contradicts my test results.