Email this post as a PDFAI and agents · 5 November 2026 · 2 min read

AI-assisted AL development in practice: what it speeds up and what still needs a person

Coding agents now understand AL symbols, allocate object IDs, debug recorded failures and profile slow sessions. What that actually speeds up day to day, where it gets things wrong, and the review habits that keep AI-written code up to your standards.

Contents
  1. What it genuinely speeds up
  2. Where it gets things wrong
  3. The review habits
  4. What doesn't change

Business Central 29 made AI agents a supported part of the AL toolchain: language intelligence for agents and other editors, AL MCP server tooling, object ID allocation, debugging of recorded failures and profiling of slow sessions (see agentic AI in BC). Here's what that means at the keyboard.

What it genuinely speeds up

  • Scaffolding. A table extension with five fields, captions, tooltips and data classification; a page extension placing them; an API page over a table. Minutes instead of half an hour.
  • Boilerplate patterns. Install and upgrade codeunits with upgrade tags, permission sets, a interface-and-enum skeleton.
  • Reading unfamiliar code. "Explain what this ISV's codeunit does when a sales order is released." Very good, and a huge help on rescues and NAV upgrades.
  • Tracing events. Finding every subscriber to an event across a workspace and what each does.
  • Tests. Drafting test codeunits with Given-When-Then structure and library calls (test patterns).
  • Debugging and profiling. Working through a recorded failing session or a slow trace and pointing at the likely cause.
  • Converting old code. Mapping C/AL modifications into what they'd be as extensions (NAV upgrades).

Where it gets things wrong

  • Plausible but outdated patterns. Old APIs, obsolete procedures, option fields instead of enums, string literals instead of labels.
  • Events that don't exist, or the wrong signature for one that does. The compiler catches some; not all.
  • Performance blind spots. Loops with Gets inside, missing SetLoadFields (performance mistakes).
  • Field lengths and types that don't match the base fields they copy into (overflow errors).
  • Design decisions. It will happily build the customisation you asked for. It won't tell you the business shouldn't have it.

The review habits

  1. Treat AI-written code like a junior developer's pull request: read every line.
  2. Run the analysers (CodeCop, UICop, PerTenantExtensionCop/AppSourceCop) with warnings as errors in the pipeline.
  3. Check against your standards: labels, naming, namespaces, data classification.
  4. Run the tests, and write the ones it didn't.
  5. Check performance on realistic data volumes.
  6. Never let it publish to production; it goes through the pipeline like everything else.

What doesn't change

Someone still has to decide whether a customisation should exist, where it belongs, how it fits the data model, and whether it'll survive the next release. AI makes the typing faster. The judgement is still the job.

Email this post as a PDF
A branded PDF of this post, sent to your inbox to keep, print or share. Copy in colleagues if you like.
We only use these addresses to send this PDF. Nobody is added to a mailing list. Mike at Business Boxed receives a copy. See our privacy notice.
Email this post
Talk to us
Want this done in your Business Central?
Book a 30 minute callGet the monthly newsletter

Related posts