Strong junior programmers usually fail by rewriting everything from scratch, having no concept of DRY, libraries, or how to effectively break logic into methods. But inability to generate their own code is not a common failure mode!
It's only weak junior programmers (that is, people who simply are not going to become strong developers) who approach a problem and, in the absence of the ability to write code from scratch, try to find something to copy-paste.
This has been my experience too. It's also common (maybe even nearly universal) for devs to go thru a stage where "rewiting" feels like the path of least resistance. This is usually (not always) wrong, but until you've ramped up in several very different codebases it's difficult to see how something so foreign can end up being as productive as what you're used to.
It's messier than simply that too. Even though I may be the inferior coder to them, I am not necessarily without any capacity to reason and improve on something.
So what happens is I pick something up that someone else wrote, and I see things I think should be done differently, and much of that is probably perfectly true and correct, as far as it goes.
But also, even while some of my ideas were correct and better than what's in there, at the same time it's also true (ends up turning out to have been true, but I only recognize it later) that much of what I didn't like and ripped out and re-wrote, was actually just me not actually grasping the thoery of operation of the original code.
My new replacement may still work and may even look more organized or more easy to follow, but turns out not to handle some edge cases the original code not only handled, but did so in some elegant trick way that isn't obvious from reading it, but ends up handling more conditions in fewer lines, fewer cpu ops, fewer memory ops, fewer db/net calls, etc.
I live with myself by deciding it's good enough that I at least recognize this process and am generally improving day by day. That has to be all anyone can really expect.
I'd also wouldn't frown on just calling them developer. They just need a senior developer to tell them not to rewrite everything.
Anyway, regardless of whether they're really strong or not, the couple I've mentored have become tremendously valuable to my company, with performance outstripping my own (I think because of the higher tolerance to shitty repetitive frontend work).
Sure, technically you are a Junior again if you use a new technology, but assuming the MO of the language is not completely unlike one you're familiar with (for example OOP vs functional vs whatever).
I mean, at least that's what I need to do - but maybe "how was this syntax again?" paired with "I don't like these docs" might only superficially be copy/pasting from SO, because you know what you're writing, but you don't have the words of the language...
In my opinion the way to get them through it is loads of pair programming and stopping them and reminding them they haven't stopped to think about the entire context when you catch them doing it (or when they come to ask for help in the ideal case).
I'm not sure if I ever went through this phase, but not everyone has the luxury of developing their programming skills at a leisurely pace from highschool all the way through college.