Claude não está criando sua dívida técnica. Ele está removendo o freio que escondia o problema.
Quando mudar Salesforce passa a custar quase nada, arquitetura deixa de ser uma etapa do desenvolvimento e vira o mecanismo que impede velocidade de virar complexidade.
Ferramentas como Claude tornaram tão fácil pedir 'faz um Flow pra isso' que a velocidade de criação disparou muito além da capacidade de documentar, revisar e entender o que foi criado. O risco não é a IA errar a automação. É ela acertar rápido demais, sem ninguém no controle da arquitetura.
Comecei essa reflexão pensando que Claude, Cursor, Copilot e outras ferramentas estavam nos tornando mais eficientes em criar dívida técnica no Salesforce.
Depois de acompanhar a discussão que surgiu em torno desse assunto, acho que essa afirmação precisa de uma correção.
O problema não é exatamente a IA criar dívida técnica.
Nós já fazíamos isso muito bem sozinhos.
O que mudou é que desapareceu boa parte do atrito que limitava a quantidade de decisões técnicas que conseguíamos transformar em metadata por dia.
E talvez essa diferença seja muito mais importante do que parece.
O custo de uma decisão ruim despencou
Durante anos, existiu um pequeno mecanismo de defesa involuntário dentro dos projetos Salesforce: implementar alguma coisa dava trabalho.
Um novo Record-Triggered Flow exigia abrir o Flow Builder, entender o objeto, olhar o que já existia, pensar em before-save ou after-save, criteria, order of execution, fault handling, testes, deployment.
Um trigger Apex exigia ainda mais.
Esse trabalho nunca impediu decisões ruins. Quem já herdou um org com quinze anos de customização sabe disso.
Mas havia fricção.
E fricção também funcionava como um limitador de volume.
Agora imagine o mesmo cenário com um agente conectado ao projeto:
Preciso atualizar esse campo quando o contrato mudar.
Alguns minutos depois está pronto.
Depois:
Tem uma exceção para LATAM.
Pronto.
Se for renovação, atualiza também a Opportunity.
Pronto.
Vamos precisar de outro campo para controlar isso.
Pronto.
Nenhuma dessas decisões precisa ser tecnicamente absurda.
Esse é exatamente o problema.
Dívida técnica raramente nasce de uma decisão obviamente idiota. Ela nasce de dezenas de decisões perfeitamente defensáveis quando analisadas isoladamente.
O perigo da IA não está necessariamente em gerar metadata ruim.
Está em tornar decisão local barata demais.
Um Flow correto pode ser uma decisão arquitetural errada
Essa distinção ficou mais clara para mim depois da discussão.
Claude pode gerar um Flow correto.
Pode colocar descriptions.
Pode gerar testes.
Pode produzir Apex elegante.
Pode inclusive olhar para metadata antiga e ajudar a explicar o que ninguém mais entende.
Há relatos justamente nessa direção: gente usando IA para documentar metadata melhor do que fazia manualmente, analisar codebases existentes e até identificar problemas que estavam escondidos há anos.
Então não acho mais muito útil discutir se “Claude programa bem Salesforce”.
Essa pergunta está ficando velha rapidamente.
A pergunta que me interessa é:
Claude deveria estar construindo aquilo que pedimos?
Essa é uma pergunta completamente diferente.
Uma implementação pode satisfazer 100% do ticket e ainda aumentar coupling, duplicar uma responsabilidade existente, introduzir uma segunda fonte de verdade ou tornar mais difícil mudar aquela área do sistema daqui a dois anos.
Nenhum teste unitário detecta necessariamente isso.
Porque o teste responde se a implementação funciona.
Arquitetura responde se aquela implementação deveria existir daquela maneira.
E não, “muitos Flows” também não é o problema
Aqui eu também mudaria parte da discussão tradicional sobre Salesforce.
Durante muito tempo ouvimos versões diferentes de “um Flow por objeto”. Hoje isso é simplista demais.
A própria Salesforce fornece Trigger Order, Flow Trigger Explorer e orientação arquitetural considerando a densidade de automação do objeto. Dependendo do cenário, dividir responsabilidades entre diferentes Record-Triggered Flows pode ser mais saudável do que construir um gigantesco mega-flow.
Portanto, encontrar oito Flows em Opportunity não prova que o org está mal arquitetado.
O que eu quero saber é:
Por que existem oito?
As responsabilidades estão separadas intencionalmente?
Existe ownership?
A ordem de execução é conhecida?
Existem Entry Criteria conflitantes?
Dois deles representam a mesma regra de negócio criada em momentos diferentes?
Alguém consegue explicar por que a arquitetura chegou naquele desenho?
Isso muda bastante a conversa.
Complexidade não é quantidade de metadata. Complexidade é quantidade de relações que ninguém consegue mais explicar.
E IA pode aumentar muito rapidamente justamente essa segunda variável.
Documentar o “what” ficou barato. O “why” ficou mais valioso.
Um dos melhores contrapontos à crítica original foi simples: Claude é excelente em documentação.
Concordo.
E isso provavelmente fará com que tenhamos metadata mais bem descrita do que tivemos em boa parte da história do Salesforce.
A própria Salesforce recomenda documentar Flows usando nomes, API names e descriptions, e o Well-Architected trata ausência de documentação como antipattern.
Mas existe uma diferença enorme entre:
What:
“Este Flow atualiza Billing Account no Order quando determinadas condições do Contract são atendidas.”
e:
Why:
“Decidimos manter essa lógica separada do processo principal porque o sistema de Billing externo ainda não suporta determinado cenário. Reavaliar quando a integração X for substituída.”
A primeira informação pode ser reconstruída lendo metadata.
Uma IA provavelmente fará isso melhor e mais rápido que qualquer humano.
A segunda talvez desapareça para sempre se não for registrada.
É por isso que acho que Architecture Decision Records, links para User Stories, acceptance criteria e contexto de negócio passam a ser ainda mais importantes na era da IA.
Salesforce Well-Architected recomenda justamente que decision records preservem as alternativas avaliadas, trade-offs, decisão final e racional.
Não precisamos apenas documentar o que construímos.
Precisamos preservar por que achamos que construir aquilo era melhor do que não construir.
A IA também pode ser uma extraordinária máquina de pagar dívida técnica
Aqui está a parte que faltava na minha primeira leitura.
Tudo que torna Claude perigoso para criar complexidade também pode torná-lo extremamente eficiente para removê-la.
Uma IA com acesso suficiente à metadata pode comparar Flows, localizar lógica repetida, mapear referências de campos, analisar Apex, levantar dependências, gerar testes, produzir documentação e ajudar um arquiteto a entender um org que ninguém do time atual construiu.
Ou seja:
o mesmo custo marginal próximo de zero vale para criar e para analisar.
A discussão trouxe exatamente esse contraponto: quando planejamento continua existindo, IA pode reduzir dívida em vez de aumentá-la. O problema aparece quando “isso leva só vinte minutos” vira justificativa para pular o planejamento.
Isso muda minha conclusão.
Talvez a divisão futura não seja entre empresas que usam e empresas que não usam IA para desenvolver Salesforce.
Vai ser entre empresas que usam IA como gerador de metadata e empresas que construíram um sistema de engenharia ao redor da IA.
São coisas muito diferentes.
O time maduro não escreve prompts. Constrói um sistema.
Um dos relatos mais interessantes da discussão veio de um time que centralizou skills em GitHub, estabeleceu standards compartilhados, usa CI/CD, realiza QA antes da promoção entre ambientes e mantém o contexto usado pelos agentes atualizado.
Nesse ponto, Claude deixa de ser simplesmente “alguém muito rápido construindo coisa”.
Existe um harness ao redor dele.
Existem regras.
Existe contexto.
Existe memória institucional fora do modelo.
Existe revisão.
Existe um caminho previsível de Dev → staging → produção.
E aí acontece algo curioso: a IA pode tornar o desenvolvimento mais governado do que era quando cada desenvolvedor ou admin seguia seu próprio processo.
Isso conversa diretamente com Salesforce Well-Architected.
A própria Salesforce diz que boa governança não significa colocar burocracia na frente de toda mudança. Significa criar standards e mecanismos que impeçam customizações ruins de avançar e permitam que as boas cheguem a produção de forma previsível.
Esse detalhe importa muito.
Porque tentar responder ao aumento de velocidade da IA colocando mais reuniões de Architecture Review Board não vai funcionar.
A geração ficou automatizada.
A governança também precisa ficar.
Meu novo checklist antes de deixar IA alterar um org
Se eu estivesse definindo hoje uma política de desenvolvimento Salesforce com Claude, Codex, Copilot ou qualquer agente equivalente, não começaria pela pergunta “qual ferramenta podemos usar?”.
Começaria definindo o contrato da mudança.
Antes de construir, o agente deveria entender:
- Qual problema de negócio está sendo resolvido?
- O que já existe naquele objeto ou domínio?
- Por que alterar algo existente não resolve?
- Quais dependências podem ser afetadas?
- Qual alternativa foi descartada e por quê?
Durante a construção:
- Seguir naming e design standards do projeto.
- Documentar metadata.
- Gerar ou atualizar testes.
- Não criar novos componentes quando uma responsabilidade existente deveria ser ampliada.
- Tratar declarativo e código com o mesmo processo de lifecycle.
Depois:
- Registrar o motivo da decisão, não apenas o resultado.
- Relacionar a mudança ao ticket ou User Story.
- Revisar automações do objeto no Flow Trigger Explorer quando aplicável.
- Executar regressão.
- Fazer a mudança passar pelo mesmo source control, CI/CD e code review de qualquer implementação humana.
Isso não é burocracia criada porque não confiamos na IA.
É o contrário.
É o processo necessário porque começamos a confiar nela para produzir em uma escala que humanos nunca produziram.
Agentforce torna essa discussão ainda mais importante
Existe ainda uma segunda consequência.
Estamos construindo agentes sobre sistemas empresariais que já acumulam anos de decisões históricas.
Quanto mais automação, regras, permissões, dados e integrações esses agentes puderem interpretar ou acionar, mais importante se torna termos um sistema cuja intenção seja compreensível.
A própria orientação Well-Architected da Salesforce conecta documentação confiável e centralizada ao contexto que sistemas agentic podem consumir.
Isso significa que documentação não é mais apenas aquilo que deixamos para o próximo consultor.
Ela começa a se transformar em parte da infraestrutura que ajuda máquinas e humanos a compreender o sistema.
Essa talvez seja uma das mudanças mais interessantes dessa nova fase.
Então Claude está aumentando nossa dívida técnica?
Minha resposta hoje seria:
depende do que ficou mais rápido junto com ele.
Se somente implementação ficou 10x mais rápida, provavelmente existe um problema chegando.
Se discovery, análise de impacto, documentação, testing, review e refactoring também ficaram 10x melhores, talvez aconteça exatamente o contrário.
Claude não inventou o admin que resolve tudo criando “só mais um campo”.
Não inventou o desenvolvedor que cria outro trigger porque não quer mexer no existente.
Não inventou stakeholder pedindo shortcut para colocar algo em produção na sexta-feira.
Esses personagens já estavam aqui.
A IA apenas removeu boa parte do custo que limitava quantas dessas decisões poderiam virar software.
E por isso minha preocupação agora é um pouco diferente da inicial.
Não tenho medo de a IA ficar boa demais em construir Salesforce.
Tenho medo de organizações ficarem boas demais em construir antes de aprenderem a decidir, documentar e governar na mesma velocidade.
Porque a próxima geração de dívida técnica talvez não seja um org cheio de código ruim.
Pode ser algo muito mais difícil de enxergar:
um org cheio de soluções tecnicamente boas para decisões que ninguém mais lembra por que tomou.
E nenhuma quantidade de documentation em Description vai resolver completamente isso.
Quando a IA generativa reduz o custo de criar um Flow para praticamente zero, ela também remove o único freio natural que existia antes: o esforço. Antes, construir automação exigia tempo suficiente para alguém parar e pensar se aquilo deveria existir. Agora não exige mais, e é aí que mora o problema.
Se a velocidade de criar automação supera a velocidade de documentar e revisar, o org acumula complexidade que ninguém mais domina por completo. Isso não é um risco abstrato: é exatamente o tipo de débito técnico que trava upgrade, migração de CPQ para Revenue Cloud, ou adoção de Agentforce mais adiante.
Arquiteto que ignora esse ciclo hoje vai herdar um org ilegível daqui a um ano, só que maior e mais rápido do que o de antes da IA generativa. A pergunta que importa deixou de ser "quanto tempo leva para criar isso" e passou a ser "quem vai entender isso quando eu não estiver mais no projeto".
- Governança de automação vira pré-requisito, não boa prática opcional
- Revisão de Flow precisa entrar no mesmo ritmo da geração via IA, não depois
- Escalabilidade de arquitetura passa a depender de quem audita, não só de quem constrói
O ponto que me incomoda nessa discussão do r/salesforce não é o Claude, é o que ele expõe. Sempre existiu gente criando Flow ruim, Apex acoplado, automação sem nenhum desenho por trás. A diferença é que antes isso levava tempo e deixava rastro: quem construiu, tinha que entender o que estava fazendo, nem que fosse por tentativa e erro. Agora a IA remove esse atrito, e o que sobra é volume.
Já vi esse filme antes, só que com outro protagonista. Quando o point and click virou mainstream no Salesforce, o discurso era o mesmo: "qualquer admin consegue automatizar sem código". E conseguia mesmo, o problema é que ninguém parou pra pensar em quem ia manter aquilo três anos depois. IA generativa é isso na décima potência. Ela não erra a sintaxe, ela erra o contexto, e isso é bem mais perigoso porque passa despercebido em code review.
Minha leitura de arquiteto é direta: o gargalo nunca foi gerar automação, sempre foi decidir onde ela deve morar. Flow, Apex, orquestração via Agentforce, integração externa. Isso exige entender o org como um todo, os limites de governor limits, o histórico de decisões que já foram tomadas ali dentro. Claude não tem esse contexto e não é obrigação dele ter. É nossa.
Não estou advogando contra usar IA para acelerar entrega, uso o tempo todo. Estou dizendo que sem um processo de governança que já existia antes da IA chegar, ela só vai empacotar decisão ruim com aparência de decisão rápida e confiável. O problema nunca foi a ferramenta ser boa demais. É a ausência de arquitetura sendo mascarada por velocidade.
Na prática, dá pra conter o estrago com processo, não com proibição. Algumas coisas que eu implementaria já na próxima sprint:
- Trate metadata gerado por IA como pull request: nenhum Flow, trigger ou Permission Set entra em produção sem descrição do objetivo de negócio, nome padronizado e justificativa de por que aquela automação precisa existir e não uma já criada antes.
- Rode o Flow Trigger Explorer antes de aprovar qualquer novo Record-Triggered Flow em objeto que já tem automação ativa. Isso deveria ser gate obrigatório, não sugestão de boas práticas.
- Mantenha um changelog de automação que sobrevive à saída do consultor que criou aquilo. Não precisa ser sofisticado: uma planilha ou um campo customizado de documentação já resolve boa parte do problema de rastreabilidade.
- Formalize o uso de Claude, Copilot ou Agentforce Vibes como política explícita de projeto, não como atalho informal de quem tem acesso à ferramenta. Defina quem pode gerar, em que contexto e com qual nível de aprovação.
- Revise metadata de IA com o mesmo rigor de Apex escrito por humano, incluindo teste de regressão e checagem de ordem de execução no objeto. Se você não aceitaria um PR de Apex sem esse cuidado, não devia aceitar um Flow gerado em trinta segundos sem o mesmo escrutínio.
Nenhum desses pontos é sobre desacelerar a entrega. É sobre garantir que a velocidade que a IA trouxe não vire a dívida que alguém vai ter que pagar seis meses depois, sem saber por onde começar.
- Discurso de "a IA resolve a dívida técnica depois" é ilusão de arquitetura. Ferramenta de análise de org identifica Flow órfão ou duplicado, mas não decide o que consolidar, aposentar ou manter. Essa decisão exige alguém que entenda o negócio por trás da automação, e isso IA nenhuma resolve sozinha.
- Gerar Flow rápido demais em objetos críticos como Opportunity, Quote ou Order é jogar gasolina em problema que já existe. Automações conflitantes nesses objetos são dor de cabeça recorrente mesmo sem IA no meio.
- Acelerar a geração de automação sem controle de governança é o caminho mais curto para production incident silencioso, daqueles que só aparecem quando o processo de negócio já quebrou há semanas.
- Velocidade de criação não é o gargalo real de quem opera Salesforce em escala. O gargalo é decisão arquitetural, e isso não se resolve com prompt melhor.
- Quem trata Claude como atalho para pular etapa de design está apenas movendo o problema para frente, com juros.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.