Why You Still Need a Business Rules Engine – The hidden cost of AI-generated business logic

“Every D365 JavaScript web resource & C# Plugin generated from a chat prompt is a future archaeology project for someone who wasn’t in the room.”

John Grace – North52 CEO

Just describe what you want in plain English. The AI spits out a working plugin. Deploy it, move on. It feels like the future because, in a narrow sense, it is. A Dynamics 365 consultant who once spent half a day hand-coding a validation rule can now have something functional in ten minutes. That’s a genuine, measurable shift.

So here’s the question that keeps surfacing in conversations with CRM teams and IT leaders: if anyone with a Copilot subscription can generate C# plugins, JavaScript web resources, and Power Automate flows from a chat prompt, why would you still invest in a dedicated business rules engine like North52?

The answer is uncomfortable for the vibe coding enthusiasts. AI makes it dramatically easier to create code. It does nothing to solve the much harder problem of maintaining, understanding, and governing business logic over time. There’s a credible argument that it makes that problem worse.

The Vibe Coding Revolution Is Real

It’s worth being clear about what’s actually happening before picking it apart.

• “Vibe coding” is shorthand for AI-assisted or AI-generated code produced from natural language prompts, whether through GitHub Copilot, ChatGPT, or Microsoft’s own Copilot tooling embedded across the Power Platform and Visual Studio ecosystem.
• The productivity gains are not imagined. Consultants and developers are shipping solutions faster, prototyping in hours what used to take days, and tackling small automations they previously would have skipped entirely because the cost-benefit didn’t justify manual coding.
• The Dynamics 365 and Dataverse ecosystem is shifting visibly. More solutions are being delivered by people who prompt AI rather than write code from scratch. Implementation partners are advertising it as a selling point.
• None of this is going away. The tooling will get better, the adoption curve will steepen.

The Morning After

The excitement peaks at deployment. What follows is less photogenic.

Vibe coding generates code. That code still needs to be read, maintained, debugged, versioned, and governed. The AI that produced it has moved on to someone else’s prompt. The code remains, living inside your environment, executing against your production data, interacting with dozens of other customizations it knows nothing about.

• There’s a compounding paradox here. Vibe coding lowers the barrier to creating technical debt at exactly the moment when the workforce capable of managing that debt is contracting. Companies are cutting technical headcount through layoffs, hiring freezes, and what some are calling the Great Retirement of senior developers who built the systems everyone still depends on.
• The institutional knowledge problem is stark. The person who prompted the AI to generate that plugin leaves in eighteen months. Their replacement opens the solution, sees 400 lines of C# with generic variable names and sparse comments, and has to reverse-engineer the business intent from the implementation. This is not a hypothetical scenario; it’s already the reality in organizations that went heavy on custom development five years ago, and vibe coding is accelerating the cycle.
• AI-generated code is often harder to parse than hand-written code because it lacks the original developer’s mental model. It’s syntactically correct, sometimes even elegant, but it doesn’t carry the reasoning. The “why” is gone.
• More code in your environment doesn’t mean better outcomes. It means more surface area for things to break, more dependencies to track, more regression risk every time someone touches something adjacent.

The Skills Gap Keeps Widening

The people best equipped to deal with the fallout are the ones disappearing fastest.

Mid-level developers and technical consultants who can read code, reason about execution pipelines, and trace a bug through a chain of plugins and workflows are the hardest roles to fill right now. They’re being replaced, in theory, by citizen developers and business analysts armed with AI tools. But a business analyst cannot debug a plugin execution pipeline when it throws an unhandled exception at 2 AM on a Saturday. That’s not a criticism of business analysts; it’s a statement about what different roles are designed to do.

• When something breaks in production, organizations increasingly turn to external consultants. Those consultants charge premium rates, and their first billable task is almost always the same: figure out what the previous person built. Hours of budget evaporate before any actual fix begins.
• Every vibe-coded solution that isn’t properly documented and governed becomes another artifact nobody dares to modify. Teams route around it. They build new automations on top of old ones. The environment grows more fragile with each layer.

“Can’t AI Just Fix What AI Built?”

This is the counterargument that comes up in almost every conversation, and it deserves a direct response.

AI can explain code line by line. It can sometimes suggest fixes for isolated bugs. What it cannot do is tell you why a business rule exists, what edge cases it was designed to handle, how it interacts with the 47 other customizations in your environment, or whether changing it will violate a compliance requirement that was negotiated three years ago in a meeting room that no one documented.

• AI doesn’t understand your business context. It doesn’t know that the discount calculation on that entity was structured a specific way because of a contractual obligation with a single client, or that the approval workflow skips a step for a particular division because of a regulatory carve-out that expires next quarter.
• The governance gap is real and largely unaddressed. Who approves changes to AI-generated code? Who tests them against the full range of production scenarios? Who owns the logic? Vibe coding offers no framework for any of this.
• The deeper controversy: by making it trivially easy to generate bespoke code, AI is encouraging organizations to build more one-off, unmaintainable solutions instead of consolidating logic into manageable, visible patterns.

The Business Rules Engine: A Different Category Entirely

A business rules engine is not just “another way to build the same thing.” It’s a fundamentally different approach to where business logic lives, how it’s expressed, and who can work with it.

• Business logic is expressed declaratively through structured formulas, decision tables, and visual matrices rather than compiled DLLs or sprawling script files. The logic is the documentation.
• The key distinction is not about making it easy to build. Every tool claims that. It’s about making it possible to maintain, understand, and hand off business logic to someone who wasn’t involved in the original implementation.
• Rules live inside Dataverse, visible to the team, not buried in external repositories, DevOps pipelines, or a developer’s local machine. When someone needs to understand what a rule does, they open it and read it. That sounds simple because it is.

	Vibe-Coded Plugins / Scripts	North52 Business Rules Engine
Readability	Requires a developer to interpret AI-generated C# or JavaScript; comments are sparse or generic	Declarative formulas readable by functional consultants and business analysts without needing to parse compiled code
Maintenance handoff	New team members must reverse-engineer intent from implementation, often burning hours before any productive work starts	Logic is self-describing within Dataverse; a new team member can open a rule and understand the business intent directly
Governance & change control	No built-in framework for approvals, versioning, or impact analysis; relies entirely on external tooling and discipline	Rule history, structured change management, and visibility built into the platform natively
Debugging in production	Requires someone who can attach to plugin traces, read stack traces, and reason about execution pipelines	Errors traceable through the rules engine interface; no need to decompile or step through external code
Long-term cost profile	Cheap to create, expensive to maintain; consultant costs compound as institutional knowledge erodes over time	Higher initial structure, but dramatically lower cost of ownership across a multi-year horizon because the logic stays accessible

Where This Leaves You

The temptation to vibe code everything is understandable. The speed is intoxicating, and the short-term economics look favorable. But the organizations that will be in the strongest position two or three years from now are the ones drawing a clear line between logic that should be coded and logic that should be governed.

Complex, mission-critical business rules — the kind that touch pricing, compliance, approvals, routing, SLA calculations — belong in a system designed to make them visible, maintainable, and transferable. Not in a plugin that was generated from a prompt nobody saved.

The workforce trends aren’t reversing. The people who can rescue you from bad technical decisions are going to be harder to find and more expensive to hire with every passing quarter. Building your business logic in a way that doesn’t depend on their availability isn’t a conservative choice. It’s the only realistic one.