My experience tells me otherwise. While I agree, that features should not be added just "for the future", it is important to recognize many exceptions to that:

- it is good if a new capability comes with the new feature. For example, if lets say attachments are needed in some place, think of how it could be a capability so adding the same feature in another place of the system will be simple. Note, that having a habit of this will not add development efforts at all.

- problem domain can clearly guide what the system will possibly need. Thus for a startup aiming at world domination it may be myopic not to think of localization. Certain thing go together very closely and it's wise to get the foundation right. In software it's easy to keep enhancement possibilities open without cost / speed of development implications. For example, use enum instead of specifically named boolean even; have a concept of currency if the application deals with money, etc.

- there are certain aspects, which better to be thought of early. It may very well be that in the beginning it's easy to imaging that everything can be refactored. In reality it's rarely the case. For example, logging can be very important to figure out problems. The requirement for logging may be not in the specs, but wise developers still do it, because they know it's not YAGNI.

My advice is to learn getting things right from the start. It does not mean implement everything, but it means develop software development approach, which sports adequate level of abstraction. It's easy to find developers to implement 2+2 daily. It's harder to develop a habit to develop X+Y as easily. YAGNI is only good as part of the balance, not as an ultimate rule.

If pressed, at least try to keep ways open in the software architecture. It's easier to do thinking one or two levels of abstraction above the task at hand and especially useful with greenfield projects.