I can really only describe my personal experience adequately vs the X hype, though there are enough influential/experienced devs out there who aren't part of the LLM industry who are saying they are having great success that I have to think that, that amount of smoke must mean fire.
Some background, I'm a "working manager" in that I have some IC responsibilities as well as my management duties, and I'm pretty good at written communication of requirements and expectations. I've also spent a number of years, reading more code than I write, and have a pretty high tolerance for code review at this point. Finally, I'm comfortable with the shift from my value being what I create, to what I help others create.
TLDR: Agentic coding is working very well for me, and allows me to automate things I would have never spent the time on before, and to build things that the team doesn't really have time to build.
Personally, I started testing the waters seriously with agentic coding last June, and it took probably 1-2 months of explicitly only using it with the goal of figuring out how to use it well. Over that time, I went from a high success rate on simple tasks, but mid-to-low success rate on complex tasks to generally a high success rate overall. That said, my process evolved a LOT. I went from simple prompts that lacked context, to large prompts that had a ton of context where I was trying to one-shot the results, to simple prompts, with a lot of questions and answers to build a prompt to build a plan to execute on.
My current process is basically, state a goal or a current problem, and ask for questions to clarify requirements and the goal. Work through those questions and answers which often makes me examine my assumptions, and tweak my overall goal. Eventually have enough clarity to have the agent generate a prompt to build a plan.
Clear out context and feed in that prompt, and have it ask additional questions if I have a strong feeling about direction and what I would personally build, if there's still some uncertainty that usually means I don't understand the space well enough to get a good plan, so I have it build instead with the intention of learning through building and throwing it away once I have more clarity.
Once we have a plan, have the agent break it down into prioritized user stories with individual tasks, tests, and implementation details. Read through those user stories to get a good idea of how I think I would build it so I have a good mental model for my expectations.
Clear out context and have the agent read in the user stories and start implementing. Early on in the implementation, I'll read 100% of the code generated to understand the foundation it's building. I'll often learn a few things, tweak the user stories and implementation plans, delete the generated code and try again. Once I have a solid foundation, I stop reading all the code, and start skimming the boilerplate code and focus only on the business rules / high complexity code.
I focus heavily on strong barriers between modules, and keeping things as stupidly simple as I can get away with. This helps the models produce good results because it requires less context.
Different models prompt differently. While the Opus/Sonnet family of models drive me nuts with their "personality", I'm generally better at getting good results out of them. The GPT series of models, I like the personality more, but kinda suck at getting good results out of them at this point. It takes some time to develop good intuition about how to prompt different models well. Some require more steering as to which files/directories to look in, others are great at discovering context on their own.
If the agent is going down a wrong path, it's usually better to clear context and reset than to try and steer your way out of screwed up context.
Get comfortable throwing away code, you'll get better results if you don't think of the generated code as precious.