Agentic DevOps / Salesforce
Vídeo de introdução Áudio · Debate (22 min) Problema vs Solução Agentic Development Arquitetura Federada Spec-Driven Development Framework SDD + Agentic Exemplo Prático Orquestrando o Devin Custos & ACUs Fluxo de Trabalho Estrutura do Repositório Governança & Checklist Autoria & Credibilidade Recursos
Salesforce DevOps · Modelo Federado · Devin + Flosum

Como desenvolver Salesforce com IA Agentic sem gerar débito técnico

Um guia prático e ensinável para times Apex, LWC e Admins que querem parar de digitar boilerplate e começar a orquestrar soluções de negócio usando Spec-Driven Development, Devin (Cognition) e Flosum como Source of Truth.

Este não é um novo método — é a aplicação disciplinada de boas práticas de engenharia (contratos explícitos, fronteiras claras, governança de deploy) ao ecossistema Salesforce com Devin e Flosum.

O problema

IA sem contexto gera código inconsistente, conflitos de metadata e débito técnico que escala mais rápido que a feature.

No Salesforce isso piora

Orgs compartilhadas, regras implícitas, profiles conflitantes e legado tornam cada deploy um campo minado.

A solução aqui

Spec-Driven Development + agentes autônomos + Flosum como SoT, em um framework ensinável passo a passo.

Começar pelo SDD Ver a Arquitetura Federada github.com/issei/sf-repo
Modelo
Federado

Multi-times, multi-repos, sem monorepo

Method
Spec-Driven

Templates estruturados orquestram a IA

Source of Truth
Flosum CLI

Versionamento, merge e promoção

Auth
sf · Web Login

Sem JWT, sem chaves locais

Em 1 vídeo

Explicação resumida em vídeo

Se você prefere começar pelo panorama visual antes de mergulhar nas seções, este vídeo cobre os pontos centrais do framework — Agentic, SDD e o pipeline com Flosum — em formato direto.

Vídeo no YouTube · resumo executivo
Abrir no YouTube

O contexto

Por que IA + Salesforce, do jeito tradicional, quebra em escala

Existem dois problemas se sobrepondo: o uso ingênuo de IA generativa no código e as armadilhas intrínsecas do Salesforce (orgs compartilhadas, regras implícitas, integração com legado). Quando esses dois mundos colidem sem método, o resultado é débito técnico exponencial.

Problemas de IA no desenvolvimento

  • Código inconsistente — cada sessão produz um padrão diferente para o mesmo problema.
  • Falta de contexto — a IA não conhece convenções, naming, ownership ou o legado do time.
  • Hallucinations silenciosas — APIs e campos que parecem existir mas não existem na org.
  • Débito técnico acelerado — código aceito sem revisão crítica vira legado em semanas.
  • Custo descontrolado — prompts vagos consomem tokens/ACUs em loops de "tentativa e erro".

Problemas específicos do Salesforce

  • Orgs complexas e compartilhadas — múltiplos times tocando QA/Prod ao mesmo tempo.
  • Regras implícitas — Profiles, Permission Sets, Validation Rules e Flows que ninguém documentou.
  • Integração com legado — Apex de 10 anos, triggers gigantes, dependências escondidas.
  • Metadata trampling — um time sobrescreve componentes de outro silenciosamente.
  • Source of Truth ambígua — Git e Org divergem, e ninguém sabe qual é a verdade.

A virada

Tradicional vs Federado Agentic

Múltiplos times trabalhando nas mesmas orgs de QA, PreProd e Prod — em um único repositório — geram conflitos diários, deploys quebrados e metadata trampling. O Modelo Agentic Federado é a abordagem estruturada adotada para lidar com isso, combinando isolamento, IA e governança.

Modelo Tradicional

Anti-pattern
  • Monorepo com todos os times pisando no mesmo metadata.
  • Conflitos constantes em Profiles, Layouts e Flows.
  • Deploys diretos via CLI nas orgs compartilhadas — risco de sobrescrita.
  • "Source of Truth" ambígua entre Git e a Org.
  • IA sem contexto = código genérico, retrabalho e custo alto.

Modelo Agentic Federado

Recomendado
  • Cada time em seu próprio repo GitHub isolado.
  • Ownership por domínio + validação automática de fronteiras.
  • Devin valida e prepara — Flosum promove.
  • Specs, playbooks e skills dão contexto rico à IA.
  • Smart Merge do Flosum resolve conflitos entre times.

Conceito

O que é Agentic Development

Antes de falar em SDD, é preciso entender a mudança de paradigma. IA como ferramenta é o copilot autocompletando linhas; IA como agente é um colaborador autônomo que lê specs, executa tarefas, valida e itera dentro de fronteiras claras. Os dois mundos exigem técnicas distintas.

IA como ferramenta

Copilot

Você dirige cada linha. A IA preenche, sugere, completa. Foco em velocidade local.

  • ·Atua dentro do editor, em escopo curto.
  • ·Não tem memória entre tarefas.
  • ·O dev é responsável por contexto, validação e arquitetura.
  • ·Bom para: snippets, rename, refactor pontual.

IA como agente autônomo

Agentic

Você dá direção, contexto e fronteiras. O agente planeja, executa, valida e itera sozinho.

  • ●Lê Specs, playbooks, knowledge-base.
  • ●Cria branches, codifica, roda testes, abre PRs.
  • ●Mantém estado entre iterações da mesma sessão.
  • ●Bom para: features ponta a ponta dentro de fronteiras claras.

Como o agente atua no ciclo de desenvolvimento

Agentes não são "IA com mais tokens". São loops de raciocínio com acesso a ferramentas (shell, FS, CLI, browser) operando dentro do que você explicitar como contexto e limites.

Plan

Lê a Spec, decompõe em tarefas, define ordem de execução.

Act

Executa: cria arquivos, roda CLI, modifica código, chama testes.

Observe

Lê stdout, logs, falhas de validação e feedback do humano.

Reflect

Avalia se cumpriu o critério de aceite e replaneja se necessário.

Origem do ciclo: este loop é inspirado no padrão ReAct (Reasoning + Acting), introduzido por Yao et al. em 2022, que descreve como agentes de linguagem combinam raciocínio e ação em iterações sucessivas. Aqui ele é adaptado ao contexto de desenvolvimento Salesforce com Devin.
Insight central: a qualidade do output do agente é função direta da qualidade do contexto. Sem contexto = adivinhação. Com contexto rico (Spec + playbook + knowledge-base) = engenharia de verdade.

A arquitetura

Quatro pilares, papéis bem definidos

Em vez de um sistema monolítico, separamos responsabilidades. Cada peça faz uma coisa — e faz muito bem.

Pilar 1

GitHub

A camada de intenção e conhecimento.

  • · Specs e playbooks
  • · Skills e knowledge-base
  • · Pull Requests e revisão humana
  • · Não é a Source of Truth da Org
Pilar 2 · SoT

Flosum

A Source of Truth e o motor de promoção.

  • · Versionamento real do estado da Org
  • · Smart Merge entre times
  • · Promoção QA → PreProd → Prod
  • · Único caminho de deploy oficial
Pilar 3

Salesforce

O runtime e os ambientes.

  • · Sandbox para validação
  • · QA, PreProd e Prod compartilhadas
  • · sf via Web Login
  • · Nunca deploy direto via Devin
Pilar 4

Devin

O executor/desenvolvedor autônomo.

  • · Lê Specs e knowledge-base
  • · Codifica em force-app/
  • · Valida via --check-only
  • · Prepara o pacote para Flosum

Relacionamento

Como os pilares se conectam

GitHub captura a intenção, Devin executa, Flosum governa a promoção e o Salesforce é o runtime. As setas mostram a direção real do fluxo — não o desejo, o que efetivamente acontece.

lê Spec + playbooks push branch + PR merge → main (webhook) --check-only sandbox promove QA → PreProd → Prod PILAR 1 GitHub intenção · specs · PRs PILAR 4 Devin executa · codifica · valida PILAR 2 · SOURCE OF TRUTH Flosum smart merge · promoção PILAR 3 · RUNTIME Salesforce QA · PreProd · Prod CAMADA DE INTENÇÃO & EXECUÇÃO PIPELINE GOVERNADO (DEPLOY OFICIAL)

→ contínua

caminho oficial e canônico

--- tracejada

validação local (não promove)

Flosum em destaque

único deployer para ambientes compartilhados

Clusters

separam intenção/execução do pipeline governado

Método

Spec-Driven Development — o coração do método

O Devin não adivinha. Ele segue limites claros. A Spec é o contrato entre o time, o agente e o negócio — e quanto melhor a Spec, menor o custo (ACUs) e maior a qualidade do output.

Definição

O que é SDD

Spec-Driven Development é uma prática em que toda implementação é precedida por uma specification versionada — um documento estruturado que descreve contexto, requisitos, regras técnicas, limites e critérios de aceite. A Spec antecede o código e é o input principal do agente.

O Spec-Driven Development não é um conceito inventado aqui — ele se apoia em práticas consolidadas como Design by Contract (Bertrand Meyer), BDD/TDD com critérios de aceite explícitos e Architecture Decision Records. O que esta abordagem faz é aplicar esses princípios ao contexto específico de agentes autônomos no Salesforce.

Fonte de verdade

Papel da specification

A Spec é a fonte de verdade da intenção. Código pode mudar; a Spec captura o porquê. Para o agente, ela é o briefing; para o time, é o contrato; para o futuro, é a documentação que sobrevive ao refactor. Versionada em specs/, junto ao código.

Benefícios

Por que usar SDD com agentes

  • ●Previsibilidade — escopo congelado antes do código.
  • ●Qualidade — critérios de aceite explícitos.
  • ●Alinhamento — humano e agente leem o mesmo contrato.
  • ●Custo menor — menos retrabalho e ACUs gastos.
  • ●Auditabilidade — quem decidiu o quê, quando, por quê.

Anatomia de uma Spec

As 6 seções que toda demanda deve ter:

  • 01Contexto

    Por que essa demanda existe? Qual o problema de negócio?

  • 02Requisitos funcionais

    Comportamento observável esperado, em linguagem de produto.

  • 03Regras técnicas

    Padrões, naming, convenções, integrações e limites técnicos.

  • 04Limites (out-of-scope)

    O que não deve ser tocado, alterado ou criado.

  • 05Critérios de aceite

    Testáveis, mensuráveis. "Done" significa o quê, exatamente?

  • 06Guardrails de segurança

    Sem deploy direto, sem destructiveChanges, sem JWT, ownership respeitado.

Template SDD (markdown)

specs/<ticket>.md 
# SPEC: [TICKET-123] Validação de desconto em pedidos B2B

## 1. Contexto
Pedidos B2B com desconto acima de 30% precisam de aprovação automática
do gerente regional. Hoje a regra é manual e gera atrasos.

## 2. Requisitos funcionais
- Disparar fluxo de aprovação ao salvar Order com Discount__c > 30.
- Notificar o Owner_Manager__c via email quando aprovação for solicitada.
- Bloquear alterações em Status enquanto aprovação estiver pendente.

## 3. Regras técnicas
- Trigger: OrderTrigger (já existe — apenas estender via handler).
- Padrão: "Trigger Handler Pattern" conforme /playbooks/02_apex.md.
- Cobertura mínima de testes: 85%.

## 4. Limites (out-of-scope)
- NÃO modificar Profiles, Permission Sets ou Layouts.
- NÃO criar novos objetos — apenas Custom Field Discount__c.
- NÃO tocar em metadata fora de CommercePricing.

## 5. Critérios de aceite
- [ ] Order com desconto > 30% inicia approval automaticamente.
- [ ] Email enviado em até 60s.
- [ ] Testes Apex passando com ≥ 85% de cobertura.
- [ ] check-metadata-ownership.py aprovado.

## 6. Guardrails
- Auth: sf org login web apenas.
- Deploy: --check-only em sandbox; promoção via Flosum.
- Sem destructiveChanges. Sem JWT. Sem snapshot completo.

Como o Devin interpreta cada seção

  • Contexto → calibra o tom e o escopo.
  • Requisitos → gera tarefas (todo plan).
  • Regras técnicas → escolhe padrões certos.
  • Limites → evita arquivos fora do escopo.
  • Aceite → vira checklist de validação.
  • Guardrails → bloqueia ações destrutivas.
⚠ Anti-pattern: "Crie uma LWC de pedidos." → vago, ambíguo, custo alto. Sempre escreva uma Spec.

Framework

O Framework SDD + Agentic em 6 etapas

Um ciclo ensinável. Você pode aplicar amanhã, em qualquer feature Apex/LWC. Cada etapa tem objetivo claro, ação concreta e resultado esperado — nada é opcional.

1 Etapa 01

Definição de contexto

Antes da Spec, o contexto.

Objetivo
Garantir que o agente saiba onde está atuando.
Ação
Atualizar knowledge-base/: ownership, org-inventory, pipeline-map.
Resultado
Agente consegue raciocinar sobre fronteiras e padrões do time.
2 Etapa 02

Criação da specification

O contrato vira artefato.

Objetivo
Capturar contexto, requisitos, regras, limites, aceite e guardrails.
Ação
Escrever specs/<ticket>.md seguindo o template SDD.
Resultado
Documento versionado, revisável, ensinável e reusável.
3 Etapa 03

Interação com o agente (Devin)

Direção, não digitação.

Objetivo
Delegar a implementação amarrada à Spec e a um playbook.
Ação
Prompt curto: "Leia specs/X.md, aplique playbooks/02_apex.md, atue só em force-app/...".
Resultado
Branch devin/<ticket>-<slug> com código + testes.
4 Etapa 04

Validação

Confiança baseada em evidência.

Objetivo
Provar que a entrega cumpre os critérios de aceite e guardrails.
Ação
Rodar check-metadata-ownership.py, --check-only em sandbox, testes Apex.
Resultado
Validações verdes ou falha clara para a próxima iteração.
5 Etapa 05

Iteração

Spec evolui antes do código.

Objetivo
Quando algo falha, refinar a Spec antes de pedir mais código.
Ação
Atualizar Spec → re-prompt curto → revalidar. Nunca itere "no escuro".
Resultado
Convergência em poucas iterações, sem queima de ACUs.
6 Etapa 06

Deploy via Flosum

O agente nunca promove.

Objetivo
Promoção governada QA → PreProd → Prod.
Ação
PR aprovado → merge na main → Flosum executa promoção via webhook.
Resultado
Deploy auditável, com Smart Merge resolvendo overlaps entre times.

O loop

Etapas 1→6 não são lineares: 4 e 5 formam um loop curto de validação

O caminho linear é Contexto → Spec → Devin → Flosum. Mas Validação e Iteração formam um loop fechado: toda falha alimenta refinamento da Spec antes de pedir mais código ao agente.

01 Contexto 02 Spec 03 Devin 04 Validar 05 Iterar loop curto refina Spec 06 Flosum → Prod aceite ✓
Linear (preparação) Execução do agente Loop de validação/iteração Promoção governada

Aplicação prática

Exemplo concreto: criação de uma feature Apex + LWC

Cenário real. Mesmo agente. Mesma feature. Duas abordagens. Uma delas explode em débito técnico em três sprints; a outra entrega previsível desde o primeiro dia.

Cenário

Aprovação automática de pedidos B2B com desconto > 30%

Pedidos B2B com desconto acima de 30% precisam disparar um fluxo de aprovação para o gerente regional. Há uma LWC no detalhe da Order que precisa exibir o status em tempo real e bloquear edição enquanto pendente.

Abordagem SEM SDD

Anti-pattern

Prompt típico

O prompt abaixo é intencionalmente exagerado para tornar o contraste didático — mas variações menos óbvias do mesmo padrão (escopo vago, sem limites explícitos) produzem os mesmos problemas em escala menor. 

# Prompt vago e ambíguo
"Faça uma aprovação automática quando o desconto
do pedido for grande. Cria uma tela bonita pra mostrar
o status, e arruma o que precisar pra funcionar."

O que acontece

  • ●Agente cria um novo objeto Approval__c (já existia um padrão!).
  • ●Mexe em Profile e Layout sem ownership — quebra outro time.
  • ●"Desconto grande" foi interpretado como > 50%, não > 30%.
  • ●LWC criada com naming inconsistente, sem testes Jest.
  • ●Cobertura Apex em 62%, abaixo do mínimo (75%) → deploy falha.
  • ●3 ciclos de retrabalho, ~4× mais ACUs gastos.
Resultado: feature meio pronta, débito técnico criado, time lateral irritado.

Abordagem COM SDD

Recomendado

Pseudo-Spec (specs/B2B-450.md) 

# SPEC: [B2B-450] Aprovação automática > 30% desconto

## Contexto
Reduzir SLA de aprovação manual em pedidos B2B.

## Requisitos
- Disparar approval quando Order.Discount__c > 30.
- LWC orderApprovalStatus no Order Page Layout.
- Bloqueio de edição em Status enquanto pendente.

## Regras técnicas
- Estender OrderTrigger via Handler Pattern.
- Reutilizar objeto padrão ProcessInstance (NÃO criar Approval__c).
- Cobertura Apex ≥ 85%; Jest ≥ 80%.

## Limites
- NÃO modificar Profiles, Layouts ou outros domínios.
- Apenas force-app/main/default/{classes,lwc,triggers}/.

## Aceite
- [ ] Order com desc > 30% inicia approval em < 60s.
- [ ] LWC mostra status em real-time (Platform Event).
- [ ] check-metadata-ownership.py verde.

Prompt para o Devin

Leia specs/B2B-450.md e playbooks/02_apex.md.
Implemente apenas em force-app/main/default/.
Rode check-metadata-ownership.py antes de finalizar.
Pare se qualquer guardrail falhar.

Resultado esperado

  • ●Branch devin/B2B-450-approval-auto com código + testes.
  • ●Reuso de ProcessInstance — sem novo objeto.
  • ●Cobertura Apex 89%, Jest 82%.
  • ●Validações verdes; PR pronto em uma sessão.
  • ●Flosum promove QA → PreProd → Prod sem intervenção.
Resultado: feature entregue, sem débito, com auditoria completa.

Lição 1

Toda ambiguidade do prompt vira retrabalho — paga-se em ACUs e em deploy quebrado.

Lição 2

Spec curta > prompt longo. 30 linhas de Spec valem mais que 300 linhas de prompt.

Lição 3

Limites explícitos protegem times vizinhos — ownership não é burocracia, é segurança.

Orquestração

Orquestrando o Devin (Web e CLI)

Você não está mais codificando. Está dando direção. O Devin é o engenheiro júnior brilhante que precisa de um Tech Lead — e esse Tech Lead é você.

Boas práticas

  • Use playbooks e referencie-os no prompt.
  • Aponte para skills reutilizáveis em .agents/skills.
  • Itere em passos pequenos; valide antes de avançar.
  • Rode --check-only na sandbox antes do PR.
  • Use Agents.md e Blueprints para fixar o ambiente.

Anti-patterns

  • Prompts vagos do tipo "faça uma LWC de pedidos".
  • Escopo gigante numa única sessão (engole ACUs).
  • Pedir deploy direto em Prod ao Devin.
  • Pedir destructiveChanges sem aprovação.
  • Salvar credenciais (JWT, refresh tokens) em qualquer arquivo.
Por que Web Login (e não JWT): a autenticação via sf org login web é adotada deliberadamente. Em sandboxes Salesforce, cada dev faz login individual, e JWT individual por desenvolvedor é inviável operacionalmente. Centralizar em um usuário sistêmico de CI/CD eliminaria a rastreabilidade de alterações por autor — informação crítica para auditoria e Smart Merge. O Web Login preserva identidade sem comprometer o pipeline.

Prompt eficaz (Web/CLI)

Curto, direcionado, ancorado em arquivos do repo.

# Bom: específico, com referências e limites
Leia specs/TICKET-123.md.
Aplique o playbook playbooks/02_apex.md.
Implemente apenas em force-app/main/default/classes/.
Valide com scripts/salesforce/validate-deploy.sh.
Pare se check-metadata-ownership.py falhar.

Prompt fraco

Custa ACU, gera retrabalho, desvia do escopo.

# Ruim: ambíguo e sem fronteiras
Faça uma melhoria no fluxo de pedidos.
Tenta deixar mais bonito também.
Se precisar, mexe no Profile pra liberar.
Faz deploy direto na QA pra ver se funciona.

Eficiência

Otimização de custos (ACUs)

Cada ciclo do Devin consome ACUs (Agent Compute Units). Engenheiros experientes economizam dezenas de ACUs apenas escrevendo Specs melhores e validando localmente antes de delegar.

Regra de ouro: tudo que o seu laptop pode validar (lint, sintaxe, ownership), valide antes de pedir ao Devin.

Dica #1

Evite loops de fix

Se o Devin tenta corrigir o mesmo erro 2x sem progresso, pare. Refatore a Spec.

Dica #2

Sem guesswork

Forneça nomes de campos, paths e exemplos. Adivinhação custa caro.

Dica #3

Lint local primeiro

Rode prettier, eslint e os scripts de validação antes do agente.

Dica #4

Sessões focadas

Uma Spec por sessão. Evite "while you're at it..." — vira escopo infinito.

Dica #5

Use Blueprints

Ambiente pré-configurado evita reinstalações a cada sessão.

Dica #6

Knowledge-base rica

Inventário, ownership e pipeline documentados reduzem perguntas e erros.

Pipeline ponta a ponta

O Fluxo de Trabalho

Da Spec ao deploy em Produção, sem atalhos perigosos. Esta é a sequência canônica.

  1. 1

    Criação da Spec

    Time/Tech Lead descreve a demanda em specs/<ticket>.md seguindo o template SDD.

  2. 2

    Setup de ambiente

    Rode os scripts de bootstrap localmente.

    # Setup local + autenticação Web
bash scripts/environment/setup.sh
bash scripts/environment/authenticate-orgs.sh
sf org login web --alias qa
  3. 3

    Desenvolvimento via Devin

    Local (Devin CLI) ou Web. O Devin lê a Spec, executa playbooks e codifica em force-app/.

  4. 4

    Validação & testes

    Check-only na sandbox + validações de ownership e destructive changes.

    python scripts/validation/check-metadata-ownership.py
python scripts/validation/check-destructive-changes.py
sf project deploy start --check-only --target-org qa
bash scripts/salesforce/run-tests.sh
  5. 5

    Sincronização via Flosum CLI

    Pacote package-deploy.xml entra no Flosum, que cuida da promoção QA → PreProd → Prod.

    # Apenas após PR aprovado e merge na main
npx @flosum/cli branch sync --branch <feature-branch>
npx @flosum/cli package deploy \
  --manifest manifest/package-deploy.xml
    ⚠ O Devin não executa esta etapa em ambientes compartilhados — Flosum é o deployer oficial.

Repositório

Estrutura do Repositório (modelo de referência)

O repositório github.com/issei/sf-repo é o template oficial. Use-o como ponto de partida (fork ou clone) — assim os playbooks e skills essenciais já vêm pré-configurados para orquestrar o Devin de imediato. 

sf-repo/
├── CLAUDE.md            # Instruções base ao agente
├── .agents/
│   └── skills/          # Componentes modulares reutilizáveis
├── knowledge-base/     # A "memória" do Devin
│   ├── metadata-ownership.yaml
│   ├── org-inventory.md
│   └── flosum-pipeline-map.md
├── playbooks/          # SOPs determinísticos
│   ├── 01_setup.md
│   ├── 02_apex.md
│   └── 03_promotion.md
├── scripts/            # Ferramentas locais (bash/python)
│   ├── environment/
│   ├── salesforce/
│   ├── validation/
│   └── reporting/
├── specs/              # Demandas de negócio (entrada principal)
│   └── TICKET-123.md
├── force-app/          # Código Salesforce
└── manifest/
    └── package-deploy.xml
/knowledge-basecontexto persistente

Inventário de orgs, mapa do pipeline Flosum e ownership por domínio. É a primeira coisa que o Devin lê.

/playbooksexecução determinística

Procedimentos passo a passo. Quando o agente referencia um playbook, ele segue uma SOP testada.

/specsentrada principal

Onde mora a demanda. A Spec é o input #1 do Devin para qualquer sessão.

/.agents/skillsreutilização

Skills modulares que o agente combina para tarefas recorrentes (ex: gerar testes Apex, validar pacote, gerar relatório).

Adotando o template

  1. Faça fork de issei/sf-repo para o seu time.
  2. Atualize knowledge-base/metadata-ownership.yaml com o domínio do time.
  3. Configure orgs em org-inventory.md e o pipeline em flosum-pipeline-map.md.
  4. Pronto: o Devin já entende o seu contexto desde a primeira sessão.

Governança

Ownership, fronteiras e checklist

Em um modelo federado, ownership de metadata é sagrado. Violar uma fronteira = metadata trampling = deploy quebrado para outro time.

Quem pode alterar o quê

Custom Objects & Fields

Apenas o time owner do domínio (ex: CommercePricing).

Apex Classes

Time owner; convenções de naming por namespace lógico.

Flows

Apenas após validação de impacto cruzado entre times.

Profiles & Layouts

Componentes compartilhados — Smart Merge do Flosum obrigatório.

Estratégias de isolamento

  • ● Ownership por domínio declarado em metadata-ownership.yaml.
  • ● Naming conventions com prefixo do time/domínio (ex: CP_OrderTrigger).
  • ● Namespace lógico separando classes, objects, layouts e LWCs.
  • ● Validação automatizada via check-metadata-ownership.py antes do PR.
Consequência da violação: metadata trampling — outro time descobre, em um deploy futuro, que seus componentes foram sobrescritos. Resultado: rollback emergencial, retrabalho e perda de confiança no pipeline.

Checklist do Desenvolvedor

interativo

Marque conforme avança — funciona como guia rápido.

Quem está por trás

Autoridade, contexto real e aprendizados práticos

Este framework não nasceu em slide. Foi destilado de experimentações reais com times Salesforce, agentes autônomos e pipelines Flosum em produção. O que está aqui é o que funcionou — e o que custou caro para descobrir.

Contexto real

Onde este framework foi forjado

  • ▸
    Múltiplos times compartilhando QA, PreProd e Prod, cada um com seu domínio de metadata.
  • ▸
    Legado relevante: triggers e fluxos vivos há anos, com dependências escondidas.
  • ▸
    Devin em produção, lendo Specs reais, executando playbooks e abrindo PRs.
  • ▸
    Flosum como SoT, com Smart Merge resolvendo overlaps entre times.

Aprendizados

O que custou caro descobrir

  • ✓
    Toda Spec ambígua vira retrabalho — sempre. Não há prompt longo que compense Spec frouxa.
  • ✓
    Ownership por domínio é a única defesa real contra metadata trampling.
  • ✓
    Confiar cegamente no agente custa o dobro: em ACUs e em rollback.
  • ✓
    Knowledge-base rica reduz o número médio de iterações de 5 para 1–2.
  • ✓
    Quem promove é o Flosum. Sempre. Sem exceções.

Onde este conteúdo se posiciona

A maior parte dos conteúdos sobre IA + desenvolvimento foca em prompts mágicos. Esta abordagem foca em engenharia: contratos, fronteiras, validação, governança. É o que diferencia entrega previsível de "demo bonita que quebra na quinta-feira". Se você é Tech Lead, Arquiteto ou Senior em Salesforce, é um processo que funcionou nesse contexto — e está testado em campo.

O futuro

De codificadores a Agentic Tech Leads

O futuro do Salesforce não é digitar XML mais rápido. É orquestrar Specs, Skills e agentes para entregar valor de negócio com governança real. O ferramental está pronto. A próxima escolha é sua.

Links oficiais

Devin

Devin CLI · Documentação

cli.devin.ai/docs

Devin

Blueprints

docs.devin.ai/onboard-devin/environment/blueprints

Devin

Blueprint Reference

docs.devin.ai/.../blueprint-reference

Devin

Agents.md

docs.devin.ai/onboard-devin/agents-md

Flosum

Flosum CLI (Node.js)

docs.flosum.com/.../flosum-cli-node.js-package

Salesforce

Salesforce CLI (sf)

github.com/salesforcecli/cli

Salesforce

Web Login (auth flow oficial)

developer.salesforce.com/.../sfdx_dev_auth_web_flow.htm

Template

issei/sf-repo (referência)

github.com/issei/sf-repo

Aprofundamento em áudio

Debate: a transição para orquestrador de agentes IA

Um debate de 22 minutos que reforça e aprofunda toda a ideia apresentada neste material — a mudança de mentalidade de "quem digita código" para "quem orquestra agentes", aplicada ao contexto Salesforce com SDD, Devin e Flosum.

Episódio único · 22 min

A transição para orquestrador de agentes IA

Reforço auditivo da tese central deste portal.

Baixar áudio (.m4a) Abrir em nova aba