One thing I've noticed when working with others while coding with agents is that many people are still working at too low of a level by default.
Obviously if you're telling it line by line what to type (and no one is -- this is a straw man), you're not getting the value out of the LLM that you could be.
The next level up is specifiying technical solutions in detail, eg "Create a model and a controller for retrieving rows from the widget table". This is a common level for many people that have been burnt by older less-effective models. It's a waste because the agent knows how to build out CRUD endpoints for any web framework under the sun. Or if it doesn't, it can just follow examples in your codebase. It's extremely good at this now.
An improved level that I see people default to frequently is describing properties of their system like Create an api endpoint GET /api/widget/234 that gets widgets. This is definitely an improvement, but it's still not as high level as we can get: nothing changes in the world when this endpoint exists. Backends need frontends to create full products. The example I've given here can still be absolutely crushed by the agent in most cases. You may still be at too low of a level.
A further improvement level is when you're coding agentically across all the necessary services in a way that is user-facing or product-oriented. eg "Create an orders page to show orders" that is run on a mono-repo or in a parent folder holding all the necessary repos. More often you're describing real user value instead of parts of the system.
It's worth noting that this is the lowest level that non-programmers will be operating at, so if non-programmers are blowing you away in productivity, now you know why. You're being silly if you let that happen!
And there are more levels even further outside! Instead of giving it a spec, you can give it a problem to solve and have it write its own spec (There are lots of tools for this like openspec or spec-kit). Or instead of giving it a problem to solve, you could just ask "what should we do next?"
I generally pick the highest level of abstraction that I think it can pull off. That's going to get you the biggest bang-for-the-buck when it works. The one where we're just supplying product specifications works extremely well today if your codebase doesn't suck.
In the end, it may not always do what you want. When it does something you don't like, you can throw it away and restart or iterate with it to where you want to go. But these new frontier models are so much better than previous models that it's worth a shot at trying something at a higher level or even without so much detail. And sometimes it has a better idea than the one you were going to specify which for me is just pure magic.
I would strongly consider being more ambitious if you're working at one of the lower levels here. And if it fails at a higher level, think about how you could make it work (eg skills, prompts, agents, documentation, etc) if you were to give it another shot. I realize that with previous models you needed to specify the hell out of everything, but the technology has changed considerably in the last 3-4 months. Try dropping to a lower level only after you've proven that the higher level won't work.
I also think the exact technical details of the solution matters a lot less now that you can refactor to what you want cheaply and easily as well, whenever you want. As long as you have the functionality, the performance, the UX, etc that you need, the exact code isn't all that important. I know that's going to blow a lot of minds, but I do encourage you to consider it.
If you're one of those people that's been using the agent for everything, but you don't feel like you're able to get the productivity gains that other people are seeing it could be that still working too far down into the details. The more ambitious you are, the more agentic you are.