Vibe Coding é Fascinante Mas Perigoso e Você Deveria Evitar
Gerar código com IA sem entender a plataforma é receita para dívida técnica, bugs silenciosos e org impossível de manter.
Vibe Coding — escrever código guiado por prompts de IA sem revisão crítica — chegou ao ecossistema Salesforce e traz riscos reais de governança, segurança e manutenibilidade. A abordagem pode parecer produtiva no curto prazo, mas compromete a qualidade arquitetural das implementações. Entenda por que adotar com critério é mais importante do que adotar rápido.
Vibe Coding em Salesforce: trate o LLM como junior dev, não como sênior
O artigo do Tim Combridge no Salesforce Ben levanta uma discussão que já chegou à mesa de qualquer Technical Architect que avaliou Agentforce Vibes, Claude Code ou Cursor contra uma org produtivo: vibe coding funciona como demo, mas falha como prática de engenharia se não houver governança em volta.
A premissa do Karpathy — deixar o LLM dirigir e o humano guiar — colide frontalmente com as restrições da plataforma Salesforce. Apex não é JavaScript genérico. Você opera dentro de governor limits precisos: 100 SOQL queries síncronas, 150 DML statements, 6MB de heap síncrono, 12MB async. Além disso, há bulk patterns obrigatórios, mixed DML exceptions, ordem de execução de triggers e um data model que muda a cada release. Um LLM que gera código sintaticamente válido mas ignora Database.Stateful em um Queueable, ou que escreve SOQL dentro de loop, passa tranquilamente em um code review automatizado e explode em produção com 10 mil registros.
O que o vibe coding resolve bem
Há casos de uso genuinamente úteis. Vale reconhecer:
- Prototypagem em scratch org isolada
- Geração de boilerplate — test classes com
@TestSetup, wrappers de LWC, handlers de trigger seguindo framework existente - Tradução de requisito funcional em primeira versão de código
- Invocable Apex chamado de Flow para admins com PD1 que antes precisavam abrir chamado com o time de dev
Para um admin que precisa de um Invocable Apex simples, é um ganho real e mensurável. O MVP que antes levava dias chega em horas.
O trade-off que o artigo subestima
Tim foca em "verify, don't vibe" e sugere usar um segundo LLM para auditar o primeiro. Isso resolve consistência sintática, mas não resolve três problemas estruturais:
- Contexto de org: o LLM não conhece seu metadata. Ele não sabe que existe um
AccountTriggerHandlerrodando antes, nem que o campoCustom_Status__ctem validation rule que invalida o DML. Retrieval-augmented generation sobre metadata via SFDX ajuda, mas custa tokens e ainda é parcial. - Não-determinismo: dois prompts iguais geram código diferente. Isso quebra a premissa de CI/CD reproduzível. Você precisa congelar o output e versionar o resultado — não o prompt.
- Responsabilidade e licenciamento: código gerado por LLM em org de cliente — quem é o proprietário? Se Agentforce Vibes for cobrado por consumo, o custo por feature entregue pode superar o de um contractor sênior quando você soma os ciclos de regeneração.
Onde isso pega especificamente no CPQ e Revenue Cloud
Se você está em CPQ clássico (SBQQ__), vibe coding em Quote Calculator Plugin ou Custom Action é particularmente perigoso. A documentação pública do CPQ é esparsa, o LLM alucina métodos de SBQQ.QuoteCalculator que não existem, e price rules têm ordem de execução que nenhum modelo público entende bem.
Em Revenue Cloud novo — baseado em core platform, com Product Catalog Management e Pricing Procedures — o risco é menor porque a stack é mais padrão. Mas você ainda está escrevendo extensões em Apex que tocam objetos com triggers internas da Salesforce. O risco não desaparece, apenas muda de forma.
A recomendação de "mover de builder para auditor" está correta, mas incompleta. Auditar Apex gerado por LLM exige mais skill do que escrever, não menos. Você precisa ler código que não estruturou, identificar anti-patterns sutis e validar contra um data model que pode ter mudado entre o treinamento do modelo e hoje.
Como aplicar isso na prática: cenário concreto
Org Enterprise Edition com CPQ instalado, time de 4 admins/consultores e 2 devs. Objetivo: permitir Agentforce Vibes para admins gerarem Invocable Apex chamado de Flow, sem liberar acesso a triggers de Quote ou QuoteLine.
- Setup de perfil restrito: crie permission set
Vibe_Coding_Restrictedque concede acesso ao Agentforce Vibes mas não concede Author Apex. Os admins geram código em scratch org dedicada provisionada via DevHub — nunca na sandbox de integração. - Source control gate: configure branch protection no repositório (GitHub/GitLab) exigindo que qualquer PR tocando
force-app/main/default/classes/tenha review de pelo menos um dev com PD2. Vibe coding entrega no feature branch; dev humano revisa antes do merge. - Static analysis obrigatório: PMD com ruleset Salesforce (
apex-ruleset) rodando no CI antes de qualquer deploy. Bloqueie SOQL-in-loop, DML-in-loop, hardcoded IDs e ausência de CRUD/FLS checks. - Ruleset do LLM: crie um arquivo
.cursorrulesou equivalente definindo bulk patterns obrigatórios, o framework de trigger usado na org (fflib, Trigger Actions Framework), naming conventions e proibição explícita deDatabase.executeBatchsem aprovação. - Verificação cruzada para CPQ: para Apex tocando o namespace
SBQQ__, exija um segundo LLM — Claude com contexto do CPQ Developer Guide carregado — revisando antes do PR humano. - Limitação explícita e documentada: nada de vibe coding em Quote Calculator Plugin, Custom Pricing ou Advanced Approvals. Esses pontos exigem dev sênior com conhecimento de ordem de execução do CPQ.
Pontos de atenção que você precisa monitorar
Licenciamento e consumo Einstein
Agentforce Vibes faz parte do bundle Agentforce e consome Einstein Requests / Flex Credits. Cada geração de código pode consumir múltiplas requests. Em modelo de consumo, um time de 6 pessoas iterando em features médias pode queimar um pacote de 100 mil requests/mês com surpreendente rapidez — modele isso antes de aprovar o piloto.
Governor limits invisíveis em teste
LLMs frequentemente geram código que passa em teste unitário com 1 a 5 registros, mas viola Too many SOQL queries: 101 em produção com bulk load. As test classes geradas pelo próprio LLM tendem a testar happy path com volume baixo. Force uma test data factory com mínimo de 200 registros como padrão.
Platform Events e CDC
Vibe coding gera handlers de Platform Event sem considerar replay, sem EventBus.TriggerContext e sem entender que CDC events chegam em batches. Audite manualmente qualquer código async — Queueable, Schedulable, Batchable. É onde os erros mais caros aparecem.
API limits em integrações
Integrações geradas por LLM tendem a fazer callouts unitários em loop em vez de usar composite ou bulk APIs. Monitore consumo do daily API request limit na org após adoção.
Compliance e auditoria
Se sua org está sob SOX, HIPAA ou requisitos similares, código de origem não-determinística pode ser questionado em auditoria. Documente prompt e commit hash do output como evidência de rastreabilidade.
Falsa sensação de produtividade
O tempo economizado na escrita é frequentemente gasto — e mais — no debugging de comportamento sutil. Meça lead time de feature do prompt ao deploy em produção, não do prompt ao primeiro commit. Essa é a métrica que importa.
A linha de fundo para arquitetos
Vibe coding está sendo posicionado como democratização do desenvolvimento. Para Technical Architects, o ponto é outro: ele desloca o gargalo de escrever código para auditar código não-determinístico em escala. Times que adotarem sem instituir guardrails — rulesets, static analysis com PMD, segundo LLM como reviewer, retrieval sobre metadata da org — vão acumular dívida técnica invisível. Código que passa em testes mas viola bulk patterns, ignora FLS/CRUD, ou cria acoplamento com objetos que mudarão no próximo release. O custo aparece em 6 a 12 meses, quando o volume de produção expõe os limits.
Quem assina embaixo do PR continua sendo o arquiteto humano. Isso não mudou.
O debate em torno de vibe coding — a prática de gerar código majoritariamente via IA, com pouca ou nenhuma revisão crítica — não é apenas uma curiosidade tecnológica. Para quem trabalha com Salesforce, especialmente em papéis de arquitetura e desenvolvimento, ele toca em pontos estruturais que definem a qualidade, a governança e a sustentabilidade das implementações.
A plataforma Salesforce tem características que tornam a adoção acrítica de código gerado por IA particularmente arriscada:
- Limites de governador: código gerado sem contexto de execução real pode ignorar restrições de SOQL, heap size e CPU time — problemas que só aparecem em produção, sob carga.
- Modelo de dados compartilhado: automações mal construídas em uma org multi-tenant têm potencial de cascata. Um trigger gerado sem bulkification correta não é apenas um bug — é um risco operacional.
- Segurança e FLS/CRUD: modelos de linguagem não têm visibilidade do seu modelo de permissões. Código gerado pode expor dados sensíveis ou contornar controles de acesso sem que o desenvolvedor perceba.
- Débito técnico acelerado: a facilidade de geração cria uma ilusão de produtividade. O custo real aparece nas revisões de arquitetura, nos projetos de remediação e nas auditorias de segurança.
Para arquitetos Salesforce, o ponto central não é ser contra IA — é entender que velocidade sem julgamento técnico não é produtividade, é acúmulo de risco. O tema importa porque define como times vão usar essas ferramentas de forma responsável, com critérios claros de revisão, testes e ownership do que é entregue.
O título já entrega o recado: vibe coding é sedutor, mas perigoso. E eu concordo — com nuances importantes. Usar IA para gerar código Apex, LWC ou flows sem entender o que está sendo produzido é uma receita para débito técnico silencioso. O problema não é a ferramenta. É a ilusão de competência que ela cria. Um desenvolvedor júnior que nunca depurou um governor limit não vai identificar quando o código gerado vai explodir em produção com 50 mil registros. E um arquiteto que terceiriza o raciocínio para o modelo perde a capacidade de revisar criticamente o output. O que me preocupa no ecossistema Salesforce especificamente é que a plataforma tem camadas de complexidade que modelos de linguagem ainda tratam de forma superficial: bulkification, sharing model, order of execution, metadata dependencies. O código pode compilar, passar nos testes rasos e falhar miseravelmente no primeiro deploy em uma org com dados reais. Minha posição: vibe coding tem lugar — prototipação rápida, exploração de padrões, aceleração de tarefas repetitivas. Mas como método principal de entrega em projetos Salesforce de médio e grande porte? Não. Ainda não. Quem toma essa decisão sem clareza do risco está transferindo o problema para o cliente — e para quem vai fazer a manutenção depois.
- Defina o perímetro antes de abrir qualquer ferramenta de IA generativa.
- Documente explicitamente o que pode e o que não pode ser gerado via vibe coding no seu projeto: Apex de integração crítica, triggers com lógica de negócio complexa e configurações de segurança estão fora do escopo.
- Se não existe essa fronteira definida, o risco não é hipotético — é garantido.
- Trate o código gerado por IA como código de terceiro não auditado.
- Aplique o mesmo rigor de revisão que você aplicaria a um pacote AppExchange desconhecido: leia linha a linha, valide governor limits, verifique SOQL sem seletividade e identifique hardcoded IDs ou credenciais.
- Nunca faça deploy direto do que a IA gerou sem passar por revisão de um arquiteto ou desenvolvedor sênior.
- Estabeleça um checklist obrigatório de revisão para código gerado via IA.
- Cobertura de testes real — não apenas cobertura numérica, mas asserções que validem comportamento.
- Bulkificação dos triggers e classes Apex.
- Ausência de lógica de negócio em triggers diretos — use handler pattern.
- Validação de permissões e sharing rules adequados ao contexto.
- Nenhum acesso direto a campos sensíveis sem verificação de FLS.
- Use vibe coding onde ele realmente agrega sem comprometer a arquitetura.
- Geração de boilerplate para LWC components sem lógica crítica.
- Criação de classes de utilitário com escopo bem definido e sem dependências externas.
- Geração de testes unitários a partir de código já revisado — não o contrário.
- Documentação técnica e comentários de código.
- Implemente um processo de gate arquitetural antes do merge.
- Nenhum código gerado via IA entra em produção sem passar por revisão arquitetural documentada — seja via pull request review, seja via sessão formal de code review.
- Registre no ticket ou na documentação do projeto que aquele trecho foi originado por IA generativa. Rastreabilidade importa quando algo quebrar em produção.
- Capacite o time a entender o código, não apenas a executá-lo.
- Se o desenvolvedor não consegue explicar o que o código gerado faz e por quê, ele não está pronto para submeter aquele código.
- Vibe coding que não é compreendido é dívida técnica disfarçada de produtividade.
- Vibe coding gera código sem que o desenvolvedor entenda o que está sendo executado — em Salesforce, isso significa Apex rodando em contexto de sistema, sem visibilidade real de sharing rules, limites de governor ou efeitos colaterais em triggers.
- A IA não conhece o estado do sua org. Ela não sabe quais automações existem, quais campos são fórmula, quais objetos têm triggers encadeados — e vai gerar código como se estivesse num ambiente limpo.
- Código gerado por IA tende a ignorar bulkification. Em Salesforce, isso é eliminatório: um único registro processado fora de contexto bulk vai explodir em produção com volume real.
- SOQL e DML dentro de loops são o erro mais comum vindo de código gerado sem revisão arquitetural — e o modelo de linguagem não vai te avisar sobre isso de forma consistente.
- Sem testes unitários robustos escritos por alguém que entende o domínio, o coverage passa mas a cobertura lógica é zero. A IA escreve testes que satisfazem a métrica, não a qualidade.
- Deployar código que você não entende em produção Salesforce é um risco operacional real: rollback não é trivial, metadados têm dependências, e um erro em produção pode travar automações críticas de negócio.
- O vibe coding incentiva pular a fase de design — e em Salesforce, decisões de modelo de dados e arquitetura de automação são praticamente irreversíveis no curto prazo.
- Quem assina o deploy é você, não a IA. A responsabilidade técnica e o impacto no negócio são inteiramente seus.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.