Vibe coding matou o CRM? Não, mas mudou a conversa que eu tenho com cliente
CEOs estão cancelando contrato de Salesforce depois de vibe-codar um CRM em duas semanas. Antes de comemorar ou entrar em pânico, vale entender onde isso realmente se sustenta
Fred Turner cancelou US$ 600 mil de contrato Salesforce depois de vibe-codar um CRM interno. Casos como esse viralizaram, mas escondem uma distinção importante: o que funciona para 50 pessoas quebra em escala. Aqui está minha leitura de arquiteto sobre onde essa história é real e onde é ilusão de curto prazo.
Nas últimas semanas apareceram vários relatos parecidos: um CEO vibe-codou um CRM em um fim de semana, cancelou o contrato com a Salesforce e está "funcionando melhor". O caso mais comentado é o de Fred Turner, da Curative, uma seguradora de saúde, que cancelou US$ 600 mil em contrato Salesforce depois de construir um CRM interno em dois meses. Ele próprio admite que a manutenção é "um dos pedaços mais desafiadores", mas argumenta que valeu a pena.
Tem também o CRO da Atonom, que reduziu a conta de US$ 40 mil para US$ 1.200 usando a Lovable (que, convenientemente, é quem ajudou a construir a solução e depois publicou o case). Tem a CarboNet, empresa de 65 pessoas de tratamento de água, cujo COO disse que nunca conseguiu fazer o Salesforce funcionar exatamente como queria e resolveu construir por conta própria. E tem o ex-CEO de operações de consumidor da Amazon que vibe-codou um CRM entre uma noite e uma manhã porque estava cansado de lutar contra campos que não fazem sentido pro processo dele.
Eu já vi esse filme antes, só que com outro nome. Antes de vibe coding, era planilha de Excel disfarçada de CRM. Depois virou app no Bubble, depois Airtable com automações, agora é Lovable, Replit, Cursor gerando código direto. O padrão se repete: empresa pequena, processo simples, poucos usuários, dor real com um sistema genérico que tem 200 campos e ela usa 12. Nesse cenário, sim, faz sentido construir algo enxuto. Não é heresia, é decisão de arquitetura correta pro contexto.
O problema é generalizar esse caso para além do que ele realmente representa. Mais de 90% das empresas da Fortune 500 usam Salesforce, que ainda detém cerca de 24% do mercado global de CRM, mais que os quatro concorrentes seguintes somados. E o dado mais interessante desse debate todo é que nem a própria Anthropic, que teoricamente está na posição ideal para vibe-codar qualquer sistema interno, está fazendo isso. Ela está contratando desenvolvedores Salesforce.
Vale lembrar também do caso Klarna, que ano passado anunciou ter "desligado" o Salesforce como parte de uma modernização com IA. O CEO depois voltou atrás publicamente, dizendo que ficou "tremendamente envergonhado" com a repercussão. O que aconteceu de fato foi consolidação de dados fragmentados entre várias ferramentas SaaS usando um banco de grafos (Neo4j), não substituição de CRM por LLM. A narrativa de "IA substitui Salesforce" vendeu muito mais do que a realidade técnica por trás.
A própria Salesforce reagiu num artigo institucional chamado "Thinking of Vibe Coding Your CRM? Here's The True Cost", alertando sobre dívida técnica acumulada, arquitetura de dados frágil, brechas de segurança e compliance, e ausência de suporte oficial. O ponto mais certeiro do texto: cada atalho que você toma em vibe coding é um "empréstimo de juros altos" contra sua produtividade futura. Isso eu vejo acontecer o tempo todo em projetos reais, só que com Flow em vez de LLM: automação rápida resolve o problema de hoje e vira pesadelo de manutenção em 18 meses, quando ninguém mais lembra por que aquela lógica existe.
A pergunta que eu faço para qualquer cliente animado com vibe coding é simples: quando a pessoa que construiu isso sair da empresa, quem mantém? Quem responde por incidente de segurança, integração quebrada, mudança regulatória? Se você tem anos de dados e processo acumulado, você recomeça do zero? Para uma empresa de 50 pessoas com processo simples, o risco é administrável. Para uma operação com múltiplas unidades de negócio, integrações via MuleSoft, processos de aprovação complexos, Revenue Cloud rodando cotação e faturamento, esse risco vira inviável rapidamente.
Esse debate importa porque muda a conversa que arquitetos e consultores têm com cliente. Não é mais só "por que Salesforce custa caro", é "por que não simplesmente construir isso com IA". Quem trabalha em pré-vendas, discovery ou arquitetura de solução vai ouvir essa pergunta cada vez mais, principalmente de empresas pequenas e médias insatisfeitas com implementações mal feitas ou superdimensionadas.
Também é um sinal de alerta interno: se seu CPQ, seu Flow, sua Experience Cloud estão tão inchados e mal configurados que o cliente prefere reconstruir do zero com IA, o problema pode não ser a plataforma, pode ser a implementação.
Interessante notar que a própria Salesforce sentiu necessidade de publicar um artigo institucional respondendo a esses casos. Isso mostra que a empresa está levando a narrativa a sério, mesmo sabendo que a maioria dos casos vem de empresas pequenas, um segmento onde ela historicamente já compete com CRMs mais leves como HubSpot.
Se você é consultor ou arquiteto, use esse momento para revisar implementações inchadas antes que o cliente use vibe coding como desculpa. Um objeto com 150 campos que ninguém usa, um processo de aprovação que devia ser um Flow simples e virou uma cadeia de Apex trigger, uma tela de Opportunity poluída, tudo isso alimenta a narrativa de que "dá pra fazer mais simples com IA". Faça a limpeza antes que o cliente faça essa pergunta.
Para lideranças avaliando a troca, o critério prático é: número de usuários, complexidade de integração, necessidade de auditoria e compliance, e quem assume a manutenção no longo prazo. Se a resposta para as quatro perguntas for "simples", vibe coding pode ser válido. Se qualquer uma delas escalar, o cálculo muda rápido.
O maior risco não é técnico, é organizacional: a pessoa que vibe-codou o sistema geralmente é a mesma que sustenta o conhecimento tácito da solução. Quando ela sai, a empresa fica com um sistema em produção sem documentação, sem suporte oficial e sem histórico de decisões de arquitetura.
Outro ponto que passa despercebido nos cases virais: eles quase sempre comparam contra uma implementação Salesforce mal feita ou superdimensionada, não contra uma implementação bem arquitetada. Isso distorce a comparação e faz parecer que o problema é a plataforma, quando muitas vezes é a governança da implementação.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.