Ontem, ao conversar com um amigo, surgiu um fenómeno: ele mantém uma biblioteca de código aberto que, nos últimos três meses, duplicou o número de PRs, mas o tempo que dedica à revisão diminuiu.

Não é por preguiça, mas porque realmente não consegue acompanhar, e muitas PRs parecem ter sido geradas por IA, com lógica coerente, mas há algo que não parece certo.
Ele disse uma frase que me ficou na cabeça: “Agora, quem envia o código não precisa de assumir as consequências, mas quem faz a fusão tem que.”
Essa frase aponta para a questão central: no trabalho colaborativo de código aberto, o risco entre contribuidores e revisores é assimétrico.
Quem envia o PR pode cometer erros, prejudicando a reputação do projeto e gastando tempo a corrigir bugs mais tarde; enquanto o revisor, mesmo trabalhando de forma voluntária e exaustiva, não recebe qualquer compensação.
Essa assimetria é ampliada na era da codificação por IA, onde gerar código é fácil, mas validar o código continua a ser difícil.
O MergeProof pretende resolver exatamente essa assimetria.
Ele permite que o contribuinte, ao submeter um PR, aposte uma quantia de dinheiro, indicando “Acredito que este código está bom”, e, se o revisor encontrar vulnerabilidades, a aposta vira recompensa; se ninguém encontrar, o dinheiro é devolvido. Simples assim.
Por trás da simplicidade, há uma mudança fundamental: a revisão de código passa de uma “ação altruísta baseada na reputação” para uma “ação econômica baseada em incentivos”.
Você não pode contar com a boa vontade dos outros para revisar; basta apostar na sua própria contribuição, e naturalmente alguém verificará para obter lucro.
Quanto mais penso nisso, mais vejo que essa pode ser a base que falta na colaboração de código aberto.
Atualmente, todos dizem que o Web3 deve introduzir incentivos econômicos em vários cenários, e o MergeProof escolheu um ponto muito preciso: não inventa um novo processo, apenas adiciona um mecanismo de jogo ao processo existente.
Contribuidores podem demonstrar sua confiança, revisores podem monetizar seu tempo, e os projetos podem obter códigos de maior qualidade — todos saem ganhando.
Além disso, é especialmente relevante neste momento de explosão de codificação por IA, quando o volume de código começa a crescer exponencialmente e o espírito voluntário já não basta para sustentar a revisão; incentivos econômicos podem ser a única solução escalável.
Tenho a sensação de que, com o tempo, isso pode mudar a forma como colaboramos em software.
Pelo menos, fez-me pensar numa questão: se eu realmente confio no código que escrevi, teria coragem de apostar?