Il existe une dissonance persistante dans le développement logiciel :

Les personnes qui écrivent le code assument les résultats, tandis que celles qui examinent le code n’en supportent pas les conséquences.
Cette structure n’est pas problématique lorsque l’échelle est petite, mais elle tend à s’amplifier dans des systèmes complexes.
Dans des plateformes comme GitHub, on peut observer que de nombreux codes problématiques entrent dans la branche principale après avoir été « approuvés ».
MergeProof tente de corriger cela.
Grâce à un mécanisme où les examinateurs doivent également assumer les résultats :
• Participer à la revue nécessite un engagement (staking)
• Une revue correcte peut apporter des bénéfices
• Une erreur de revue peut entraîner des pertes
Cela transforme l’« approbation » d’un acte léger en une décision nécessitant un jugement.
Dans le contexte actuel du codage avec Vibe, cette adaptation a une signification concrète.
Avec des outils comme Cursor réduisant la barrière au développement, la volatilité de la qualité du code augmente.
Ce dont le système a besoin, ce n’est pas seulement plus de code, mais un mécanisme de filtrage plus fiable.
MergeProof offre une amélioration structurelle.
Il transfère, par des contraintes économiques, la problématique de la qualité du code du « niveau culturel » au « niveau mécanisme ».
Ce transfert pourrait redéfinir la façon dont les équipes construisent des logiciels.