AI assistants and X++: what works and what is still limited
What a general-purpose AI assistant can do in X++ for D365 F&O, what it lacks (context, compilation, security, tests) and how to close the gap.
The short answer
A general-purpose AI assistant quickly produces correct X++ for well-documented patterns: Chain of Command, SysOperation classes, RDP reports, data entities, queries. Its limits come less from the language than from context: without access to your code it ignores your extensions, prefixes, roles and volumes; without a compiler or BP check it does not know whether its code compiles; without an environment it cannot run tests. The value therefore lies in what surrounds the model: the context it gets and the checks applied afterwards.
What works well
- Repetitive patterns publicly documented on Microsoft Learn: table and form extensions, Chain of Command, SysOperation, RDP/Contract, business events, OData actions.
- Writing the specification from a business request, and listing the objects involved.
- SysTest test skeletons and the edge cases to cover.
- Explaining existing code, provided you supply it.
See for example SysOperation batch step by step or SSRS report with RDP and Contract classes: these are stable patterns.
What is still limited
- Your context: custom objects, conventions, models and dependencies. Without them, code is generic.
- The version: APIs change with updates; a model may suggest a deprecated method or a signature that does not exist.
- Verification: compiling, passing the BP check, synchronising the database and running tests require Microsoft's tools and an environment.
- Security and performance: roles to create, real volumes, indexes; these are architecture decisions.
- Accountability: approving a development remains a human decision.
Microsoft even documents that, for agents acting in F&O, the choice of orchestration model clearly changes result quality: the model is not everything, the tooling around it matters as much.
How to close the gap?
Provide the context (repository code, conventions), tool up verification (build, BP check, tests) and keep a pull-request review. That is what our checklist for reviewing AI-generated X++ and the chain of quality gates describe.
At Skalp AI, the agent generates the X++ code and its unit tests, compiles with a best-practice check, then pushes a pull request to the customer's Azure DevOps project with screenshots of the tests. Nothing reaches the working branch without the customer's technical architect reviewing and approving the pull request. For the comparison with Copilot, see Skalp AI vs Copilot for D365; pricing: Basic, Pro and Max plans (1 credit, ≈ €400 on Basic, €200 on Pro, consumed only when the code is generated).
See also: X++ development in 2026: AI or X++ developer and AI X++ development.
Sources
- Microsoft Learn, "Build an agent with Dynamics 365 ERP MCP", updated 5 Mar 2026, accessed 18 Oct 2026.
- Microsoft Learn, "Customization Analysis Report (CAR)", updated 26 Feb 2026, accessed 18 Oct 2026.
- Microsoft Learn, "Testing and validations", updated 29 Apr 2026, accessed 18 Oct 2026.
Frequently asked questions
Can an AI assistant write correct X++?
Yes for well-documented patterns. Correctness in your context (objects, conventions, security, volumes) requires giving it that context and checking the result.
Why doesn't generated code always compile?
The model does not see your metadata or exact package versions, and does not run the compiler by itself. A tooled build step is needed.
Should X++ developers be banned from AI assistants?
No: properly framed (context, checks, review), they speed up repetitive tasks. The framework matters more than the tool.
Ready to transform your D365?
Join the CIOs who develop their D365 tickets in 2–4 h for 1 credit (≈ €400 on Basic, €200 on Pro).