In June 2026 our team made a simple decision. We would use Claude in real Dynamics 365 Finance & Operations development work. Not in a demo project, but in the customer's development environment, on real requests. Five months have passed. In this post we describe what we have seen along the way, and we try not to exaggerate.
The first week: "Does it actually know X++?"
Our first impression was mixed. Claude knew general X++ syntax, but it stumbled on the parts that are specific to F&O. The kind of mistakes anyone who develops on F&O will recognise: leaving out the next call when extending a method with Chain of Command, or referring to a data source that does not exist in a form extension. Code like that either fails to compile or compiles and then behaves wrongly. The second case is the more dangerous one.
We soon realised the problem was not the model's intelligence. It was context. Claude does not know Microsoft's standard code by heart, and it knows nothing at all about the customisations our customer had built up over the years. Put a person on a project with that little context and they will make similar mistakes.
We built the context ourselves
Over the following weeks, most of the work went into giving Claude the right knowledge. Today we work with three layers:
- Microsoft's standard code. We split the X++ source of the Application Foundation, Platform and Common packages into chunks and put them in a local vector database. More than 140,000 chunks in total. Instead of guessing how a standard class works, Claude goes and looks.
- The customer's own customisations. A catalogue of the customer-specific objects sits in a separate collection. Claude also reads the code in the development environment directly while it works.
- Our own experience. Each developer's Claude sessions write the lessons they learn to a shared repository. The next session starts with that repository.
This third layer turned out to matter far more than we expected. We will come back to it shortly.
The biggest time saving is in reading, not writing code
From the outside, it looks as if AI's main contribution is writing code. That was not our experience. The real difference showed up in understanding the existing system.
When a new request arrives in an F&O environment that has been developed for years, the first question is always the same: "Is this already done somewhere? Which tables does it touch? What could I break?" Answering it used to cost a developer half a day of searching through objects. Now Claude scans the relevant tables, forms and classes and prepares an analysis document. The analyst reads it and either approves or corrects it. Only then is any code written.
We keep this order on purpose: no code before the analysis is approved. Because AI can produce code so quickly, it is also very easy to build neat but wrong code on top of a misunderstood request. The approval step is the cheapest protection against that.
When lessons get lost, the same mistake comes back
Everyone who develops on F&O knows the small traps: a field that disappears after synchronisation, a model that fails unless it is built in a certain order, a data provider class that behaves unexpectedly in an SSRS report. None of this is in the documentation. It lives in people's heads.
When we started working with AI, this problem got bigger. Claude would fall into a trap in one developer's session and find its way out, and the next day it would fall into the same trap in another developer's session. The sessions knew nothing about each other.
Our answer was a shared experience repository. At the start of every session the repository is pulled, and at the end new lessons are added. Today it covers more than a hundred topics: X++ traps, build and synchronisation problems, lessons on forms and reports, team rules. There is no formal approval process, but there is one rule: a lesson is checked against the source before it is written, and an outdated lesson is corrected or deleted.
What we do not leave to Claude
After five months our limits are also clear:
- Builds, database synchronisation and testing are done by people.
- Check-in to source control and go-live are the team's decision.
- There is no write access to production. Production is only looked at, when needed, to read something.
This is less a technical necessity than a matter of trust. Our customer's production system is our responsibility, and we do not want to hand that responsibility to a tool.
Something we did not measure
We have deliberately left one number out of this post: "we got this much faster". We did not measure it. We have a feeling, but presenting a feeling as a number would be wrong. We will start measuring on upcoming work, and if something meaningful comes out of it, we will write about that too.
For now, this is what we can say: Claude is a good colleague. But only when you feed it the right knowledge, and inside a process where you set the rules.