"Always implement things when you actually need them, never when you just foresee that you need them."
YAGNI is a principle behind the XP practice of "doing the simplest thing that could possibly work". It is meant to be used in combination with several other practices, such as continuous refactoring, continuous automated unit testing and continuous integration.
Used without continuous refactoring it would lead to messy code and massive rework. Continuous refactoring in turn relies on automated unit tests as a safety net and continuous integration to prevent integration problems.
YAGNI is not universally accepted as a valid principle, even in combination with the supporting practices. The need for combining it with the supporting practices, rather than using it standalone, is part of the original definition of XP.
It was never claimed that standalone YAGNI was a good idea.
According to those who advocate the YAGNI approach, not following YAGNI may lead to following disadvantages:
The time spent is taken from adding, testing or improving necessary functionality.
The new features must be debugged, documented, and supported.
Any new feature imposes constraints on what can be done in the future, so an unnecessary feature may preclude needed features from being added in the future.
Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work correctly, even if it eventually is needed.
It leads to code bloat; the software becomes larger and more complicated.
Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards feature creep.