Feedback loop automatizado: o time de engenharia do Salesforce ensinou uma IA a parar de repetir erro
Um caso real de como transformar comentário de code review em requisito executável, e por que isso importa para quem constrói agentes e automações no ecossistema Salesforce
O time de engenharia interno do Salesforce construiu um sistema que mina comentários de PR, identifica padrões repetidos e reescreve as próprias instruções do gerador de IA sem intervenção humana. O resultado interessante não é a automação, é o sistema aprender a parar de mudar quando não há mais sinal.
Todo arquiteto que já revisou PR de automação conhece a cena. Você escreve o mesmo comentário de review pela quinta vez no mês, sobre a mesma convenção de nomenclatura, a mesma estrutura de pastas, o mesmo erro de escopo. O contribuidor corrige, o PR é aprovado, e na semana seguinte outra pessoa comete exatamente o mesmo erro. O conhecimento existe, mas vive na cabeça de quem revisa, não no sistema.
O time de engenharia do Salesforce bateu de frente com esse problema construindo skills para agentes de IA internamente e resolveu de um jeito que vale a pena entender em detalhe, porque o raciocínio se aplica direto a qualquer time que hoje mantém Flows, Apex, templates de Agentforce ou padrões de configuração em escala.
A sacada central foi tratar comentário de review repetido não como feedback, mas como requisito não documentado. Se o mesmo apontamento aparece em PR após PR, ele não devia estar na cabeça do revisor, devia estar codificado na ferramenta que gera o artefato. Isso levou à construção de um meta-skill (eles chamam de creating-sf-skill) que gera outras skills já seguindo as convenções que os revisores ficavam repetindo: nomenclatura, formatação de constraints, precisão de trigger, escopo. PRs que levavam três dias para mergear caíram para dois.
O problema de avaliar um gerador de IA
Aqui entra a parte que interessa a quem trabalha com arquitetura de dados e automação: como provar que uma versão do gerador é melhor que a anterior? A resposta foi um framework de avaliação em três camadas, cada uma cobrindo o que a outra não cobre.
- Trigger accuracy: testa se a skill ativa corretamente num ambiente com mais de 80 skills concorrentes rodando ao mesmo tempo. Sem isso, você tem uma skill perfeita no papel que nunca dispara em produção.
- Validação estrutural: checagem determinística, as mesmas 21 regras de CI que já bloqueiam PR hoje (kebab-case, formato de frontmatter, convenção de nomenclatura, detecção de conflito entre skills). Zero ambiguidade, passa ou não passa.
- Rubric com LLM-as-judge: onde a checagem mecânica não alcança, um agente avalia qualidade semântica do conteúdo gerado.
O princípio por trás disso é direto: use validação determinística onde a qualidade é mensurável objetivamente, e reserve julgamento de LLM só para o que exige entendimento de contexto. É a mesma lógica que a gente aplica em Revenue Cloud quando decide o que vai para Validation Rule versus o que precisa de uma camada de Apex com lógica de negócio mais nuançada.
O loop que se auto-limita
A parte mais interessante do case não é a automação em si, é o comportamento dela ao longo do tempo. O sistema roda semanalmente, minera comentários de PRs mergeados, deduplica padrões via LLM e calcula prioridade por frequência x severidade. Quando um padrão cruza o limiar, um agente aplica a correção (limitado a cinco melhorias e 100 linhas por ciclo, para conter o raio de impacto), valida contra as três camadas, e se passar, abre um PR para revisão humana.
Rodaram seis ciclos. Nos dois primeiros, mudanças estruturais relevantes (regras de escopo ausentes, nomes de repositório hardcoded). Nos quatro seguintes, o sistema literalmente ficou sem coisa para corrigir. Comentários de revisor foram diminuindo em frequência, sinal foi ficando mais fraco, e três dos seis ciclos abortaram antes de aplicar qualquer mudança porque não havia sinal suficiente para justificar.
Isso é convergência de verdade, não um script de "colete feedback e aplique" que muta para sempre. E quando a convenção de frontmatter mudou entre os ciclos 6 e 7, cinco PRs sinalizaram a mesma orientação defasada na mesma janela, o sistema detectou o pico de frequência e se auto-corrigiu sem ninguém apertar botão.
Isso não é papo de laboratório de IA generativa distante da sua realidade de projeto. É o mesmo problema que você enfrenta com padrões de Flow, templates de LWC, convenções de nomenclatura em Apex ou regras de governança em Data Cloud: conhecimento tribal que vive na cabeça do arquiteto sênior e evapora a cada novo membro do time. O case mostra um caminho concreto para transformar esse conhecimento em artefato versionado e auto-corrigível, algo que se aproxima do que times maduros já tentam fazer com linters customizados e templates de Flow, mas com uma camada de aprendizado contínuo por cima.
O que me chamou atenção nesse case não é a parte de IA, é a parte de engenharia de requisitos disfarçada de IA. Toda equipe que já fez code review sério sabe que boa parte do conhecimento crítico do sistema mora em comentário de PR, não em documentação. Alguém aponta um edge case, o autor corrige, o comentário morre ali. Duas semanas depois outro dev comete o mesmo erro porque ninguém formalizou aquilo como regra.
O time do Salesforce fez o óbvio que quase ninguém faz: pegou esse feedback informal e transformou em requisito executável, algo que a IA consegue checar antes de propor a próxima solução. Isso não é mágica de LLM, é disciplina de engenharia aplicada ao ciclo de vida do agente. E é exatamente esse tipo de disciplina que separa quem constrói agente de produção de quem constrói demo bonita para VP ver.
Para quem trabalha com Agentforce ou qualquer automação mais sofisticada dentro do ecossistema, a leitura prática é direta: se você não tem um mecanismo de captura e reforço de aprendizado, seu agente vai errar do mesmo jeito, na mesma escala, só que mais rápido. IA generativa sem loop de correção estruturado é só um jeito caro de repetir erro em produção com confiança.
O ponto de governança aqui também merece atenção. Quando o erro corrigido vira requisito versionado, você ganha rastreabilidade, algo que arquiteto de Salesforce deveria exigir de qualquer componente crítico, humano ou automatizado. É o tipo de prática que eu gostaria de ver citada com mais frequência em discussão de arquitetura de agentes, porque resolve um problema real, não um problema de slide.
Se você lidera um time de implementação ou mantém um Center of Excellence, o modelo de três camadas de avaliação (determinístico, estrutural, semântico) é replicável hoje sem esperar Agentforce fazer isso automaticamente: separe o que pode ser checado por regra fixa (nomenclatura de API Name, padrão de Flow, formatação de Permission Set) do que exige julgamento de negócio, e documente comentários recorrentes de code review como requisitos de template, não como conhecimento informal.
Para quem já usa Agentforce ou pretende construir agentes internos, vale estudar o conceito de "blast radius" limitado (máximo de mudanças por ciclo) antes de dar autonomia de auto-correção a qualquer automação. É a diferença entre um agente que aprende com governança e um que degrada silenciosamente.
O próprio time reconhece que a arquitetura não é universal: ela depende de um volume mínimo de sinal (aqui, pelo menos 15 PRs mergeados) para não overfittar no estilo de um único revisor. Times pequenos ou com pouca massa de PRs de automação não vão conseguir gerar sinal estatístico suficiente para esse tipo de loop funcionar de forma confiável.
Outro ponto de atenção: mesmo com todo o framework de avaliação, o artefato principal (o diretório core de skills) ainda exige revisor humano no fluxo deles. A confiança em automação total ainda não chegou lá, e isso é um sinal saudável de maturidade, não uma limitação a se envergonhar. Quem estiver pensando em aplicar algo parecido em pipeline de deploy Salesforce deve manter o mesmo ceticismo: automação de correção é ótima, automação de aprovação final ainda merece humano no circuito.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.