On the flip side, a lot of the reasoning and decision making might have happened in the conversation which is more ephemeral than a comment. A future LLM-age source code repository would store the conversation along with the commit, for future reference by humans or LLMs.

Just quit reading the code then duh ¯\_(ツ)_/¯

Depends on how in-the-loop you want to be. I personally delegate all the writing of the code to agents, but I maintain a clear mental model of the architecture, which I come up with by iterating and prototyping with agents. I can use Luna for all of this, although I switch depending on the task. It's nice to be able to throw a 1,000 word rough spec at Fable and get a personal tool that works perfectly though. I expect that as the models get better, I'll continue to be in the loop, but operate at increasingly higher levels of abstraction.

Having worked with both, it seems like a control thing to me. Either you're cool with Fable spitting out tons of code you'll never read, or you're cool with Luna doing targeted work while you manage the main work thread.

(I'm in the second boat so long as I'm responsible for the code I PR)

I'm ok with not-Fable until I need anything design-related: a nice HTML page, LaTeX typesetting, UI design. Sol is especially incapable of doing anything sensible.

Is there any alternative model with design sensibilities?

GP kinda explains why: "You have to lead it by the nose".

If you're happy to "lead it by the nose" you can do well with a lot of very low end models.

If you want to kick off a "/goal run until [complex verification passes]" and let it run for a week with minimal intervention, then not so much.

You can make do with cheaper models for long running agentic runs too, but it tends to require a lot of extra scaffolding and additional review steps.

I'm happily in both depending on what it is. Even Sol / Fable cannot do some truly novel stuff and if you rely on it too heavily you get detached from the underlying systems to the point that it's both uncomfortable and detrimental.

Yeah, it's about, do you guide it, or does it guide you.

People who know what they want and know how to describe what they want with sufficient detail, and everyone else.

The thing about consulting is that someone needs to verify the output, know what questions to ask in the first place, and provide a throat for the client to choke in the event of an issue. Also, professional insurance. I could be wrong but in the worlds I live in professionally, accountability is still a thing.

Why do you need to involve IT?

What I do notice is that when it doesn't have the info it needs, or when I don't tell it that I'll handle part of the process, it will indeed do everything to get the job done. Also saw this but find this a great quality, because I never ask it to do anything that would involve unhinged things. Sol and other models as well have just gotten so damn good. They can get just about anything done and usally do it well too. Maybe I was inexperienced in prompting, but I remember doing much, much more handholding with late 2025 LLMs.

Nothing weird or exotic - just frequent daily work in two reasonably large applications, with a lot of testing and follow-through. I've found that as codebase size goes up, token usage does too - perhaps quadratically, and a complex back end application just costs a lot to work in, probably because it needs to map out so many pathways and interdependencies.

I tend to work in 5-10 or so parallel streams at a time so that also multiplies token use as a function of time. Much less and I'm waiting for it too much, much more and I can't juggle effectively. My new big project is of course to try to take myself out of the equation further and increase the parallel streams dramatically; pretty hard to get that right so still manual for now.

Completely disagree (except the Sonnet bit, yes, it's degrading).

"then the cost of executing that plan is a just one turn more of cached tokens, and minimal time."

This is just not true at all. There's a huge gap between 'figured out the hard stuff' and 'rock solid'.

Dependencies, integration, corner cases, docs, testing, unforeseen issues, a lot of back and forth auditing making sure things are really tight.

Audits get diminishing marginal returns, but you have to do them until they don't find anything, and that's usually a few cycles.

So aside from the fact there is 'a lot of labour' - part of the plan (maybe the most important part) is documenting most of the trip-up scenarios. If you ran an experiment or two in the background your agent will 'discover' a few key odd things, you back those into the plan.

I'm 100% certain that this pattern works because I (and others) use it very successfully.

Hint: save your main context by using sub-agents to do grunt work - even in impl phase - farm out anything directly implementable without a ton of background.

Also - make a skill so your Claude can call Codex and visa versa and maintain long-running sub agents of 'the other kind'.

An Opus with 1M context window executing on a 'plan' that a Codex 'sub-agent' is executing on - ad a different Opus sug-agent is auditing hard ... that 1M token window is dramatically extended to 'many millions of tokens'.

That can work within Anthropic/Codex Pro plans.