Vibe coding no Salesforce: por que a org legada quebra a promessa da IA autônoma
O gargalo não é o modelo de IA, é a falta de uma fonte confiável da verdade e de orquestração por fases
Vibe coding funciona bem em projetos greenfield, mas orgs Salesforce com anos de customização escondem verdades que não estão no repositório de código. Um grafo de metadados exposto via MCP server, combinado com orquestração em fases, permite mapear dependências reais e gerar blueprints de deploy em horas em vez de dias.
Vibe coding chegou no Salesforce e a promessa é sedutora: você conversa com um agente, ele entende o problema, escreve o código, ajusta o Flow, propõe a automação e entrega pronto para deploy. Funciona bonito em projeto novo, greenfield, sem bagagem. O problema é que quase nenhuma org que eu conheço é greenfield. É org de oito, dez anos, com CPQ legado convivendo com tentativa de Revenue Cloud, Process Builder que ninguém teve coragem de aposentar, campo customizado que só o consultor que saiu em 2019 sabia explicar por que existe.
E é aí que a conversa fica interessante, porque o motivo do vibe coding não escalar direto para dentro de uma org enterprise não é o modelo de IA ser fraco. É a forma como o trabalho é orquestrado. Quem manja de verdade de vibe coding não fica numa conversa única e infinita com o agente. Divide o trabalho em fases, cada fase com entrada e saída bem definidas, um agente novo para cada fase (sem carregar o "lixo" de contexto da fase anterior) e a passagem de bastão feita via arquivo em disco, tipo markdown, porque os agentes não conversam entre si: eles leem e escrevem arquivo. É basicamente handover documentado, só que documentado por máquina para máquina.
Agora tenta rodar esse mesmo esquema numa org Salesforce de verdade. A primeira dor é: qual é a fonte da verdade? Num repositório de código tradicional, é o repo, ponto final. Numa org Salesforce, você tem duas verdades competindo: o que está versionado no repo e o que foi alterado direto em produção, via interface, sem passar por lugar nenhum. Email template, list view, report, regra de preço em CPQ legado, agente configurado na tela: nada disso necessariamente está no seu controle de versão. A própria API de metadados admite que Report padrão nem consegue ser recuperado via Metadata API. List view mora dentro do metadado do objeto. E configuração baseada em registro (Industries, CPQ, pacotes gerenciados de terceiros) simplesmente não existe como arquivo de repositório.
Some a isso o problema de "onde eu documento a decisão". Numa org com CPQ legado misturado com tentativa de Revenue Cloud, ninguém registrou por que aquela regra de preço existe, por que aquele campo foi criado, por que aquele Fluxo (ou pior, aquele Process Builder) faz o que faz. É a casa que foi reformada quatro vezes sem nunca deixar a planta baixa. Você anda por todo cômodo e não sabe qual parede é estrutural.
Para um agente conseguir operar com autonomia real sobre uma org assim, duas coisas precisam existir ao mesmo tempo: um modelo confiável da verdade completa da org (não uma extração parcial, mas algo próximo de um "gêmeo digital" do metadado real, atualizado, incluindo relatório, list view, registro de configuração) e uma orquestração que quebre o trabalho em fases com handover documentado, exatamente como o vibe coding sério já faz em projeto novo.
O exemplo prático que mais me chamou atenção foi um caso de consolidação de agendamento de ordens de serviço. Dois objetos que cresceram grudados um no outro ao longo dos anos, ambos carregando automação de agendamento, nenhum sendo claramente o dono do processo. A solução arquitetural é clássica: criar um objeto de junção entre os dois, migrar a automação para lá, fazer o backfill dos dados e aposentar o formato antigo. É o tipo de refatoração que qualquer arquiteto sênior já fez na mão, suando para mapear dependência por dependência.
O que muda com uma camada de contexto adequada (no caso, expondo o grafo de metadados via MCP server para qualquer agente de codificação, seja Claude, Cursor ou Agentforce Vibes) é a velocidade de mapear a dependência real: qual automação depende de qual objeto, o que quebra se você mexer ali, qual a ordem de execução correta para o backfill não corromper dado. Trabalho que levaria dias de análise manual entregue em menos de uma hora, com decisão documentada em cada etapa, gerando um blueprint que qualquer plataforma de deploy (Copado, Gearset, o que for) pode simplesmente implementar.
Isso importa porque a conversa sobre IA generativa em Salesforce está presa demais em "o agente escreve o Apex" ou "o agente monta o Flow", quando o gargalo real está um passo antes: entender o que já existe na org e por quê. Toda arquitetura séria de Revenue Cloud, de migração de CPQ legado, de consolidação de objeto, depende de mapa de dependência preciso. Sem isso, o agente (ou o consultor júnior, tanto faz) só está adivinhando, e adivinhação em produção custa caro.
Para arquiteto e admin de org enterprise, o recado prático é: a era de "vibe coding funciona em qualquer org" ainda não chegou, e não vai chegar enquanto a documentação de decisão e o mapa de dependência não forem tratados como parte da entrega, e não como acessório opcional que ninguém tem tempo de escrever.
O que mais me interessa aqui não é o hype de vibe coding, é a confissão implícita de que documentação de arquitetura sempre foi o elo fraco em projeto Salesforce, muito antes de qualquer agente entrar em cena. Toda org de dez anos que eu já entrei tinha esse mesmo problema: parede estrutural sem planta baixa. Se a chegada de IA generativa forçar o mercado a levar documentação de decisão a sério, isso é ganho para todo mundo, com ou sem agente rodando por trás.
- Antes de soltar qualquer agente de codificação numa mudança estrutural (fusão de objeto, retirada de automação legada, migração de CPQ para Revenue Cloud), mapeie a dependência real primeiro: quem lê, quem escreve, quem depende daquele objeto ou campo, incluindo Flow, relatório, list view e configuração baseada em registro.
- Trate documentação de decisão arquitetural como entregável, não como nota de rodapé. Se seu time não registra "por que fizemos assim", nenhum agente (nem o próximo consultor humano) vai conseguir dar manutenção com segurança.
- Para mudanças de alto risco (consolidação de objeto, backfill de dado, aposentadoria de automação legada), separe o trabalho em fases explícitas: descoberta de dependência, desenho da mudança, plano de migração, execução. Não deixe tudo numa conversa só, seja com IA ou com o próprio time.
- Se está migrando de CPQ legado para Revenue Cloud, esse é exatamente o tipo de cenário onde falta mapa de dependência confiável: regra de preço legada, campo customizado, Process Builder esquecido. Vale investir tempo em levantamento antes de qualquer automação via agente.
Cuidado com a tentação de tratar isso como "ferramenta mágica que documenta sozinha". A qualidade da análise depende de a org estar minimamente organizada: metadado sincronizado, dependência real mapeada, sem isso o agente também vai alucinar em cima de contexto incompleto, só que com mais confiança aparente. E antes de qualquer proposta de mudança estrutural (objeto de junção, retirada de automação) virar deploy, ela precisa passar por revisão humana de arquitetura: o agente propõe, mas quem assina a decisão de negócio ainda é gente.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.