> Quite a lot of changing the code is just useless busywork: re-wiring old functions, moving imports around, searching for locations that benefit from extracting a common piece of code.
If other people are dissatisfied with LLM output quality while it seems to work fine for you, you might want to consider that the quality of code you produce is closer to the quality of code the LLM produces than what those other people are producing.
What you posted there, for example, about most of changing code being busy work is a pretty big red flag for a codebase. One of those "large structure" things that you're supposed to be paying attention to is the architecture of the code. There's always the chance that some change you need to do goes against the grain of the solution you architected, and you need to make changes all across your codebase to fit it in, but in general the point of modularity and good architecture is that when you make a change you just have to make that one change, ideally just changing the logic of the one responsible function with only minor changes required anywhere else in the codebase. If you're consistently having to hunt throughout the code for related functions that you need to rewire that's a sign that your architecture does not fit with the direction your codebase is evolving, or alternatively that you don't have much of an architecture to begin with and your code is highly interconnected.
Actually one habit you mention at the end of that quote can worsen this issue: "searching for locations that benefit from extracting a common piece of code". Tautologically this is a good thing as you define it as only working on locations that will benefit, but given the frequent need for rewiring of functions I would hazard to guess that you've "deduplicated" code a bit overzealously. Just because two functions share some common code does not necessarily mean it is appropriate to pull that out into a function. Deduplicating is good if conceptually the code is a single thing that you would always want to keep in sync, as it means that when you need to make a change to it you don't have to hunt down all the places it's used. On the other hand, if you find yourself frequently needing to delve in to these functions to rework them because you need to make a change to how it's used by just one caller, your "deduplication" has added to your workload, and probably created some overcomplicated code in the function that is in reality handling multiple distinct needs.
I hope this doesn't come across as too condescending, and if I've just wasted your time explaining principles you already understand I apologize. I don't know you or the code you're working on so I can't exactly confidently judge your work solely on a few paragraphs. It's just that your mention of how your experience of coding has been different from what others have described, and specifically that, for you, writing has been the bottleneck rather than understanding, combined with the specific issues you describe facing, imply to me that you may not realize that the approach you are taking to producing code yourself may be significantly different from how other Software Engineers are producing code, and that may account for some of the differences you note in your personal experiences programming.