I never let it go into planning mode, other than to output a plan file that I can audit before giving it the go-ahead to implement. After that I don't want to be bothered, so --dangerously-skip-permissions keeps all but real questions out of the loop, and I can do something else while it works rather than babysit.

This is my impression too. Whenever it needs permissions outside of a small set of defaults I've allowed, it's often because it's trying to do something ridiculous that it doesn't need to do.

I think the yoloist counter-argument is "So what? Let it. It'll take longer that way and consume more tokens, but you can work on something else in parallel instead of being hooked in to this one session".

I do it with every project I go into. First step is setting up the documentation so that the agent can navigate it quickly, knows the idioms, knows the test gating procedure, design principles, coding standards, testing policies, etc.

Once that's set up, I spend time laying out the planning for whatever feature or fix is being worked on. For fixes the agent is pretty quick and usually needs little guidance. For new features it's best to have more of a hand on the tiller.

Wow... Our experiences have been very different, then. I've found each upgrade of Opus to be a noticeable improvement in its complex reasoning and delegation capabilities over its predecessor.

To me, this feels in many ways like a technical manager or team lead's job, where I guide the process along using my knowledge and experience, and then let the agent fill in the rest (to the best of its ability).

The agent can't really learn from its mistakes (at least, not without consuming precious context), so I apply a blameless postmortem process, updating the guardrails whenever it goes astray in the same way more than once.

And really, I'd rather be contemplating the more difficult and interesting questions of architecture, environment, ergonomics and market fit, so it suits me fine.

I think this is just a misunderstanding of how most technology has always worked?

Consider what is happening in most construction sites. The heavy work is absolutely from the technology on site. But without people there to oversee it and keep it working, it would fail.

And that is almost certainly true at any industrial site. Indeed, look up videos of high tech looms. A large portion of the technology added to them are so that the operators can locate the fault and fix it.

AI should be assisting us, instead it's doing the job and it's us being an assistant to it.

If you're a manager and you ask a report to do something and they come back with a question, does that mean you're now their assistant?

I give agents the tasks, I answer their questions, I make choices about the tradeoffs in their plan, I supervise their implementation, I review their output, I have them walk me through things. In what way is this not delegating to them and managing their work, just like a more junior employee?

The problem (okay, one of the problems) with renting other people's models is, as you mentioned, that they can and will change out the model without notifying you ahead of time, and you don't always get to control which model you use. (They might decide to retire it, and you won't be able to get it back if they do).

Which is why (well, part of why) I think the long-term trend will be towards self-hosting models. Right now the frontier models are far enough ahead of the self-hosted ones that there are lots of people willing to pay by the token to rent someone else's model, because they get more value for money from that than from self-hosting models.

But the frontier companies won't be able to keep up their current levels of expenditure forever. At some point the investors are going to say "Hey, so, um, when am I going to see some return on my investment?" and then the current subsidized subscriptions (including the one my employer uses) are going to go away, much like what happened with Copilot this month.

And then the locally-hosted models are going to suddenly look like a more attractive picture. Because where you might have been willing to spend $100/month/employee to rent time on models in someone else's data center, you might suddenly balk at spending $500/month/employee. You might say "Hey, you know what? A $50,000 up-front capital investment is only, what, one month's worth of subscriptions for our 100 employees? Yeah, okay, I'll approve the hardware purchase. Get that self-hosted model set up and then we'll cancel the subscription and switch over."

Not everyone is going to do that. But once the locally-hosted models are good enough, the first few people who do so and report success are going to start a snowball effect. And it will likely be driven by money first, but it will also have the effect, that people will slowly discover, of meaning that you can better predict the model you're using. It will continue to work the same way next year that it is working this year; or if it doesn't, it's because you chose to install the new version.

And when that happens (I'm saying "when", not "if" because although it might take some time, I think it's inevitable in the long run), the frontier-model rental companies are going to struggle to stay afloat. Except for the ones who saw this coming and transitioned to a non-subscription income source somehow (maybe by selling licenses to self-host their frontier models for $$BIGNUM), or who have some other revenue stream besides renting out models.

That sounds weirdly gendered even though there's no reason it should be.

Are you getting LLMsplained? :)

Well... as a human software engineer, I've been the one with very strong, intelligent, completely wrong takes. The question is, are the LLMs improving faster than you can improve a junior dev? And is their ceiling as high?

That’s a problem with the tool not the people. AI is marketed literally as writing one sentence and having some app perfectly output. Just check any of the landing pages for Claude code or codex or GitHub copilot…