AL Object ID Ninja is now available as a GitHub Action and an Azure DevOps Pipeline Task. It scans your AL repository during CI/CD and fails the build if it finds any object IDs, field IDs, or enum value IDs that aren’t tracked by the Ninja backend. No more spreadsheets, no more “we’ll coordinate manually”, no more conflicts surfacing during deployment.
Multi-app repos and app pools are supported automatically.
Today I want to talk about something that barely anyone is talking about. Context engineering.
We hear about prompts constantly. We hear about the latest model releases, the agentic frameworks, the AI-powered IDEs, the MCP servers (luckily we don’t hear about vibe coding all that much anymore). We hear about a lot of things. You name it – we hear about it.
But context engineering? Not so much.
And I find that strange, because if there is one lesson I have taken away from spending the past nine months writing code almost exclusively with AI agents (last six of which you can drop the “almost” word), it is this: context matters more than your prompt. Significantly more. Whenever my agents produced results that I could never match – faster, more consistent, undeniably better – every single time I could trace that back to one thing. Precise context.
That word, precise, is doing a lot of work in that sentence. Remember it.
I’ve been busy over weekend with completing a few work items that were in the cooking for a while. Some have been on my wish-list since day one, some have been brewing since a few years ago. It’s unbelievable how far certain architectural decisions can go, and I am genuinely excited to bring this new version to the daylight: 3.2.1.
So, 3-2-1 go!
I owe you an explanation.
Not a corporate statement. Not a carefully worded legal notice. An actual explanation, from me to you, because you’ve trusted this tool – and by extension, me – for years. You deserve more than a changelog entry.
So here it is.
So you’ve jumped on the agentic coding train. You’re using Cursor, or Claude Code, or Windsurf, or whatever the cool kids are using this week. Your AI assistant writes AL code for you, and life is good.
Except… who’s making sure your object IDs don’t collide?
Nobody, that’s who. Until now.
You know what’s supposed to be unique? Snowflakes. Fingerprints. And GUIDs.
A GUID (Globally Unique Identifier) is mathematically designed to be so astronomically unique that if you generated one hundred billion GUIDs per second, you’d still have a better chances of being struck by lightning twice and then winning the lottery, all on the same day, than generating a duplicate.
And yet, here we are. Talking about duplicate App IDs in Business Central.
I’ve just released Ninja 3.1.0, and it adds something I’ve wanted for a while: language-model tool-based object ID assignment.
In practice, this means that when an agent is writing AL code inside VS Code, it can now use Ninja directly as a tool to allocate and commit object IDs. No typing. No IntelliSense. No human in the loop. The agent writes the code, asks Ninja for an ID, and moves on, safely, and conflict-free.
The response was immediate. Within the first hour, agents assigned 64 object IDs across 12 different apps. So, this was an obvious signal that this wasn’t just a “nice to have”, but was a really much needed feature.
This was a very obvious gap once agent-driven coding became real. For previous versions of Ninja there has been an MCP server (written by Torben Leth). I am not sure if that MCP still works (probably not, because the old endpoints are gone, and new ones are not compatible anymore). I am now working on the MCP server of my own: the official AL Object ID Ninja MCP server that will work inside or outside VS Code, in any agentic workflow.
So, if you’re using agents to generate AL code (which you should!), you no longer have to worry about object IDs. They’re assigned correctly, globally, and in real time, exactly the same way Ninja already does it for human developers. It’s amazing to see agent just picking the next number from the tool, instead of trying to figure it out by grepping through the project and trying to do it by hand (which would be inaccurate and would require human intervention anyway).
More new cool features are coming, so stay tuned! Now that Ninja is a commercial product, I can finally put the hours in to make it an even better tool for everyone.
This past weekend marked an important milestone for AL Object ID Ninja.
Backend version 3 is now live, running in production on:
So far, it’s been running smoothly and reliably, exactly as intended.
At the same time, version 3 of the VS Code extension was published to the Visual Studio Code Marketplace earlier today and has already started being used in real production environments.
This post is a short status update: what’s live, what changed, what to expect next, and how billing and pricing work going forward.
This post is for teams running AL Object ID Ninja on their own backend.
If you are using the hosted Ninja backend, you don’t need to do anything — the transition will be handled for you invisibly.
When I opened the early-bird sign-up page for AL Object ID Ninja, my goal was simple:
to understand whether there was enough real interest in a fully supported, commercial-grade Ninja platform for me to commit myself to building it the way it deserves to be built.
That question didn’t stay unanswered for long.
The response was overwhelming — a clear, resounding “Yes, please!” from the market.
To everyone who signed up: thank you. Truly. Your trust is the single biggest motivator behind the speed and intensity of development happening right now.
I even extended the early-bird window by two extra days to accommodate the late rush, but now the big lifetime discounts are officially closed and I’m no longer collecting “count-on-me” registrations.
That said, if you feel you should still receive a discount, reach out to me directly before December 22, and I’ll gladly provide a 15% voucher. No justification needed — just ask.