It was just about 2 years ago that I started playing with the new shiny ChatGPT and tried to put its code-writing skills to the test. My experience was that while it's ability with DAX was minimally viable, it didn't fare so well when it came to writing code in AL.

Still, given that AL is a proprietary language and used only for Business Central, I was impressed that it wrote code that at least somewhat resembled AL even if the code actually failed to compile. Enamored by the fact that my conversational AI bot even knew what Business Central or AL was, I proceeded to post about it on my socials only to be swatted down by my fellow BC MVPs who weren't going to settle for what just "looks like AL code."

Image from my tweet on Jan 18, 2023 showing ChatGPT attempting write AL code

That it was hallucinating couldn't be argued, but ever the optimist that I am, I saw it as a glass half-full.

Fast-forward to December 2024, many Business Central developers are now using Copilot for GitHub as a pair programmer that can look at patters from their code and code snippets and help write pretty good AL code. There are even examples abound where a book on AL has been used as a knowledge source and the Agent then leverages that knowledge to help write AL code.

Still, I've been curious to see how far the GPT LLM has improved from GPT-3.5 to GPT-4o. I hear over and over again that LLMs improve leaps and bounds from version to version, so much so that if you were to spend a lot of time fine-tuning and adding knowledge to an LLM to serve a certain vertical or industry, the next version of the same LLM is likely to out-do all that effort right out of the box. So of course I wanted to know if that would be the case with Business Central and AL code.

Today was the day. I asked my trusty Agent in Copilot Studio (which is powered by GPT-4o, and isn't grounded in any knowledge source other than its own general knowledge) to write code to create a new table in AL:

=====

I want to create a Business Central Table in AL. The table should be called Consultant, with fields called Code (Code20), Name (Text50), Billing Rate (Integer), E-mail (Text80), Active (Boolean). The primary key is Code. Each field should also have multilanguage captions in French and Spanish. I will need your help translating those field captions.

Sure, I can help you with that. Below is an example of how you can create a table in AL for Business Central with the specified fields and multilanguage captions in French and Spanish.

table 50100 Consultant
{
 DataClassification = ToBeClassified;

 fields
 {
 field(1; Code; Code[20])
 {
 DataClassification = ToBeClassified;
 Caption = 'Code';

 // Multilanguage captions
 CaptionML = ENU='Code', FRA='Code', ESP='Código';
 }
 field(2; Name; Text[50])
 {
 DataClassification = ToBeClassified;
 Caption = 'Name';

 // Multilanguage captions
 CaptionML = ENU='Name', FRA='Nom', ESP='Nombre';
 }
 field(3; BillingRate; Integer)
 {
 DataClassification = ToBeClassified;
 Caption = 'Billing Rate';

 // Multilanguage captions
 CaptionML = ENU='Billing Rate', FRA='Taux de facturation', ESP='Tarifa de facturación';
 }
 field(4; Email; Text[80])
 {
 DataClassification = ToBeClassified;
 Caption = 'E-mail';

 // Multilanguage captions
 CaptionML = ENU='E-mail', FRA='E-mail', ESP='Correo electrónico';
 }
 field(5; Active; Boolean)
 {
 DataClassification = ToBeClassified;
 Caption = 'Active';

 // Multilanguage captions
 CaptionML = ENU='Active', FRA='Actif', ESP='Activo';
 }
 }

 keys
 {
 key(PK; Code)
 {
 Clustered = true;
 }
 }
}

In this example:

  • The table is named Consultant.
  • The fields are Code, Name, BillingRate, Email, and Active.
  • Each field has multilanguage captions in English (ENU), French (FRA), and Spanish (ESP).
  • The primary key is set to Code.

Feel free to adjust the field IDs and other properties as needed for your specific requirements.

AI-generated content may be incorrect

=====

Those of you who are not AL developers are probably wondering: So how did it do?

If you look at the screenshot below with all the red curly underlines, you'd be tempted to conclude at first glance that it didn't do very well. But if you look closely at the Problems at the bottom of the screenshot, you will see that the only error it seems to have made is that used both the Caption and the CaptionML (Multilanguage caption) property, where only one of those should be used for a field. And that same error was repeated over and over again for each field in the table.

You could argue that it made a mistake so it's still not good enough. Or you could be practical and acknowledge that the problems will take less than a minute to clean up. And that it could be avoided with a better-written prompt.

The reality is that if you are a professional software developer looking for a "Copilot" programming buddy, you are likely going to use a purpose-built tool like Copilot for GitHub just like many other Business Central developers are doing today. (Note: by default Copilot for GitHub also uses GPT-4o at the time of this writing, but can easily be switched with models better suited for coding like o1-mini, o1-preview, or Claude 3.5 Sonnet).

But it is a testament to the clip at which LLMs and Generative AI are improving that in less than 2 years, the very generic, out-of-the-box GPT-4o LLM can now write working AL code right out of the box.

Is your mind blown yet? No? Check this out…

Before I ended my experiment, I thought I'd try one more thing.. I cleared out my chat so it didn't remember anything about the code it wrote for me earlier and asked it another question:

=====

Can you tell me what language this code is written in and what it's designed to do?

With that prompt, I also pasted the code. And within seconds came the response:

The code snippet you provided is written in AL (Application Language), which is used for developing extensions for Microsoft Dynamics 365 Business Central.

Here's a breakdown of what the code is designed to do:

  1. Table Definition: The code defines a table named Consultant with the ID 75099.
  2. Data Classification: The DataClassification property is set to ToBeClassified for the table and its fields, indicating that the data needs to be classified according to data privacy and security standards.
  3. Fields: The table contains five fields:
    • Code: A Code[20] field with multilingual captions for English (ENU), French (FRA), and Spanish (ESP).
    • Name: A Text[50] field with multilingual captions.
    • BillingRate: An Integer field with multilingual captions.
    • Email: A Text[80] field with multilingual captions.
    • Active: A Boolean field with multilingual captions.
  4. Keys: The table has a primary key (PK) defined on the Code field, which is clustered.

This table is likely used to store information about consultants, including their code, name, billing rate, email, and active status. The multilingual captions ensure that the field names are displayed correctly in different languages.

If you need further assistance with this code or have any other questions, feel free to ask!

AI-generated content may be incorrect

=====

To my surprise and hopefully yours, it was able to establish that the code was written in AL for Business Central and it did a pretty good job of explaining the fields, data types and even a possible explanation as to what purpose the table and fields may serve.

I also did similar tests for creating a List Page, a Card Page and an API page for this table.

  • For List and Card Pages, the only issue was that it referenced fields from the table without the explicit Rec. prefix.
  • For API Page, it added a DataClassification property for each field; this property is not used for pages of this type.
  • On the API Page, it also mapped the ODataKeyFields to the primary key field of the table instead of using SystemId. While this does not cause an error, using SystemId is a best practice for purposes of stability (should a user change the value of the default primary key inside BC).

Overall, nothing major that could be considered problematic.

That, my friends, is what I call impressive!