For more than two decades, Business Central development has been about understanding the business, understanding the platform, and turning those two worlds into reliable software. AI is now changing how that software is created, and the biggest change may not be that AI can write AL code, but that AI can increasingly participate in the entire development lifecycle. I have spent more than 20 years working with Dynamics NAV and Microsoft Dynamics 365 Business Central, and during that time I have seen the development profession change many times. We moved from C/AL to AL, from C/SIDE to Visual Studio Code, from direct database customizations to extensions, from on-premise development to cloud-based applications, and from traditional release cycles to continuous development and deployment.
Every transition changed the tools developers used, but the fundamental responsibility of the developer remained the same. We were responsible for understanding the requirement, designing the solution, writing the code, testing it, fixing problems, and making sure the final result behaved correctly inside Business Central.
AI is beginning to change that model.
Microsoft is now providing AI agent tooling specifically for AL development, allowing AI agents to perform activities such as building projects, publishing extensions, searching symbols, retrieving diagnostics, and debugging AL solutions.
This is no longer simply AI helping developers write code. AI is beginning to participate in the development process itself.
The AL Developer’s Role Is Not Disappearing
I don’t believe AI coding agents will make AL developers less important. In many ways, they will make Business Central expertise even more valuable because as AI becomes better at producing code, the ability to understand why that code should exist, where it belongs, and what consequences it may create becomes increasingly important.
An AI agent can create a table extension, but should that field actually exist? It can create an event subscriber, but is that the right architectural approach? It can modify posting logic, but does the change respect Business Central’s existing framework and business rules? It can generate a query, but will it perform efficiently when the database contains millions of records? It can make the code compile, but compilation is only proof that the code is syntactically valid, not that the solution is correct.
AI can increasingly generate the code. The developer still needs to decide whether the code deserves to exist.
That distinction becomes particularly important in Business Central because AL is not simply another programming language. AL operates within a deeply interconnected ERP platform involving tables, pages, reports, codeunits, events, permissions, posting routines, dimensions, number series, FlowFields, keys, APIs, extensions, dependencies, and established application patterns.
A technically correct piece of AL can still be the wrong solution for a customer’s Business Central environment.
A developer who understands only AL syntax may be able to ask AI to generate code. A developer who understands Business Central architecture, business processes, performance, data behaviour, extensibility and implementation experience can determine whether that code should actually be used.
Business Central knowledge becomes the context that transforms AI-generated code into production-quality software.
This is why I believe the future AL developer will not compete with AI coding agents. The developer will direct them, challenge them, review them, and provide the Business Central context they cannot discover from syntax alone.
The future belongs not to developers who write every line themselves, but to developers who know which lines should be written, why they should exist, and how they should work within the Business Central ecosystem.
The Development Environment Is Becoming an Agent Environment
The Business Central development environment is evolving from a place where developers write code into a workspace where developers and AI agents work together across the entire codebase. Visual Studio Code remains central, but AI agents can increasingly understand projects, discover symbols, inspect dependencies, identify compilation issues, trace relationships, and work across multiple objects rather than simply suggesting the next line of AL and this is where I see one of the biggest productivity opportunities.
The real bottleneck in many Business Central projects is not writing new code; it is understanding existing code. Developers spend hours finding the right codeunit, tracing event subscribers, understanding dependencies, following posting logic, locating where a table is used, and trying to understand why a customization was originally created.
AI can turn code discovery from a manual search exercise into an intelligent conversation with the existing solution.
Instead of navigating through hundreds of objects to understand how a process works, a developer could ask an AI agent to trace the process, identify the relevant objects, explain the dependencies, and highlight where a change could have an impact.
The biggest productivity gain may not be writing AL faster. It may be understanding Business Central faster. But there is another side to this acceleration. If AI can create and modify code faster, it can also create technical debt faster.
An agent may generate unnecessary abstractions, inefficient data access, excessive database calls, inappropriate event subscribers, poor use of SetLoadFields, unnecessary JIT loads, or incorrect assumptions around TransferFields. The code may compile and even appear to work, while still creating performance, maintainability, or architectural problems.
Speed without engineering discipline simply produces bad code faster.
This is why AI coding agents need to be surrounded by strong development standards, automated testing, code review, performance analysis, security controls, and Business Central-specific governance. The development environment is becoming an agent environment, but the developer remains responsible for the quality of what that environment produces.
AI can accelerate the development cycle; only engineering discipline can ensure that acceleration moves the solution in the right direction.
Code Review, Testing and Human Oversight Will Become More Important
As AI agents increasingly generate AL code, code review will become more important—not less. AI-generated code must be evaluated beyond compilation: architecture, performance, security, maintainability, Business Central conventions, extension compatibility, data access, events, permissions, and runtime behaviour all matter.
Microsoft’s BC-Bench is an important step in this direction, introducing measurable benchmarks for evaluating AI coding agents on realistic Business Central development tasks. AI coding cannot be judged by impressive demos alone—it needs repeatable evaluation and measurable quality. Testing will also become part of the agent’s responsibility:
Requirement → Implementation → Build → Test → Diagnose → Correct → Rebuild → Retest.
The developer may no longer perform every step manually. Instead, the developer increasingly becomes the orchestrator of this development loop—providing context, reviewing architecture, validating results, and deciding when the solution is ready.
This does not make technical expertise less important. It makes it broader. AL, Business Central architecture, databases, performance, APIs, security, events, extensions, testing and deployment will still matter—alongside AI workflows, context engineering, agent instructions, MCP, evaluation and governance but some decisions should remain firmly under human control. An AI agent should not independently change posting architecture, bypass security boundaries, redefine business requirements, or deploy critical changes to production simply because the code compiles.
The future developer may write less code, but will be responsible for more decisions.
The strongest AL developer may not be the one who writes the most code, but the one who can combine Business Central expertise, AI capabilities, rigorous evaluation and human judgment to deliver the right solution.
As AI becomes more capable, human oversight becomes more—not less—important.
The AL Developer of 2030
When I think about the AL developer of 2030, I don’t imagine someone manually writing every object in Visual Studio Code. I imagine a developer leading a team of AI agents—one understanding the architecture, another exploring the codebase, another generating AL, others testing, diagnosing, reviewing performance, and validating security. The developer becomes the orchestrator and architect: defining the business outcome, challenging AI recommendations, making critical architectural decisions, and taking responsibility for what ultimately reaches the customer.
After more than two decades in Business Central development, I believe the hardest part was never simply writing code. It was understanding the business, the existing system, the consequences of a decision, and how to build something that remains reliable over time. AI can increasingly handle the mechanics.
Human expertise remains responsible for the engineering. That is why I don’t see AI coding agents as the end of the AL developer.
I see them as the beginning of a new definition of the AL developer. The strongest developers of 2030 may write less code—but solve bigger problems, make better architectural decisions, and deliver solutions with AI agents working alongside them.
The future is not humans versus AI. It is AL developers + AI agents building better Business Central solutions, faster, smarter, and with stronger validation.
The tools are already arriving. The development model is already changing and the AL developer is entering the age of AI coding agents.