Botei o Jev para trabalhar: caçando golpe de Pix com Rust contra Python
Eu passei os últimos dois textos aqui do blog falando do Jev na teoria. Escrevi o que ele é, escrevi onde eu colocaria ele para trabalhar, e fechei o primeiro deles avisando que os números eram alegação de fabricante até alguém medir. Pois então. Eu medi.
Montei um detector de golpe de Pix rodando em tela dividida. Do lado esquerdo, Rust com Jev. Do lado direito, Python com DeepSeek. As mesmas mensagens entrando nos dois ao mesmo tempo, cada lado decidindo sozinho se aquilo ali é golpe, montando o grafo das contas e rastreando o dinheiro até a conta de saque.
O corredor rápido e o bastão
Antes dos números, guarda esta imagem, porque é ela que explica o resultado inteiro.
Pensa numa prova de revezamento. O Jev é o primeiro corredor, e ele é rápido de doer: recebe a mensagem, entende o contexto todo e devolve a decisão. Só que ele não termina a prova sozinho. Ele passa o bastão para a linguagem de programação, que é quem vai varrer o grafo de contas e perseguir o dinheiro.
De nada adianta ter um monstro na primeira perna se o segundo corredor arrasta o pé. O tempo total é dos dois, não de um. Foi exatamente isso que eu quis medir, e por isso a comparação não é Jev contra DeepSeek, é dupla contra dupla.
O que entrou na máquina
A base tem 10 milhões de transações e 1 milhão de contas. Por cima disso, 1.000 mensagens de WhatsApp, e dentro delas eu plantei 75 golpes. O trabalho de cada lado é o mesmo: achar os 75 e mostrar o caminho do dinheiro.
Antes de qualquer mensagem entrar, a primeira diferença já aparece na tela, e ela não tem nada a ver com modelo nenhum. Para carregar esses dados na memória, o Rust gastou 128,9 MB. O Python gastou 1,6 GB. Mais de doze vezes, só para segurar a mesma coisa.
A mesma mensagem, os dois lados
Repara na mensagem número 12, que é a que eu abro no vídeo. É aquele clássico: 'Sua conta de luz está para corte HOJE. Pague R$ 2286,46 via Pix e evite a suspensão do fornecimento.'
Os dois cravaram golpe. O Jev deu 95% de probabilidade e classificou como 'Boleto falso'. O DeepSeek deu 98% e classificou como 'Falsa central do banco'. Note que eles concordaram na decisão e discordaram no rótulo, o que é um detalhe interessante e que merece texto próprio outro dia.
A diferença que interessa aqui está embaixo do rótulo. O Jev decidiu em 345,1 ms e o Rust rastreou o dinheiro em 27,4 ms. Do outro lado, o DeepSeek decidiu em 955 ms e o Python rastreou em 300,4 ms. Naquela única mensagem, a segunda perna do revezamento custou onze vezes mais tempo do lado do Python.
O placar das 1.000 mensagens
Terminada a corrida inteira, o relatório fica assim:
| Rust + Jev | Python + DeepSeek | |
|---|---|---|
| Tempo total | 307,6 s | 1.047,4 s |
| Decisão do modelo (p50) | 298,6 ms | 1.027,3 ms |
| Rastreio da linguagem (p50) | 25 ms | 243 ms |
| Golpes detectados | 74 de 75 | 75 de 75 |
| Custo | US$ 0,025684 | US$ 0,106530 |
| Memória | 128,9 MB | 1,6 GB |
Olha o p50 com carinho, que é onde a metáfora do revezamento se paga. Na perna do modelo, o Jev é pouco mais de três vezes mais rápido. Na perna da linguagem, o Rust é quase dez vezes mais rápido. As duas vantagens se somam, e é por isso que 307 segundos viram 1.047 do outro lado.
Deu para entender por que eu não testei o Jev com Python? Se eu tivesse feito isso, a decisão rápida do modelo ia ficar esperando a linguagem terminar de rastrear. O corredor bom entrega o bastão e vê o outro andando.
Onde o lado lento ganhou
E ganhou mesmo, não vou esconder. Dos 75 golpes plantados, o Rust com Jev achou 74. O Python com DeepSeek achou os 75.
Um a menos parece pouco, e num teste de bancada é pouco mesmo. Agora pensa nesse um dentro de um banco de verdade, rodando milhões de mensagens por dia. Aquele um vira gente perdendo dinheiro. Esse é o tipo de número que você não resolve trocando de linguagem, e sim ajustando o modelo para a sua base.
Sobre o custo, a mesma honestidade: o valor do lado do Jev é medido, o do DeepSeek a aplicação marca como estimado. Trate como cerca de quatro vezes mais caro, não como quatro vírgula alguma coisa.
E a ressalva maior, a mesma que eu faria se o número fosse de outra pessoa: isso é uma rodada, na minha máquina, com processamento linear. Eu não abri thread nenhuma de propósito, justamente para comparar as duas duplas no mesmo ritmo. Se eu abrisse quatro ou cinco threads, os dois lados melhorariam, e a proporção entre eles é que ia ser a pergunta boa.
A aplicação inteira nasceu de um prompt
Essa parte talvez seja a que mais te interessa na prática: eu não escrevi essa aplicação na mão.
Usei o Reversa New no modo expresso, que é o agente que constrói projeto do zero, ao contrário do Reversa que você já conhece, que faz o caminho inverso e documenta o que já existe. Descrevi num prompt o que eu queria, a tela dividida, os dois backends, o grafo das contas em memória, onde estavam os arquivos de dados, e mandei rodar. Ele executou as oito etapas sem parar e entregou as specs prontas.
Depois foi só chamar o Reversa Forward, que é quem programa de verdade. Ele escreveu o backend em Rust, escreveu o backend em Python e montou a página que conversa com os dois. Subiu em localhost:8080 e funcionou do jeito que estava escrito na spec.
Para software grande eu continuo recomendando o modo guiado, onde você discute cada detalhe antes. O expresso serve para o que é pequeno e bem definido, como foi esse caso.
Se você quer entender esse fluxo de especificar primeiro e deixar o agente construir depois, é disso que trata o livro do Reversa.