For me, I never liked the "coding" part as much as I like the "seeing the results" part and the "showing people" part. So, not doing all the coding, in so far as it allows more of the latter, makes me _more_ happy.
For me, the spec format matters way less than the routing. You can have perfect definitions, but if your agents don't know their boundaries or who handles what, you get chaos. I now think in terms of an "org chart" for agents.
Mine have burned a lot of money! Right now, I'm trying to keep the context smaller. It takes a lot of discipline, though, to have a system that gives enough context to do the work but not so much the agent can go off doing new/crazy stuff.
I don't look at much code in my own work anymore. Sometimes, I'm just lazy. But mostly, I trust but verify. I spent a lot of months looking at every line, hand-editing, etc. I built a fair bit of trust. I learned the best way to assign tasks and structure the work. Beyond that, I definitely keep the architecture for myself. And I do believe that prior manual fluency is a requirement for being this hands off.
Not all efficiency is good. Sometimes, programming is more art than science. And for the art side, I find that thinking and struggling is useful and satisfying in a human way.
You found an interesting example of the fallacy of following and defining rules You can't define a system with only rules. Eventually, you run out of rules on how to apply the rules. Eventually, you need judgment and interpretation.