The idea should be that it probably will change, and to prepare for that you need to code it a way that if it does change, you have to update the code only in one or two places, you haven't scattered the knowledge of that detail all over the code.
If you overdo that, you end up with more abstraction than is helpful, which will hurt your ability to refactor as well. When I was younger, I've done a lot of abstractions because doing abstractions was cool. Now as I'm older and wiser, I only add interfaces if it's really needed. Even if I know that there will be some abstraction coming in the future, I felt it more helpful to add the abstraction only right before implementing the second use case for it, because then I have thought a lot about how the second use case is to be implemented.
I think an important skill you pick up after a couple decades is to know the difference between “this is likely to change” and “my gut says what-if-it-changes but my experience tells me YAGNI”
My general approach is to write my code in a way that could easily be turned into an interface once a second or third implementation needs to be introduced and hope a junior doesn’t come along and fuck it up in the meantime. I think one reason people go to the abstract interface early (when there is only one impl) is that they see it as a guard against someone else coming along and changing the well thought out layering. But it doesn’t work and just makes things harder to read and work with.
