En AI-agent kan skrive AL, kompilere den mod jeres symboler og udgive den til et sandbox-miljø. Koden virker som regel. Det er præcis derfor, gennemgangen betyder noget.
Denne side er den tjekliste, en konsulent bør køre, før AL skrevet af en agent når et produktionsmiljø, sorteret efter hvad der koster mest, når det er forkert.
Hvad kan en agent i AL i dag?
Mere end de fleste teams forventer. Release wave 1 for 2026 nævner seks punkter til dette arbejde:
- AI-agentværktøjer til AL-udvikling
- En AL MCP-server til fejlsøgning
- Tilkobling til og fejlsøgning af agentsessioner i Business Central
- AL-test, der kører fra Visual Studio Code
- Hentning af symboler fra et NuGet-feed
- BC-Bench til vurdering af AL-kodeagenter
En praktisk arbejdsgang ser sådan ud. En person beskriver ændringen. Agenten læser symbolerne, skriver objekterne, kompilerer, udgiver til en sandbox og kører testene. Personen prøver det, retter det, og agenten tager en runde mere.
Det, arbejdsgangen ikke indeholder, er dømmekraft om jeres produktionsmiljø. Det er opgaven for den, der gennemgår koden, og den bliver ikke mindre, fordi koden blev lettere at producere.
Hvorfor er gennemgang ikke valgfri?
Fordi fejltypen har ændret sig.
En juniorudvikler skriver kode, der ikke kan kompileres, og kode, der er tydeligt forkert. Begge dele er billige at fange. En agent skriver kode, der kompilerer, består sine egne test og gør det forkerte på en måde, der læses som bevidst.
Den anden type fejl er dyrere, og den er usynlig for de kontroller, der fanger den første.
Tjeklisten
Arbejd listen igennem. Rækkefølgen følger, hvad det koster at tage fejl, ikke hvor let det er at kontrollere.
1. Alt, der rører bogførte data
Se først på hver skrivning til en bogført tabel, hvert abonnement på en
bogføringscodeunit, og enhver brug af COMMIT inde i et bogføringsforløb. En
agent, der "forbedrer" bogføring, har produceret den dyreste fejltype i Business
Central, for skaden ligger i finansposten, og finansposten er selve bogføringen.
Behandl en ændring i bogføring som en ændring, der kræver en skriftlig begrundelse, en test og en læser mere.
2. Rettigheder
Nye objekter kræver rettighedssæt. En agent skriver ofte objekterne og glemmer rettighederne, eller giver mere end funktionen har brug for.
Kontrollér, at hver ny tabel og side er med i et rettighedssæt, at sættet passer til opgaven, og at intet er lagt i et bredt sæt for nemheds skyld.
3. Opgradering og datamigrering
Det er den del, der oftest mangler. Et nyt felt med en standardværdi, en ændret felttype eller data, der skal flyttes, kræver opgraderingskode. Uden den installeres udvidelsen problemfrit på en sandbox uden data og fejler i et produktionsmiljø med fem års data.
Spørg direkte: hvad sker der med de eksisterende rækker? Står svaret ikke i koden, er arbejdet ikke færdigt.
4. Objektnumre, navngivning og namespaces
Kontrollér, at objektnumrene ligger inden for det interval, I ejer, at navnene følger jeres konvention med det rigtige præfiks, og at namespaces er sat. Det er billigt at rette nu og dyrt at rette, efter udvidelsen er udgivet.
5. Ydelse
Se efter løkken, der burde have været en forespørgsel, manglende
SetLoadFields, et FlowField brugt inde i en løkke, og ethvert filter på et felt
uden en understøttende nøgle.
En agent optimerer efter korrekt resultat på de data, den kan se. Jeres produktionsdata er større end det, og omkostningen viser sig først ved volumen.
6. Fejlhåndtering
Kontrollér, at fejl ikke bliver slugt. En TryFunction, hvis fejl bliver
ignoreret, forvandler en larmende fejl til et stille forkert resultat, og det er
det værste af de to.
Kontrollér, at fejlbeskeder nævner posten og årsagen, for de beskeder dukker op i telemetri som RT0030, og en vag besked koster den næste en time.
7. Oversættelse og etiketter
Bekræft, at hver etiket kan oversættes, og at ingen tekst til brugeren er hårdkodet på ét sprog. For en dansk eller tysk kunde er det ikke en sidste finpudsning. Det er forskellen på en brugbar side og et tosproget rod.
8. Test
Spørg, hvad testene faktisk kontrollerer. Test skrevet af en agent har det med at kontrollere, at koden kørte, i stedet for at resultatet er rigtigt.
Én test, der holder et beregnet tal op mod en kendt værdi, er mere værd end ti, der kontrollerer, at der ikke kom en fejl.
Hvad agenter oftest tager fejl af
Fra vores eget gennemgangsarbejde, groft sorteret efter hyppighed:
- Manglende opgraderingskode til nye eller ændrede felter.
- Rettighedssæt, der aldrig blev oprettet.
- Et abonnement, der kører ved hver bogføring, når det burde køre på én dokumenttype.
- Filtre, der ikke kan søge, på tabeller, hvor det betyder noget.
- Etiketter, der ikke kan oversættes.
- Test, der ikke kontrollerer noget brugbart.
- Selvsikker brug af et mønster fra en ældre version af Business Central.
Punkt 7 er værd at holde øje med. Agenter lærer fra udgivet kode, og en stor del af den udgivne AL er gammel. Et mønster, der var korrekt i en tidligere version, kan være udfaset nu, og det kompilerer stadig.
Hvordan I gør gennemgangen billig
Gennemgangen er flaskehalsen, så byg efter den.
Hold sessionerne små. Én ændring pr. session. En session, der rører seks områder, kan ikke gennemgås ordentligt og bliver godkendt alligevel.
Kræv en sandbox. Intet når produktion direkte. Agenten udgiver til en sandbox, en person prøver ændringen, og først derefter gennemgår en konsulent koden.
Sæt et budget på sessionen. Et loft, der er sat, før sessionen går i gang, forhindrer en agent i at bruge en time på den forkerte tilgang.
Lad ændringen være det, I gennemgår. Gennemgå ændringen, ikke filen. En, der skal læse hele objektet, skimmer det.
Hold reglerne ét sted. Et skrevet sæt kvalitetsregler, som både agenten og den, der gennemgår koden, bruger, gør gennemgangen til kontrol i stedet for holdning. Agenten læser de samme regler, før den skriver.
Pointen med arbejdsgangen
Værdien er ikke, at koden er gratis. Værdien er, at den person, der forstår forretningsprocessen, selv kan formulere ændringen, og at konsulenten bruger sin tid på dømmekraft i stedet for på tastearbejde.
Den handel går kun op, hvis gennemgangen er ægte. En udvidelse skrevet af en agent, som ingen læste, er en ændring i produktion, som ingen læste, og det værktøj, der gjorde den nem, er ikke et forsvar.
Spørgsmål og svar
- Kan en AI-agent skrive en udvidelse til Business Central?
- Ja. En agent kan skrive AL, kompilere den mod jeres symboler og udgive den til et sandbox-miljø. En konsulent skal gennemgå resultatet, før det når produktion.
- Hvad skal den, der gennemgår koden, kontrollere først?
- Kontrollér objektintervallet og navngivningen, rettighedssættene, koden til opgradering og datamigrering, de abonnementer, der kører ved bogføring, og enhver skrivning, der rører en bogført tabel.
- Leverer Microsoft AL-værktøjer til agenter?
- Ja. Release wave 1 for 2026 nævner AI-agentværktøjer til AL-udvikling, en AL MCP-server til fejlsøgning og BC-Bench til vurdering af AL-kodeagenter.
Kilder
Vi tjekker enhver ekstern påstand på den viste dato. Microsoft flytter funktioner mellem release waves, så tjek siden igen, før du læner dig op ad den.
- 01New and planned features for Dynamics 365 Business Central, 2026 release wave 1Microsoft Learn · Kilder tjekket 2026-09-17
- 02Business Central MCP Server Overview and SetupMicrosoft Learn · Kilder tjekket 2026-09-17