velocidade sem freio

A thread que bombou essa semana no r/salesforce não é sobre IA errar automação. É sobre IA acertar rápido demais, sem ninguém segurando o volante da arquitetura. Antes, o atrito de escrever um Flow do zero ou pedir ajuda num fórum funcionava como filtro natural: só ia pra produção o que alguém tinha pensado o suficiente pra construir.

Com Claude, Copilot e afins, esse atrito sumiu. Pede, gera, aprova, publica. O problema é que dívida técnica sempre existiu, só que agora ela se acumula numa velocidade que nenhuma revisão manual acompanha. Não é a ferramenta que é ruim, é a ausência de processo em volta dela.

Na prática, isso significa que governança de automação deixou de ser luxo de org grande e virou sobrevivência básica. Quem não tem um mínimo de padrão de nomenclatura, revisão por pares e critério de quando um Flow vira Apex vai descobrir isso do jeito caro, com um incidente em produção que ninguém sabe explicar.

O ponto que mais me chamou atenção na thread é que a comunidade já sabe disso. O desabafo não é contra a IA, é contra a falta de maturidade organizacional pra usar bem uma ferramenta poderosa. Isso é problema de arquiteto, não de ferramenta.

Reparei um padrão incomodativo essa semana: Dreamforce precisando provar que Agentforce funciona, profissionais desconfiando publicamente de decisão tomada por IA, e a própria engenharia da Salesforce reconhecendo, em nota técnica, que confiança é mais difícil de entregar do que geração de resposta. Três fontes diferentes, mesmo sintoma.

Minha leitura de arquiteto é que confiança não é feature nem sentimento de marketing, é uma pilha de camadas que se constrói dentro da sua org, uma por uma. Tem a camada de dado (o agente enxerga o Data Cloud certo?), a de contexto (ele sabe quando não sabe?), a de ação (ele tem permissão real pra fazer o que promete?), a de auditoria (dá pra rastrear cada decisão?) e a de failsafe (o que acontece quando ele erra?).

Nenhuma dessas camadas aparece em keynote. Elas aparecem em governança de permission set, em Flow bem desenhado por trás do agente, em log de auditoria configurado antes do primeiro piloto rodar em produção. Quem está esperando a Dreamforce resolver isso por decreto vai continuar esperando.

O gap de confiança que todo mundo comenta não é um problema da Salesforce resolver por nós. É um problema de arquitetura que cada org precisa resolver na prática, com trabalho chato de configuração e teste, antes de colocar o agente na frente do cliente.

Quando alguém com 15 anos de plataforma pergunta como se preparar pra entrevista, não é dúvida de iniciante, é sinal de que as regras do jogo mudaram de verdade. Se o candidato sabe escrever um trigger, a IA também sabe. O que a IA não sabe é por que aquele trigger deveria existir daquele jeito, numa org específica, com aquele histórico de decisões ruins acumuladas.

Entrevista técnica de Salesforce sempre teve um viés de "resolve esse problema no quadro", tipo leetcode adaptado. Isso morreu, ou deveria morrer, porque qualquer LLM decente resolve esse tipo de exercício em segundos. O que sobrevive como diferencial é a capacidade de explicar trade off, de justificar decisão de arquitetura, de admitir limite de uma solução declarativa antes de partir pro código.

Isso muda o roteiro de quem estuda pra entrevista. Menos "decorar sintaxe de SOQL" e mais "saber contar a história de um projeto que deu errado e o que você aprendeu com isso". Recrutador técnico bom já percebeu essa mudança, e quem se prepara só decorando padrão de resposta vai ser pego de surpresa na pergunta de acompanhamento.

O profissional de 15 anos que fez a pergunta não precisa se reinventar. Precisa é aprender a verbalizar o que já sabe fazer no automático, porque isso virou o verdadeiro filtro.

Quem já sofreu com catálogo espalhado entre CPQ legado, planilha de preço e campo customizado vai entender rápido o valor do Product Catalog Management. A proposta central é simples de enunciar e difícil de executar bem: uma única hierarquia, Catalog, Category, Product2, que serve tanto pra venda quanto pra exibição e configuração.

O que separa esse post dos anteriores da série é a clareza sobre os três Selling Models e a distinção entre Simple e Bundled, Static e Configurable. Isso não é detalhe técnico gratuito, é a decisão que define se seu catálogo escala ou vira gambiarra em seis meses. Bundle mal modelado desde o início é dor de cabeça garantida na hora de reconfigurar preço ou aprovação.

O detalhe mais elegante do post é como atributos viram blocos reutilizáveis via Classifications. Isso resolve um problema clássico de CPQ antigo, onde cada produto tinha seu próprio conjunto de campos customizados sem reuso nenhum. Com Classifications bem desenhadas, você define atributo uma vez e aplica em qualquer produto compatível.

Pra quem está migrando de CPQ legado, esse post funciona como checklist mental antes de qualquer discovery técnico. Entender a hierarquia certo evita retrabalho de catálogo inteiro depois que o projeto já está em produção.