Vibe coding para automação bancária: a Porto caiu no parser da XP

Em vibe coding para automação bancária, casar o banco por um pedaço de texto passa no primeiro aviso e erra no segundo. A notificação da Porto Seguro caiu no parser da XP porque a palavra experiência contém xp. A transação não foi salva só porque o texto falava de fatura, não de compra.

gbrl808 apresentava a live. O caso deste post é o outro builder na call, o que lê notificação de banco no Android. Foi na mesma live em que o anfitrião usou o Antigravity para mesclar o PRD e decidir o MVP. Aqui a mesa é outra: o parser que decide de qual banco veio o aviso.

O package do Inter e o atalho do contém XP

O outro builder já conhecia o package name. No Android cada aplicativo tem um só. Se o package bate com o do Inter, a notificação é do Inter. Ele tinha uma classe parser por banco: Bradesco, Inter, Itaú, XP.

A primeira rede que ele colocou no caso da XP não foi o package inteiro. Foi um pedaço de texto. Se o texto contém XP, devolve a classe do parser da XP. Esse parser lê título e texto e tenta ver se a notificação é compra de cartão.

Ele sabe que o package pode mudar e o casamento quebra. Mesmo com essa ressalva, a peneira que estava ligada no dia era a substring. Qualquer aviso que carregue as letras xp nesse pedaço entra no parser da XP.

A fatura da Porto entrou no parser da XP

O aviso do dia não era uma compra. Era o fechamento de uma fatura.

hoje já chegou uma notificação que minha fatura do cartão porto tinha sido fechada. Só que o package do Porto Seguro é Porto Seguro é experiência cliente. E dentro da palavra experiência tem XP

O package da Porto é experiência cliente. Experiência contém xp. A notificação foi parar no parser da XP, o parser de outro banco.

ela não salvou como uma transação, porque depois que entrou lá na classe do parcer do XP, eh, o texto que tava vindo era a fatura do seu cartão e tal. Então, tipo, não tinha a palavra compra

A segunda rede segurou. O texto era a fatura do cartão, sem a palavra compra. Nada gravado como transação. O falso positivo aconteceu. O dano de dado não chegou a entrar, porque a palavra compra faltou.

O vibe coding para automação bancária precisa de mais de 1 sinal

Um agente de vibe coding escreve o "texto contém XP" em minutos e o primeiro teste com o Inter passa. O caso da Porto é o que esse prompt não prevê: uma palavra do package de outro banco carrega o mesmo pedaço.

Ele não trata 1 sinal como suficiente. Cruzar o package da XP com a frase compra efetuada no texto ajuda, e ainda assim "não dá muito para tomar como garantia". A hipótese que ele deixa na mesa é juntar os sinais.

fazendo um híbrido de tudo, eu acho que deve dar para no geral fazer dar certo

Os sinais que aparecem na conversa são 3. O package inteiro, não um pedaço dele. As palavras da compra, não só o nome do banco. Os últimos 4 dígitos do cartão, que a maior parte dos aplicativos de banco mostra na notificação de compra. Ele pensou em pedir esses 4 números ao usuário. Alguém acharia ruim. Quem não achar consegue usar.

O híbrido e os 4 dígitos foram falados. Nesta cena o parser novo não foi ao ar. O que a live prova é o furo e a rede que segurou: a substring xp errou o banco, a palavra compra impediu gravar.

Rode o aviso que não é compra

Se o seu agente for escrever um roteador de notificação de banco, não aceite contém xp como identidade do banco. Peça o package inteiro. Peça 2 palavras da compra, não 1. Se for usar os 4 dígitos, deixe o usuário entregar, e trate quem não entregar como fora do fluxo.

Rode o caso que não é compra. Uma fatura. Um aviso de limite. Um experiência cliente de outro emissor. Se o parser da XP acender aí, o atalho ainda está no código.

Dá para assistir à live e ouvir o momento em que a Porto entra no parser da XP. Quem faz vibe coding nesse tipo de automação precisa do caso sujo, não só do Inter que casa limpo.