alt Hacker NewsI would say they're great until they aren't. Which means at some point in a session or in a long-lived-project they will resist very hard being steered like it would be done by another developer, product manager, a designer, or just the market in general.
Most people don't find this to happen because the size of projects and the granularity of the expectations are wildly different.
I found that agents help, even if you don't parallelize. Having one agent control another and verify its results against rules you set has worked well for me because the controlling agent has no incentive to cut corners, and the implementor might, but it is being controlled.
My usage might be much simpler than what you do, but it went from "but I gave a list of things to do, you only did 5 of them" - "okay, here are the other 7, oh btw, I skipped the verification rule because nobody has time for that" to good compliance, the orchestrator starts the sub agents, tells them exactly one thing to do, and makes sure they've done it afterwards.
makes sense on planning as well, I think. spend your tokens on the best model to explore the problem and design the solution, but the implementation and testing/verification cycles don't need the strongest model you can get.