Quando a IA Escreve Seu Código Salesforce, de Quem É a Culpa Quando Algo Quebra?

Há alguns anos, gerar um componente Apex funcional do zero exigia tempo, experiência e — sejamos honestos — uma quantidade considerável de tentativa e erro. Hoje, qualquer pessoa com acesso a um LLM consegue produzir código em minutos. Isso muda bastante coisa no dia a dia de quem trabalha com Salesforce. O problema é que 'funcionar' e 'estar correto' são duas coisas completamente diferentes.

O artigo publicado pelo Salesforce Ben coloca uma pergunta que está no ar nas comunidades técnicas, mas que ainda não encontrou uma resposta confortável: quando a IA gera o código que vai para produção, e alguma coisa dá errado — seja um vazamento de dados, uma falha de segurança ou simplesmente uma org que acumula débito técnico silenciosamente — quem responde por isso?

A ferramenta não tem culpa. Mas alguém tem.

Tim Combridge, Salesforce MVP e colaborador frequente da comunidade, resume bem o paradoxo: a IA é excelente para acelerar tarefas repetitivas, debugar erros difíceis de localizar e montar provas de conceito. Ele mesmo admite ter delegado boa parte da escrita de fórmulas para LLMs nos últimos anos. O risco não está no atalho em si — está no que passa despercebido quando você não entende completamente o que foi gerado.

O exemplo citado é clássico no contexto de Lightning Web Components: um componente pode exibir os dados certos na tela e, ao mesmo tempo, estar rodando em um contexto que expõe muito mais do que deveria para quem souber como explorar a brecha. O front-end parece impecável. O problema está nas camadas que ninguém revisou.

Isso não é um problema exclusivo da IA — já víamos isso com código copiado de fóruns e Stack Overflow. A diferença é o volume. A IA acelera a produção de código a um ritmo que os processos de revisão da maioria das equipes simplesmente não acompanham.

Responsabilidade distribuída — mas nem sempre clara

Paul Battisson, também Salesforce MVP, traz um ponto que quem trabalha com implementações enterprise vai reconhecer imediatamente: o modelo de responsabilidade compartilhada da Salesforce já existe, e a chegada da IA não o elimina — ela o complica.

A lógica parece simples: se você gerou o código, você é responsável pelo que ele faz. Mas essa lógica ignora um contexto que está cada vez mais comum nas organizações. Há times sendo cobrados pelo volume de uso de IA como métrica de produtividade. Quando a liderança começa a medir 'quanto de AI você usou esta semana', o incentivo naturalmente empurra as pessoas a gerar mais, revisar menos e entregar mais rápido. O risco de uma decisão gerencial se distribui até o admin que está na ponta executando.

Paul usou uma analogia que vale repetir: preparar um baiacu. Existe uma parte pequena que é segura para consumo. O resto é veneno. Se você não tem o treinamento necessário, não deveria estar manipulando o peixe — independentemente de ter o equipamento certo na mão. Com IA, a lógica é a mesma: se você está gerando algo que não consegue avaliar criticamente, precisa trazer alguém que consiga.

O débito técnico silencioso

Débito técnico em Salesforce não é novidade. Orgs complexos acumulam automações sobrepostas, campos sem uso e lógica que ninguém mais sabe exatamente por que existe. A IA não inventou esse problema — mas aumenta a velocidade com que ele cresce.

Cada fluxo gerado sem entendimento real, cada classe Apex que 'funcionou nos testes' sem revisão adequada, cada componente entregue sem documentação — tudo isso vai parar em algum lugar na org. E quando o projeto de refatoração chegar, ou quando a auditoria de segurança acontecer, alguém vai ter que entender o que foi feito. Se esse entendimento não existia quando o código foi escrito, não vai surgir do nada depois.

Paul é direto: 'IA não é substituta para o seu cérebro.' Documentação escrita por humanos, compreendida por humanos, revisada por humanos — isso ainda é o que sustenta uma org saudável no longo prazo. Ferramentas mudam. A necessidade de entendimento, não.

O que muda na prática

Na minha leitura, o ponto central do debate não é 'usar ou não usar IA no desenvolvimento Salesforce'. Isso já está decidido — as equipes estão usando, e a tendência é aumentar. A questão é como estruturar o processo ao redor disso.

Algumas perguntas que deveriam estar na pauta de qualquer time que usa IA para construir em Salesforce:

• Existe revisão de código por alguém com experiência suficiente para identificar riscos de segurança, especialmente em LWC e Apex?
• Os critérios de aceite incluem verificação de contexto de execução, permissões e exposição de dados — ou só confirmam que 'funcionou'?
• A documentação acompanha o ritmo de entrega, ou está sempre um sprint atrás?
• Quando um admin usa IA para gerar algo fora do seu nível de experiência, existe um caminho claro para escalona para um arquiteto ou desenvolvedor sênior?

Essas não são perguntas novas. São as mesmas que boas equipes já deveriam estar respondendo. O que muda é a urgência — porque agora o volume do que está sendo produzido cresceu de forma desproporcional em relação à capacidade de revisão.

A IA é uma ferramenta poderosa. Continua sendo uma ferramenta. E ferramentas, por melhores que sejam, não substituem o julgamento de quem sabe o que está fazendo.