“The hard part was never writing the rule. It was making sure someone could still explain it eighteen months later.”
John Grace – North52 CEO
The Vibe Coding Illusion
A team lead I spoke with earlier this year had a story that stuck with me. His organization had just wrapped a sprint where a business analyst, with no formal development background, used Cursor to generate four Dataverse plugins in a single afternoon. The PM was thrilled. Leadership called it a proof point for their AI-first strategy. The team lead was less enthused. He’d glanced at the generated code and noticed two of the plugins contained nearly identical logic with slightly different trigger conditions, and a third was referencing a field that had been deprecated in a schema update six months prior. Nobody else had flagged any of this. The analyst had already moved on to another project.
That anecdote captures the tension perfectly. Vibe coding, the idea that anyone can now prompt their way to a working solution using AI copilots, ChatGPT, Cursor, and the rest, has taken hold as the dominant narrative in the Dynamics 365 and Dataverse ecosystem. If anyone can generate code now, why would you pay for a purpose-built business rules engine like North52?
Because generating code was never the hard part. Maintaining it, understanding it, governing it over time: that’s where organizations actually struggle. And vibe coding, for all its promise, is making that struggle worse.
Business Rules in Dynamics 365: A Pattern That Keeps Repeating
In the early days of Dynamics CRM, business logic lived in custom plugins, JavaScript web resources, and classic workflows. Developers wrote it, understood it, and carried the reasoning in their heads. When Power Automate and the broader low-code movement arrived, the promise was democratization. And it delivered on the simple stuff. But complex conditional logic, multi-entity rules, calculations that had to be right every time: those still ended up in code.
Now vibe coding enters the picture. Anyone can generate a plugin or script in seconds using AI. The barrier to creating code has never been lower.
Here is the historical pattern that keeps getting ignored: every wave of “anyone can code” tooling has eventually produced a maintenance crisis. VBA macros embedded in critical finance spreadsheets. Access databases running entire departments. SharePoint Designer workflows that nobody dared touch after the original creator left. Each of these technologies made it easy to build something. None of them made it easy to understand what had been built, two years and three staff turnovers later. Vibe coding is heading down the same road. It’s just moving faster.
The Technical Talent Exodus
This would all be manageable if organizations were holding steady on technical headcount. They’re not. Companies are actively reducing developer capacity through layoffs, hiring freezes, offshore consolidation, and the seductive narrative that AI will replace the need for developers entirely.
Compounding this is what some have called the “Great Retirement.” Experienced developers who built the existing systems, the ones who remember why a particular plugin checks for a null value on a field that shouldn’t logically be null, are aging out of the workforce. Their institutional knowledge leaves with them, and it doesn’t get captured in a handover document because that kind of knowledge resists documentation. It lives in context, in memory, in the accumulated understanding of hundreds of small decisions made over years.
The critical distinction that gets lost in boardroom conversations about headcount optimization: companies aren’t just losing people who can write code. They’re losing people who can read code. And reading code, understanding what it does and why, is the skill that actually keeps production systems running.
Leadership teams celebrating reduced developer headcount are often the same ones who will be caught off guard when a critical business rule breaks during quarter-end processing and nobody remaining can explain how it worked.
Vibe Coding Makes the Problem Worse, Not Better
Here’s the counterintuitive reality. The easier it is to generate code, the more code gets generated. Volume goes up. Coherence does not. Your codebase sprawls faster than anyone can map it.
Vibe-coded solutions are write-once artifacts. The person who prompted the code into existence frequently doesn’t understand the internals of what was generated. They tested it, it worked, they shipped it. When that person leaves the team, or simply forgets the context six months later, the code becomes a black box with no key.
AI-generated plugins and scripts solve the immediate problem but don’t carry the business intent in a readable, governable way. There’s no embedded explanation of why a discount threshold is set at 15% rather than 10%, or why a particular approval routing skips the regional manager for deals under a certain size. The logic is there. The reasoning is not.
“We’ll document it.” No, you won’t. Documentation decays the moment it’s written, assuming it gets written at all. The nuance of complex business rules lives in people’s heads until those people are gone.
There’s a growing divide in the community between those who believe AI-generated code eliminates the need for specialized tools and those who see it creating technical debt at unprecedented scale. Both camps are vocal. The debt camp is going to be proven right, and the proof will arrive in the form of broken processes that nobody can fix quickly.
The Black Box Multiplier Effect
When developers leave, code-based business rules become opaque. Logic that nobody remaining can understand, modify, or troubleshoot. This has always been true. What vibe coding changes is the rate at which black boxes accumulate.
Instead of one carefully architected plugin built by a senior developer who thought about extensibility, you now have a dozen AI-generated scripts, each solving a narrow problem, with no coherent architecture connecting them. Some overlap. Some conflict. Some reference entities or fields in ways that will break silently when the schema evolves.
The operational fragility this creates is real. A single departure can render a critical business process unmaintainable. And the cost spiral that follows is predictable: organizations end up re-hiring expensive contractors or consultants, often at a premium, just to reverse-engineer logic that should have been transparent from the start. Rule changes that should take hours take weeks. Business agility collapses precisely when leadership believed they were becoming more agile.
The Strategic Pivot: Decouple Business Logic from Code Dependency
The answer isn’t “hire more developers.” That’s expensive, competitive, and unsustainable given market dynamics. And the answer certainly isn’t “vibe code everything,” which creates new debt faster than the old kind. The answer is to externalize business rules from code entirely, placing them in a layer that is visible, manageable, and modifiable by the people who understand the business, without requiring them to read or write code.
This is what a business rules engine like North52 is designed to do. And the difference between that approach and the vibe-coding-plus-hope strategy is worth examining concretely.
Vibe Coding Approach
North52 Business Rules Engine
Transparency
Generated code is opaque to non-developers; understanding requires reading C# or JavaScript
Rules are expressed in a visual formula language that business analysts and admins can read directly
Knowledge retention
Governance
Modification speed
Architectural coherence
None of this means code has no place. Complex integrations, performance-critical operations, highly custom UI behaviors: these still benefit from skilled development. The argument is about where business rules should live, specifically the conditional logic, calculations, validations, and automations that define how your organization operates day to day. That logic should not be locked inside code that only a developer can interpret.
Where This Is Heading
The organizations that will navigate the next few years well are the ones making a deliberate architectural choice now: separate the business logic layer from the code layer. Not because code is bad, but because the supply of people who can maintain code-based business rules is shrinking while the volume of code being generated is exploding. That math doesn’t work.
North52 exists precisely at this intersection. It’s not a replacement for development. It’s a replacement for the specific category of development work that shouldn’t have been code in the first place, the business rules that need to be owned by the business, not held hostage by whoever last edited a plugin.
The vibe coding wave will keep accelerating. The question isn’t whether your team will use AI to generate code. They already are. The question is whether you’re building a system where the logic that runs your business can survive the people who created it.