O desenvolvedor Microsoft Dynamics 365 Finance & Operations (D365 F&O) não vai deixar de escrever X++.
Mas cada vez mais vai desenhar comportamentos, instruções, validações, ferramentas e agentes.
Essa é uma mudança maior do que parece.
Durante anos, o trabalho técnico em D365 F&O foi associado a X++, extensões, Chain of Command, eventos, data entities, batch jobs, integrações, relatórios, performance, segurança e deploy em ambientes controlados.
Tudo isso continua sendo importante. Na verdade, fica ainda mais importante.
O que muda é o centro de gravidade.
Com GitHub Copilot, Copilot Studio, Microsoft Foundry, Model Context Protocol (MCP) e agentes conectados ao ERP, o desenvolvedor deixa de entregar apenas código. Ele passa a desenhar uma camada de comportamento: como a IA recebe contexto, quais ferramentas pode chamar, quais validações devem bloquear uma ação, quais evidências precisam ser registradas e onde a decisão humana continua obrigatória.
O novo ciclo de desenvolvimento no D365 F&O não começa e termina no X++. Ele passa por X++, prompt, contexto, ferramenta, permissão, validação, teste, observabilidade e governança.
X++ continua sendo a base do ERP
Antes de falar de IA, vale cortar um exagero comum: a IA não elimina o desenvolvimento D365 F&O.
O D365 F&O continua sendo um ERP empresarial, transacional, crítico e fortemente ligado a regras de negócio. Processos como compras, contas a pagar, contas a receber, estoque, fiscal, projetos, manufatura, fechamento contábil, conciliação bancária, orçamento e integrações ainda precisam de uma base técnica sólida.
E essa base passa por X++.
A documentação da Microsoft descreve X++ como uma linguagem orientada a objetos, consciente da aplicação e dos dados, usada em programação ERP e aplicações de banco de dados. Ou seja: X++ não é apenas uma linguagem antiga que sobrou no produto. É parte da forma como o ERP expressa regra de negócio.
Quando falamos de IA no D365 F&O, não estamos falando de substituir essa base por prompts. Estamos falando de construir uma nova camada sobre ela: modelos de linguagem, agentes e ferramentas que consultam dados, chamam ações, explicam processos, sugerem correções, apoiam revisão e reduzem trabalho repetitivo.
No ERP, prompt sem X++ vira conversa. X++ sem contexto pode virar código correto para o problema errado.
Do ciclo antigo ao novo ciclo
O ciclo tradicional era conhecido: entender o requisito, localizar o objeto padrão, decidir extensão ou customização, escrever X++, compilar, testar, validar, empacotar, subir para ambiente, corrigir defeitos e documentar.
Esse fluxo continua existindo, mas agora ganha novas etapas. No ciclo com IA, o desenvolvedor também precisa formular contexto para a IA, orientar o Copilot com padrões do projeto, revisar código gerado, transformar regras em instruções reutilizáveis, decidir quando uma ação deve virar ferramenta de agente, validar permissões, testar prompts e medir comportamento.
Menos código repetitivo, mais atenção ao que importa
O primeiro impacto é claro: tarefas repetitivas tendem a diminuir.
Copilots e agentes já ajudam em atividades como explicar código legado, gerar estruturas iniciais, sugerir nomes, criar comentários, escrever documentação técnica, preparar exemplos de testes, revisar padrões de Chain of Command, apontar riscos de performance, resumir classes grandes e transformar erro técnico em explicação funcional.
Isso não significa aceitar tudo que a IA sugere. Significa gastar menos energia digitando estruturas previsíveis e mais energia avaliando se a solução faz sentido.
Em D365 F&O, o ganho real não é “escrever mais rápido”. É liberar atenção para revisar melhor.
Revisão vira competência central
O novo desenvolvedor D365 F&O será cada vez mais revisor. Isso parece menos glamouroso do que gerar código, mas é onde mora a maturidade.
Quando a IA sugere X++, o desenvolvedor precisa perguntar se a solução respeita extensibilidade, Chain of Command, integridade transacional, performance, empresa legal, moeda, dimensão financeira, localização, permissões, exceções e impacto funcional.
Um modelo pode sugerir uma solução tecnicamente convincente e ainda assim errar o desenho ERP. Pode criar uma consulta que funciona em volume baixo, mas falha em produção. Pode sugerir uma atualização direta onde deveria existir regra de negócio. Pode ignorar workflow, alçada, auditoria ou fechamento contábil.
No D365 F&O, revisar IA não é procurar apenas erro de sintaxe. É revisar consequência operacional.
public void validateVendor(VendTable _vendor)
{
ttsbegin;
this.checkBankAccount(_vendor);
this.checkWorkflowStatus(_vendor);
ttscommit;
}
Revisão assistida por IA
Validar se a ação altera dado sensível de fornecedor.
Confirmar menu item, papel de segurança e segregação de funções.
Revisar transação, exceções, log e evidência de auditoria.
Adicionar teste funcional para aprovação e bloqueio.
Contexto passa a ser parte da engenharia
O trabalho com IA melhora quando o contexto melhora. Isso vale para qualquer área, mas no D365 F&O é crítico.
Um prompt técnico fraco diz: “gere uma classe X++ para validar fornecedor”. Um prompt útil explica módulo, processo de negócio, tabela ou entidade, evento esperado, regra funcional, impacto fiscal ou financeiro, padrão de extensão permitido, volume, permissões, ambiente, critérios de teste e comportamento esperado em exceção.
Essa é uma nova competência: desenho de contexto.
Teste deixa de ser etapa final
IA aumenta a velocidade de produção. Isso torna testes ainda mais importantes.
No D365 F&O, testar não é apenas verificar se o código compila. É validar regra funcional, cenário feliz, exceções, volume, performance, segurança, permissões, integração, dados mestres, impacto contábil, impacto fiscal, workflow, rollback e regressão.
Se a IA ajuda a gerar código ou sugerir mudança, ela também deve ajudar a pensar em testes. Mas a decisão final continua humana. A IA pode sugerir testes; o desenvolvedor precisa saber quais testes provam o comportamento no ERP.
X++ começa a encontrar agentes
O MCP muda bastante a conversa.
Segundo a documentação da Microsoft, o Dynamics 365 ERP MCP server fornece uma estrutura dinâmica para agentes realizarem operações de dados e acessarem lógica de negócio das finance and operations apps.
As ferramentas são organizadas em três categorias: data tools, para operações de dados; form tools, para interações com páginas e ações disponíveis no cliente; e action tools, para encontrar e invocar classes no código das finance and operations apps.
Esse último ponto é especialmente relevante para desenvolvedores. Se uma classe X++ pode virar uma action tool, o desenvolvedor não está mais escrevendo código apenas para telas, batchs ou integrações tradicionais. Ele pode estar escrevendo lógica que um agente vai chamar.
Segurança vira preocupação diária
Quanto mais IA entra no ERP, mais segurança vira parte do trabalho técnico.
A documentação do MCP para finance and operations apps deixa claro que o contexto do agente é atualizado dinamicamente com base em permissões de segurança, configuração, extensões e personalizações do ambiente. Também explica que o papel de segurança do usuário autenticado determina quais objetos aparecem no modelo de visão retornado ao agente.
Um agente não deveria conseguir ver ou executar aquilo que o papel de segurança não permite. Mas isso exige que ferramentas, extensões e ações sejam desenhadas corretamente.
O desenvolvedor precisa pensar se a classe expõe dado sensível, se a ação altera registro crítico, se o menu item protege a execução, se existe validação no servidor, se há log suficiente, se a ação respeita segregação de funções e se existe aprovação humana quando necessário.
Observabilidade vira parte da entrega
Quando uma customização tradicional falha, normalmente o time técnico procura erro em log, batch, integração, evento, consulta, transação ou ambiente.
Com agentes, isso continua existindo, mas ganha novas perguntas: qual prompt foi usado, qual contexto foi enviado, quais dados o agente conseguiu consultar, qual ferramenta foi chamada, qual usuário estava autenticado, qual papel permitiu a ação e qual validação bloqueou ou liberou a execução.
Conhecimento funcional fica mais valioso
O desenvolvedor D365 F&O que só sabe código terá dificuldade na era da IA.
Parece contraditório, mas é o contrário: quanto mais IA ajuda a escrever código, mais valioso fica o desenvolvedor que entende processo.
A IA pode sugerir implementação, mas não sabe sozinha qual exceção fiscal importa para a empresa. Não sabe que um campo de fornecedor tem impacto em pagamento. Não sabe que uma alteração em pedido afeta orçamento, estoque, aprovação e integração. Não sabe que uma regra aparentemente simples precisa respeitar fechamento contábil.
Ela só sabe se alguém fornecer contexto, dados, regras e validações.
O prompt vira artefato de desenvolvimento
Em muitos times, prompts ainda são tratados como mensagens soltas. Isso não escala.
Quando um prompt começa a ser usado repetidamente para revisar X++, gerar testes, explicar código, documentar mudança, criar checklist funcional ou orientar um agente, ele vira artefato. E artefato precisa de versão, revisão e melhoria.
O GitHub Copilot Agent Mode no Visual Studio permite que a IA receba uma tarefa em linguagem natural, crie plano, edite código, execute comandos e itere a partir de resultados. O suporte a MCP permite conectar ferramentas externas ao fluxo agêntico.
Ou seja: o prompt deixa de ser uma pergunta. Ele começa a virar uma interface de trabalho.
O novo ciclo de desenvolvimento
O que muda na carreira do desenvolvedor
O desenvolvedor D365 F&O da era da IA não precisa abandonar X++. Precisa expandir o repertório.
As novas competências incluem engenharia de prompts, revisão de código gerado por IA, desenho de contexto, arquitetura de agentes, MCP e tools, segurança aplicada a agentes, observabilidade, testes assistidos por IA, documentação viva, conhecimento funcional profundo, governança de dados e comunicação com áreas de negócio.
Esse perfil fica mais valioso porque fala duas línguas: a língua do ERP e a língua da IA.
Ele entende que o objetivo não é apenas gerar código. É transformar regra de negócio em comportamento confiável.
Conclusão
O desenvolvedor D365 F&O não vai deixar de escrever X++.
Mas o X++ não será mais o único centro da entrega.
Cada vez mais, o trabalho vai envolver contexto, prompt, revisão, testes, ferramentas, agentes, segurança, observabilidade e conhecimento funcional.
A IA vai reduzir código repetitivo, mas vai aumentar a importância da revisão. Vai acelerar a criação, mas vai exigir mais clareza de contexto. Vai permitir agentes conectados ao ERP, mas vai exigir mais segurança e governança.
Do X++ ao prompt, o desenvolvedor que entende ERP e IA não perde espaço. Ele sobe de nível.
Fontes consultadas
- Microsoft Learn: Use Model Context Protocol for finance and operations apps
- Microsoft Learn: Get started with GitHub Copilot agent mode
- Microsoft Learn: Use MCP servers in Visual Studio
- Microsoft Learn: X++ language reference
- Microsoft Learn: X++ transactional integrity
- Microsoft Learn: Extensibility home page