An AL extension written by an agent: what the review must catch

An AI agent can write AL, compile it against your symbols and publish it to a sandbox environment. The code usually works. That is exactly why the review matters.

This page is the checklist a consultant should run before agent-written AL reaches a production environment, ordered by what costs the most when it is wrong.

What can an agent do in AL today?

More than most teams expect. The 2026 release wave 1 plan lists six items for this work:

• AI agent tools for AL development
• An AL MCP server for troubleshooting
• Attach to and debug Business Central agent sessions
• AL tests that run from Visual Studio Code
• Symbol download from a NuGet feed
• BC-Bench, for evaluating AL coding agents

A practical loop looks like this. A person describes the change. The agent reads the symbols, writes the objects, compiles, publishes to a sandbox and runs the tests. The person tries it, corrects it, and the agent goes round again.

What the loop does not include is judgement about your production environment. That is the reviewer's job, and it does not get smaller because the code got easier to produce.

Why is review not optional?

Because the failure mode changed.

A junior developer writes code that does not compile and code that is obviously wrong. Both are cheap to catch. An agent writes code that compiles, passes its own tests, and does the wrong thing in a way that reads as deliberate.

The second kind of error is more expensive, and it is invisible to the checks that catch the first kind.

The review checklist

Work down this list. The order is by cost of being wrong, not by ease of checking.

1. Anything that touches posted data

Look first at every write to a posted table, every subscriber on a posting codeunit, and any use of COMMIT inside a posting flow. An agent that "improves" posting has produced the most expensive class of defect in Business Central, because the damage is in the ledger and the ledger is the record.

Treat a change to posting as a change that needs a written reason, a test and a second reader.

2. Permissions

New objects need permission sets. An agent frequently writes the objects and forgets the permissions, or grants more than the feature needs.

Check that each new table and page is in a permission set, that the set matches the job, and that nothing was added to a wildcard set for convenience.

3. Upgrade and data migration

This is the most reliably missing piece. A new field with a default value, a changed field type, or data that has to be moved needs upgrade code. Without it, the extension installs cleanly on a sandbox with no data and fails on a production environment with five years of it.

Ask directly: what happens to existing rows? If the answer is not in the code, the work is not finished.

4. Object ranges, naming and namespaces

Check that object IDs are inside the range you own, that names follow your convention with the right prefix, and that namespaces are set. These are cheap to fix now and expensive to fix after the extension is published.

5. Performance

Look for the loop that should have been a query, missing SetLoadFields, a FlowField used inside a loop, and any filter on a field with no supporting key.

An agent optimises for correct output on the data it can see. Your production data is larger than that, and the cost only appears at scale.

6. Error handling

Check that errors are not swallowed. A TryFunction whose failure is ignored turns a loud failure into a silent wrong result, which is the worse of the two.

Check that error messages name the record and the reason, because these messages appear in telemetry as RT0030 and a vague message wastes the next person's hour.

7. Translation and captions

Confirm that every caption is translatable and that no user-facing string is hardcoded in one language. For a Danish or German customer this is not a finishing touch. It is the difference between a usable page and a bilingual mess.

8. Tests

Ask what the tests actually assert. Agent-written tests have a tendency to assert that the code ran rather than that the result is right.

One test that checks a computed figure against a known value is worth ten that check for no error.

What agents get wrong most often

From our own review work, in rough order of frequency:

1. Missing upgrade code for new or changed fields.
2. Permission sets that were never created.
3. A subscriber that runs on every posting when it should run on one document type.
4. Filters that cannot seek, on tables where it matters.
5. Captions that are not translatable.
6. Tests that assert nothing useful.
7. Confident use of a pattern from an older Business Central version.

Item 7 is worth watching. Agents learn from published code, and a lot of published AL is old. A pattern that was correct in an earlier version can be deprecated now, and it still compiles.

How to make review cheap

The review is the bottleneck, so design for it.

Keep sessions small. One change per session. A session that touches six areas cannot be reviewed properly and will be approved anyway.

Require a sandbox. Nothing reaches production directly. The agent publishes to a sandbox, a person tries the change, and only then does a consultant review the code.

Put a budget on the session. A ceiling set before the session starts stops an agent from spending an hour on the wrong approach.

Make the diff the unit of review. Review the change, not the file. A reviewer who has to read the whole object will skim it.

Keep the rules in one place. A written set of quality rules that both the agent and the reviewer use turns review from opinion into checking. The agent reads the same rules before it writes.

The point of the loop

The value is not that the code is free. The value is that the person who understands the business process can express the change themselves, and the consultant spends their time on judgement instead of typing.

That trade works only if the review is real. An agent-written extension that nobody read is a production change nobody read, and the tooling that made it easy is not a defence.