Is it ironic that the project with the most potential for making C++ build quickly is suffering the most from C++ being extremely slow to build?

Beyond that, what a superb overview. More open source projects could learn from this posting. It provides a great list of areas for someone who wanted to get started contributing.

Weird. I find Opus knows the answer more often, plus its explanations are much clearer. Opus puts the main point at the top, while Gemini wanders around for a while before telling you what you need.

There's a simpler design here begging to show itself.

We're trying to orchestrate a horde of agents. The workers (polecats?) are the main problem solvers. Now you need a top level agent (mayor) to breakdown the problem and delegate work, and then a merger to resolve conflicts in the resulting code (refinery). Sometimes agents get stuck and need encouragement.

The molecules stuff confused me, but I think they're just "policy docs," checklists to do common tasks.

But this is baby stuff. Only one level of hierarchy? Show me a design for your VP agent and I'll be impressed for real.

‘We need to offshore to a cheaper token provider’ after which the town burns down.

The right number of frameworks in a company is log10(number of employees). Go over this limit, and everyone needs to learn too many frameworks with too little support, examples, tools, and documentation.

I also think the author is understating how bad the original framework was. I've seen some of these and the "itchy points" are real true problems. The team supporting the framework decides that fixing the pain won't get them promo because it doesn't show up in any metrics, and certainly they won't accept your submitted improvements. Your only choice is to wrap it.

Of course, since their thing is a framework, your wrapper must be a framework too. (Is it possible to wrap a framework into a library?)

The end of the story is even sadder. You work on your replacement and wrapper, and oh no, the framework you are wrapping has problems or slowness because of the framework it depends upon!

Yes, I've also been confused by things like this. Claude code is sometimes saving plans to ~/.claude/plans under animal names. But it's not really surface where the plan goes, not what the expected way to refer back to them is?

It's a cache pretty much. Before it wrote them to the project directory by default, which is really annoying.

Now it has a file it can refer to (call it "memory" to be fancy) without having to keep everything in context. The plan in the file survives over autocompact a lot better and it can just copy it to the project directory without rewriting it from memory.

Yup, the "switch desktops/spaces" input lag is the absolute worst on Mac. It's remarkable that Apple has a reputation of being good at UX.

Agreed, I don't love the CLAUDE.md that gets autogenerated. It's too wordy for me to understand and for the model to follow consistently.

I like to write my CLAUDE.md directly, with just a couple paragraphs describing the codebase at a high level, and then I add details as I see the model making mistakes.

This kind of behavior should re-open the return window for the car.

I wonder if we're gonna see a class action lawsuit.

Backblaze stuck my email on a list, and now I get daily marketing spam from them. They shattered that good will with me very quickly.