I build with coding agents every day, and I give them real work: research, design options, features, refactors, debugging, tests. I still drive the product decisions and design, and I check that the result solves the user's problem without getting in their way.
An agent will happily produce something that runs and is still wrong for the person using it. One of my jobs is catching that gap: the feature that technically matches the ticket but makes the flow worse, or the fix that papers over the actual bug. Some damage doesn't show up in the product at all. A fix can work perfectly and still degrade the architecture, which you only pay for months later, when a requirement changes and the update is suddenly risky, slow, and expensive.
Working this way creates its own problems. Code shows up faster than it can be read carefully, and the pull is always to skim it and fire off another agent before anyone has understood what the last one did or what it was working from. Most of my setup is aimed at that problem:
Sharper specs, cut into smaller pieces
Deliberate limits on how much context an agent carries
A review pass separate from the person who asked for the work
Tests and recordings that catch what a quick read won't
The scaffolding matters more to the output than the choice of model. The list keeps growing the same way: whenever my own attention becomes the bottleneck, I try to turn that step into something an agent can run.
On Buttermade, a few of those look like this: