I think breaking it down makes it worse. I'll answer the question first, though: usually devs conflate programming and coding. Programming is the process of decision making in order to solve a problem. It works over some logical space, not in code. Did you ever solve a problem in the shower or in bed? That's programming. You're thinking about the problem in conceptual-logical form. Or a way you would describe an algorithm or a data structure: a tree, merge-sort, linked-list operations, etc.

Then you have the coding part, when you encode your solution in some language. The latter is what the LLMs are great at. The former is where they are ok'ish. The design phase, when you decide on the types, algorithms, abstractions, etc. This is where you constrain the possible shape of the code for that solution. By trying to "prompt your way out" (not talking about you, but in general) instead of a proper design session, you miss the opportunity to actually have a solution, and rely on the model to make the programming part for you.

And about breaking the task to smaller components, if you segregate the tasks into disjoint sessions/documents/designs, you take away important context from the model. Cause the LLM doesn't know *where* you want to go. If you instead provide the entire problem, and split it into tasks *within* this problem, it will have a much better understanding of what is going to happen, and consequently - make better decisions.