AI and AL development for Business Central
AI can now write a good share of a Business Central extension. Whether that saves you time or creates work depends less on the model than on what surrounds it. This guide covers what AL development involves, where AI helps, where it goes wrong, and the safeguards that make its code safe to install.
Updated October 2026
What AL development involves
Business Central is customised through extensions written in AL, its own programming language. An extension never changes Microsoft's base application: it adds tables and pages, extends existing ones with table and page extensions, and reacts to what the application does by subscribing to its events. Developers write AL in Visual Studio Code with the AL Language extension and compile it against the symbols of the Business Central version it will run on.
The result is an .app file. A per-tenant extension is built for one company and installed in its environment; an AppSource app is published for every customer and must pass Microsoft's validation. Either way, the extension has to compile against the right version, respect its object ID range and naming rules, and be tested in a sandbox before it reaches production.
Where AI helps
The repetitive part of AL development is large, and it is where a model is fastest:
- Turning a requirement written in business language into a structured specification, and asking about what is missing.
- Writing the objects a feature needs: tables, table and page extensions, pages, reports, codeunits and event subscribers.
- Applying the same naming, structure and patterns to every object, every time.
- Producing the translation files (XLIFF) for the languages your users work in.
- Reviewing code against a written list of development rules, and explaining every finding.
Where AI goes wrong
A language model writes plausible AL, and plausible is not the same as correct. The typical mistakes are specific to Business Central: an event that does not exist in your version, a field that was renamed, an object ID outside your range, a permission set that was never updated, a report layout that refers to a column the dataset does not have.
None of these is visible from the code alone. They surface when the extension is compiled against the real symbols or, worse, when a user runs it. That is why AI-written AL needs the same checks as a new developer's code, applied every time and without exceptions.
The safeguards that make it work
What turns AI-written AL into code you can install is the process around it:
- Compile against the symbols of the target version, and repeat until it passes: code that does not compile never reaches a reviewer.
- Write your development rules down once, and check every change against them.
- Have a person approve the plan before work starts, and two different people approve a release to production.
- Anonymise customer documents before any model reads them: names, figures and addresses become placeholders.
- Keep a register of every decision that cannot be rewritten afterwards, so you can show your customer what was done and who approved it.
From request to .app: a supervised workflow
In Agentic Company the work follows the path a good team follows. An analyst agent reads the anonymised request and asks what is unclear. A planner splits the work into units and their dependencies, and a person approves the plan. Developer agents build independent units in parallel, reviewer agents check each one against your rules, and the AL compiler runs until the code compiles.
The output is an .app file to try in a sandbox and, if you use Azure DevOps, a pull request with the source. Every step that leaves the platform, from a branch to a release, passes through a gateway that applies your rules and asks the right people to sign.
An assistant in the editor, or a supervised team of agents?
A coding assistant in Visual Studio Code, such as GitHub Copilot, helps a developer who is already writing AL: it completes code and answers questions, and the developer remains responsible for everything else.
A supervised multi-agent platform takes a request from analysis to a compiled .app, with approvals and an audit trail around it. It suits a Microsoft partner who wants more throughput from the same team, and a company running Business Central that needs an extension without hiring developers. The two are not exclusive: developers can keep their assistant while the platform handles the volume.
Frequently asked questions
Can AI write a complete Business Central extension?
For many common customisations, yes: reports, fields, pages, validations, integrations and batch jobs. It works best with a clear requirement, a compiler in the loop and a person who approves the plan and the release.
Is AI-generated AL code safe to install?
Only after it has compiled against your Business Central version, passed a review against your development rules and been tested in a sandbox. Treat it like any other code that has not been reviewed yet.
Does the AI model see my customers' data?
In Agentic Company, no: requirements and guidelines are anonymised with your own dictionary before any model reads them, and the model works on placeholders.
Do I need to know AL to use it?
No. A company can describe what it needs in business terms; a partner's developers can review the plan and the code in as much detail as they want.
See it work on a real request
Open the live demo, or see the customisations companies ask for most and what the agents build for each.