By Rajib Lochan Huzuri
I started programming in Microsoft Dynamics NAV when development meant getting your hands dirty, understanding the business requirement, tracing the existing objects, and writing every single line of code by hand.
There was no AI assistant hovering over your shoulder to suggest the next function. If a posting routine failed, you stepped through the code until you understood why, often spending hours inside the debugger. You’d discover the issue wasn’t a bug in the code at all, but a flaw in the underlying business process or system configuration.
Over twenty years later, I’m still building ERP solutions, but the ground beneath us is shifting again.
First, NAV evolved into Dynamics 365 Business Central. C/AL was retired for AL. The classic Windows Client gave way to web browsers. Direct database tweaks and object modifications were replaced by extensions, events, APIs, Visual Studio Code, Git, and CI/CD pipelines.
Now, we’re stepping into the next shift, “vibe coding” with generative AI models.
For those of us who grew up in legacy NAV, picking up AL syntax wasn’t the hard part. The real shock was surrendering ownership of the core application. Back in the NAV days, we modified standard objects directly. We knew exactly where our changes lived and could trace execution end-to-end. It gave us absolute control, though costly, painful upgrades eventually reminded us of the downside. Developing extensions in Business Central demands a completely different discipline. You subscribe to events, isolate customizations, respect application boundaries, and build with long-term maintainability in mind. The underlying business domain hasn’t simplified. Posting logic, dimension sets, reservation engines, inventory costing, tax regimes, and granular security permissions are just as complex as they ever were. AL modernizes the environment, but an ERP system still carries decades of institutional business logic inside it. That domain experience turns out to be vital when you bring AI into the loop.
The phrase “vibe coding” implies that you can loosely describe an idea, accept whatever the model spits out, and hope for the best. My first real experience with ‘vibe coding’ showed me that while it might work for a throwaway side project, it is dangerous ground for core enterprise infrastructure. A hallucinated layout on a landing page is an annoyance; a hallucinated Business Central extension can corrupt ledger entries, miscalculate tax, leak customer data, or blow up quiet month-end closings. When I started experimenting with AI models in my workflow, I wanted to see where they genuinely added value rather than just writing code fast. The immediate productivity boost is real. An AI model can draft table extensions, pages, enums, interfaces, API endpoints, test skeletons, and XML documentation in seconds. It’s brilliant for prototyping and digging up obscure standard objects. But the moment you look away, it will confidently hallucinate a non-existent event subscriber or recommend a deprecated function without batting an eye. That is the precise moment when senior expertise has to step in.
The Senior Developer’s Role Has Shifted.
I used to spend the majority of my working day writing code. Today, I spend most of my time scoping problems, feeding the model proper context, reviewing generated architecture, and validating edge cases. This isn’t “less technical” work, if anything, it requires sharper, broader technical judgment. AI output is only as good as the context you feed it. Ask an AI to “build a credit limit approval feature” and it will blow up in your face. Why? Because it knows nothing about your approval thresholds, currency rules, or dimension inheritance unless you force-feed it that context upfront—including delegation rules, reopened document states, audit trails, and touchpoints with organizational workflows. The model makes assumptions. A veteran developer catches those hidden assumptions immediately, a junior developer might take them at face value and push them to production. Vibe coding only delivers enterprise-grade results when the “vibe” is anchored by rigid specifications, clean architecture rules, existing solution patterns, and clear acceptance criteria. I let the AI speed up the execution, but I never let it dictate the design.
You don’t need a flagship, high-reasoning model for every simple task. Burning expensive tokens to rename fields, generate repetitive mock data, or format code comments is like assigning your principal architect to handle basic data entry. Smaller, lower-cost models are more than capable of handling predictable boilerplate, inline comments, basic unit tests, and routine refactoring. Reserve heavy-reasoning models for complex posting routines, concurrency analysis, and security reviews. Managing models and token costs intelligently is something most teams only learn the hard way: if you aren’t routing simple tasks to cheaper models, your productivity gains get eaten alive by your API bill. In my current setup, I use a fast model to help refine the prompt and requirements, a mid-tier model to generate the initial code, and a high-tier model to audit high-risk logic. Automated builds, static code analysis, and test suites then serve as the ground truth for verification. This matters to the business. If AI shortens dev cycles but bloats operating costs through inefficient prompting and constant regeneration loops, your actual net productivity gains vanish. Smart AI adoption isn’t about picking the cheapest tool; it’s about matching the tool to the task.
What Business Leaders Need to Understand
For executive leadership, AI-assisted development will undoubtedly mean faster proofs-of-concept, better documented codebases, and faster delivery schedules. What it shouldn’t mean is cutting corners on business analysis, system architecture, or thorough testing. ERP systems touch every corner of an enterprise, finance, supply chain, inventory valuation, compliance, and executive reporting. The team overseeing AI-assisted dev work must understand these domain dynamics well enough to challenge what the model generates. An AI can generate an event subscriber in two seconds, but it doesn’t intuitively grasp why bonded warehouse inventory movements carry different legal implications than standard transfers, how custom tax adjustments hit the general ledger, or what happens to performance when thousands of orders hit the system simultaneously. The real competitive advantage lies in pairing experienced domain professionals with high-capability AI models.
New Tools, Same Core Responsibility.
I don’t view vibe coding as the death of programming, it’s simply the next evolution in how we translate domain knowledge into software solutions. NAV taught me how business systems operate at their core. The shift to AL taught me how to architect clean, non-intrusive customizations. Working with AI is teaching me to articulate business intent with precision, delegate tasks efficiently, and audit generated outputs with constructive skepticism. The tools have completely transformed, but the ultimate responsibility hasn’t changed. Solid ERP development still starts with a deep understanding of business operations and ends with rigorous proof that the code works under real-world conditions. AI gets us down the road much faster, but an experienced driver still needs to hold the wheel.
I’d love to hear from fellow NAV and Business Central veterans, How are you incorporating AI tools into your daily implementation and dev workflows, and where are you still drawing the line on automation?