The quality of AI-generated code depends heavily on how you communicate your needs. This guide teaches you how to write effective prompts that lead to better results.
Vague prompts lead to generic results. Provide clear, specific instructions.
❌ Vague: “Create a page”
Create a page
✅ Specific: “Create a card page for Customer with fields No, Name, Address, and Phone Number”
Create a card page for the Customer table that displays these fields:
- No.
- Name
- Address
- Phone No.
Include FactBoxes for Sales Statistics and Contact Information.
Help the AI understand what you’re working on.
❌ No Context: “Add a field”
Add a field to store email
✅ With Context: “Add an email field to the Customer table extension for newsletter subscriptions”
I'm extending the Customer table. Add a new field called "Newsletter Email" to store
the email address customers want to use for newsletters. This is separate from their
primary email. Make it a Text field with length 80.
Show the AI what you want by providing examples.
✅ With Example:
Create an event subscriber for OnAfterValidate on Sales Header's "Sell-to Customer No."
field, similar to this pattern:
[EventSubscriber(ObjectType::Table, Database::"Sales Header", 'OnAfterValidateEvent', 'Sell-to Customer No.', false, false)]
local procedure OnAfterValidateSellToCustomerNo(var Rec: Record "Sales Header")
begin
// Your implementation here
end;
The subscriber should copy the Newsletter Email from the Customer to the Sales Header.
Pattern: Create a [object type] that [does what] with [specific requirements]
Example:
Create a codeunit named "Sales Order Validator" that validates sales orders before posting.
It should:
- Check that all lines have quantities > 0
- Verify customer credit limit is not exceeded
- Ensure all required fields are filled
- Return a list of validation errors
Use AL coding best practices.
Pattern: Explain [what] in [level of detail]
Examples:
// Simple explanation
Explain what this function does
// Detailed explanation
Explain this procedure in detail, including the purpose of each parameter
and the business logic flow
// For learning
Explain this code as if I'm new to AL development
Pattern: Improve this code by [what to improve]
Examples:
Improve this code to follow AL best practices
Refactor this procedure to be more performant
Add error handling to this code
Make this code more testable by reducing dependencies
Pattern: Review this code for [specific concerns]
Examples:
Review this code for potential bugs and performance issues
Check this code against AL coding guidelines
Identify security concerns in this procedure
Find opportunities to reduce database calls in this code
Pattern: Generate [documentation type] for [what]
Examples:
Generate XML documentation comments for all procedures in this file
Create a README explaining what this extension does and how to install it
Write user documentation for this new feature
Pattern: Create tests for [what] that [test scenarios]
Example:
Create test codeunit for the Sales Order Validator that tests:
- Valid orders pass validation
- Orders with zero quantities fail
- Orders exceeding credit limit fail
- All validation error messages are correct
Use the AL Test framework with Given-When-Then pattern.
Break complex requests into steps:
I need to create a new feature for automatic discount calculation. Let's approach this step by step:
1. First, create a table extension for Sales Line to store discount category
2. Then, create a discount setup table with categories and percentages
3. Next, create a codeunit to calculate discounts based on category
4. Finally, add an event subscriber to apply discounts automatically
Let's start with step 1...
Be explicit about what you do and don’t want:
Create a procedure to import customer data from CSV.
Requirements:
- Use streams for large file handling
- Validate email format before importing
- Skip duplicate records (based on external ID)
- Log errors but continue processing
- Return summary of imported, skipped, and failed records
Do NOT:
- Use temporary files
- Import if any record fails validation
- Modify existing customer records
Point to specific coding standards or patterns:
Create a page extension following the AL coding standards in this repository.
Use the same XML documentation pattern as in CustomerProcessor.codeunit.al.
Follow the naming conventions in our README.md.
Start broad, then refine:
// First prompt
Create a codeunit to process sales orders
// After seeing initial result, refine
Add error handling using try-catch pattern
// Further refinement
Add logging using AL telemetry
// Final touch
Add XML documentation comments
Create an AL procedure compatible with Business Central version 21
Create a page that uses the "Temp Blob" codeunit from the System Application
Create table 50100 "Custom Discount Setup" with fields...
Create a page with ApplicationArea set to #Basic,#Suite
Create a table extension for table 18 "Customer" that adds...
Make it better
Fix this
Create something for customers
Create a customer page, fix the sales order bug, and document the project
Better: Break into separate prompts
Add the field we discussed
Better: Restate what you need
Create a validation function
Better: Specify what to validate and how
Create a table extension for Table 36 "Sales Header" that adds these fields:
- "Requested Delivery Date" (Date)
- "Special Instructions" (Text[250])
- "Requires Approval" (Boolean)
Add triggers:
- Set "Requires Approval" to true when amount exceeds $10,000
- Validate "Requested Delivery Date" is not in the past
Include XML documentation for all fields.
Create an API page for the Item table that exposes:
- No.
- Description
- Unit Price
- Inventory
Follow AL API best practices:
- Use API versioning (v1.0)
- Include OData annotations
- Handle GET, POST, PATCH methods
- Validate required fields on POST
Create a test codeunit for the "Sales Order Validator" codeunit.
Tests needed:
1. TestValidOrderPassesValidation - Create valid order, verify no errors
2. TestZeroQuantityFails - Create order with 0 quantity, verify error
3. TestCreditLimitExceeded - Create order exceeding limit, verify error
4. TestMissingRequiredField - Skip required field, verify error
Use:
- [Test] attribute
- Given-When-Then pattern
- LibrarySales for test data
- Assert for verification
Try improving this vague prompt:
❌ Vague:
Create code for discounts
✅ Improved Version (your attempt):
[Think about: What type of code? What discounts? What should it do?
What are the requirements? What standards should it follow?]
Create a codeunit "Customer Discount Manager" that calculates volume-based discounts.
Requirements:
- Accept parameters: Customer No., Item No., Quantity
- Return: Discount percentage (Decimal)
- Business logic:
* 0-10 units: No discount
* 11-50 units: 5% discount
* 51-100 units: 10% discount
* 100+ units: 15% discount
- Read discount tiers from a setup table
- Log calculation to telemetry
- Include error handling for invalid inputs
- Add XML documentation
- Follow AL best practices for procedure naming and structure
Now that you know how to write effective prompts:
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.