Verifying is the only way to be sure. Going by text (that no one is following in the same way) results in wasted dev time. In the end, actual verification will be needed anyway.
Discussion
Fr. There is no traceability between NIPs and code because one group of people controls the NIPs and a different, sometimes overlapping, group of people controls the code.
Just look at the hot mess that is AUTH. If I opened a PR that attempted to fix that, it would never get merged. Everyone arriving new would go with the merged version, quickly realize it doesn't really work well, and then come up with variant #1946, which is incompatible with some of the other variants. And then maybe join me by also submitting a PR. Everyone can submit a PR, hardly anyone can merge, so the specs just rot and the PRs pile up.
I didn't meant that verification is not needed. What I mean is that instead of relying on the code from each client/relay introducing new NIP as a reference implementation, developer first define what they are imolementing and leaving reasoning of their decisions, and then implementing it.
We do that, but that has nothing to do with NIPs or GitHub. We write it on Nostr.
NIPs are only the ID numbers that you get assigned, if the NIPs repo merges your spec on GitHub. Otherwise, you have to devise your own numbering system (we use "NKBIP", instead of "NIP") and find some other place to store it.