If we interpret this question in its most general sense, the proposed duplicate question has perhaps the best answer you could ever get:
Too often when you try to design for the future, your predictions
about future needs turn out to be wrong. It's usually better to
refactor when you actually know how the needs have changed than to
overdesign your system on day one. At the same time, don't shoot
yourself in the foot, either. There's certainly a middle ground, and
knowing where that is is more art than science.
To boil it down to one rule of thumb: less is more.
But we can expand on this a bit. There's a big difference between trying to predict the future, and actually knowing the future.
It is important for developers to be aware of the long-term vision of the product because once in a while, you really do know for sure that you will need to do X at some point in the future. For instance, I know that our application will have to support color themes someday, so I try to avoid relying on the current default color values as much as possible. But I haven't written any code to change the default colors, because we won't need it for a very long time, and I have no idea how exactly we'll want it to work. We also knew from the start that our application would need internationalization, so we (mostly) kept user-facing strings and "code-only" strings clearly separated from day one, even when we didn't have a system for translating the user-facing ones yet.
In your example, it's not clear whether dealing with an array instead of a single number would result in you writing additional code you don't need yet, or just slightly different code. It's also not clear whether you know you'll need this in the future or if you're just guessing. Only you and your product manager can answer that. If the odds are high that you will need arrays, and using arrays doesn't make the code significantly more complicated right now, then it's probably a good idea to start using arrays early.
The only time it might be worth trying to predict the future and be more generic than necessary is when you're designing an API, schema or file format that needs to be backwards compatible. For example, if you have a web service API with a method getPublicUserStats(), making it only accept a single user id instead of an array is needlessly restrictive, even if you only need one at a time right now. But you shouldn't go out of your way to optimize for requests with a thousand user ids until you actually have a performance issue.