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 to make sure it solves the user's problem in a way that is both frictionless and delightful to use. 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, the fix that papers over the actual bug. And 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, smaller pieces, deliberate limits on how much context an agent carries, a review pass separate from the person who asked for the work, and tests and recordings that catch what a quick read won't. The scaffolding matters more to the output than the choice of model, and 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.