Often people don’t think through the comparative cost of building now to building later. One approach I use when mentoring developers in this situation is to ask them to imagine any refactoring they would have to do later to introduce the capability when it’s needed. Often that thought experiment is enough to convince them that it won’t be significantly more expensive to add it later. Another result from such an imagining is to add something that’s easy to do now, adds minimal complexity, yet significantly reduces the later cost. Using lookup tables for error messages rather than inline literals are an example that are simple yet make later translations easier to support.

Unfortunately, in my experience, YAGNI is often used to rationalise not considering the future in design. I’m not sure what can actually be done about it since words can be coopted for anything and giving a more acceptable definition is unlikely to push someone to rethink how they use it.