Ce n'est pas ce que j'ai dit, tu n'as pas besoin de savoir ce qui se cache derrière une interface si elle est bien conçue (ou si elle respecte au moins une partie de la petite dizaine de règles "d'usage").
Après on a pas de projets qui font des millions de LoC en Haskell (principalement par ce que le langage n'est pas assez verbeux pour y arriver), mais c'est faisable relativement automatiquement.

Sauf que c'est pas à la lecture de la doc d'interface que tu sais si ce qu'il y a derrière est bien conçu...
Donc pour éviter les ouvertures de rapport d'anomalie en série (surtout que ça prend du temps de trouver quelle équipe est fautive...) le plus simple reste de faire tes contrôles avant l'interface.
Et donc tu as des chances de dupliquer du code entre le tien et celui de la couche que tu attaques.

Je plussoie sur ce point. Une maxime très connue en réseau et qui s'applique dans ce cas là également:
"Be conservative in what you send, be liberal in what you accept".

Sur la libc notamment on peut linker avec des implémentations très différentes, on ne peut pas prévoir ce qu'elles accepteront ou non (dont certaines fonctionnalités non-implémentées). Il faut prévoir le maximum de choses, y compris des écarts par rapport à la spec.

Même sans parler d'écarts avec la spéc tu as de manière tout un tas d'implémentations qui ne sont pas sous forme de spec.
Pour des systèmes parallèles par exemple tu peux avoir des enchaînements de commande dont le temps entre chaque commande peut provoquer un crash ou un retour d'erreur.
S'il faut spécifier chaque temps minimum entre chaque commande je plains les pauvres qui codent ce système...