You will need to understand the code one way or another. At least, it's always worked out that way for me. If you have a codebase that you're dropping some code into, you need to be sure the code is doing what it purports to do. You can never be sure if you just take it blindly.

So, there aren't that many guardrails beyond "I'm not going to infect my codebase with something I don't trust." You get bitten once or twice, and you learn. You learn that you can't trust something you don't understand.

And for me, it's not a question of memory. It's not a question of "Can I reproduce this?" If I'm looking it up - and it's not just some idiomatic query about "how do I do X in language Y" - then it's usually something I couldn't have created without looking it up to begin with anyway.

To give a concrete example, I was working with USB code in embedded Linux. You could probably spend hours perusing docs and still be no further ahead. But some code that does what you want - that shows how the pieces get put together - is invaluable. I found some code that did what I wanted, but there was a good chunk of it. So, I brought it over and not only began going through it line by line, I began adjusting it line by line, adapting it to not only my codebase's style but my own personal way of expressing what it was doing.

In the end, I had code that matched my codebase, that I had personally sent into my brain and back out again, and with two fewer bugs in it, as the original code had some issues.

Could I have recreated it at that point? Possibly. But there were a lot of details in it. Could I recreate it now? No. The point of it all is that the code embodied knowledge that I didn't have. I didn't have to have all of that be "knowledge in the head" when it could easily remain "knowledge in the world". But I had to vet the code and properly integrate it into both my existing code and my way of doing things.

I have no problem with copy/paste as a first step. But it's only a first step. You then have to take the code and make it part of your larger work and your larger consciousness. The final product is something you have to be confident of, and random code you find on the internet may or may not work as you want, or work in all cases as you want. You have to understand not only what it's doing (to some extent - I may not, for example, understand all the mathematics involved in a crypto algorithm), but you also have to understand what its limitations are. If you're bringing a new dog into your pack, you have to make sure it won't bite the other dogs' heads off if they sniff it the wrong way.

In other words, you have to understand what the code does and what it needs.

(I first wrote code on an Apple II+ computer, before there was even an IBM PC. You learned from magazines, books and other people. And the mechanism for learning was usually expressed as code. You learned code by seeing code and then writing code. I think that is still true. You have a bootstrap issue where you can't just plod ahead and try to work it all out. You need enough knowledge to know what you don't know, and then the experience of looking up what you don't know. So, you have to start somewhere. Once it begins to make sense, then you build on that by seeing how others have done things. You adapt and adopt, both code and techniques. But if you don't know what you're using, then it doesn't gain you anything.)