Your LinkedIn feed has changed. Where it used to be full of people debating low-code vs. pro-code, now it’s full of people building entire applications in an afternoon with Claude Code or Cursor, narrating the process in real time, often with a tone of mild disbelief. And fair enough. The barrier to writing code has genuinely collapsed. A product manager with a well-crafted prompt can get a working prototype faster than most dev teams can finish sprint planning.
This is a real shift. It’s not hype. But in the Dynamics 365 and Dataverse world, it raises a pointed question that doesn’t get asked enough in the breathless demo threads: if you can vibe-code a C# plugin or spin up a Power Automate flow from a prompt, do you still need a dedicated business rules engine like North52?
The answer is yes, and it’s more emphatic than it was two years ago. The reasons cut to the heart of what the broader software industry is about to rediscover about the difference between generating code and running systems.
How We Got Here (And How North52 Got Here First)
Business logic in Dynamics 365 has gone through distinct eras, each with its own flavour of pain. The early days meant hand-coded C# plugins, the plugin registration tool, custom workflow activities. The skill floor was high. The maintenance burden was higher. If the developer who wrote the plugin left, you inherited a black box that happened to run on every invoice update.
Then the low-code wave arrived. Power Automate flows and business rules in model-driven apps made automation accessible to a much wider group, which was genuinely valuable. But scale introduced its own problems: dozens of flows with overlapping triggers, no centralized view of what logic lived where, and debugging that sometimes felt like archaeology.
North52 has been operating in this space for over a decade, long before anyone was talking about AI-generated code. Its philosophy was to let people express business intent directly in readable, declarative formulas rather than writing procedural code. That approach was ahead of its time. It anticipated the very debate the industry is now having about what happens after the code gets generated.
“Code Is Cheap. Software Is Still Expensive.”
This line, which has been circulating in various forms across the AI development discourse, captures something important. LLMs have dramatically reduced the cost of producing code. They have not meaningfully reduced the cost of understanding a business problem, maintaining a solution over time, handling the edge cases that only surface in production, or preserving data integrity when multiple processes interact in ways nobody fully mapped out.
Translate this to Dataverse and it gets concrete fast. You can ask an LLM to generate a C# plugin that calculates tax on an invoice line. It will probably compile. It might work on first test. But six months later, when the tax rules change and the person who wrote the prompt has moved to another project, you’re left with generated code that nobody fully understands, sitting in a DLL that requires a developer environment to even open. Or the plugin doesn’t fire correctly because of execution pipeline nuances (pre-operation vs. post-operation, synchronous vs. asynchronous, depth checks) that the LLM glossed over because the prompt didn’t mention them. Or you end up with 47 AI-generated plugins and no way to audit which one is causing a cascade failure on account updates every Thursday afternoon.
Here’s where the comparison gets interesting:
| AI-generated C# plugin | Hand-coded C# plugin | Power Automate flow | North52 | |
|---|---|---|---|---|
| Initial cost | Very low
Prompt and compile
|
High
Skilled developer + deployment pipeline
|
Low–moderate | Low
Formula authored directly in Dataverse
|
| Maintenance | Unpredictable
Generated code often lacks structure or comments
|
Variable
Depends on the original developer’s discipline
|
Grows fast
Hard to get a holistic view at scale
|
Stays low
Self-documenting, editable in place
|
| Fragility | High
LLMs miss pipeline nuances, concurrency, edge cases
|
Moderate
Better if well-architected
|
Moderate
Connector changes and throttling cause silent failures
|
Low
Declarative execution within the platform’s pipeline
|
| Readability | Varies widely | Can be excellent or poor | Mixed
Visual designer helps initially; complex flows get messy
|
High
Formula language is Excel-like by design
|
| Auditability | Poor
No built-in trace without custom logging
|
Requires setup
Needs instrumented logging
|
Partial
Run history expires; no centralized logic view
|
Strong
All rules visible, searchable, and traceable in one place
|
North52 sidesteps the “code is cheap but software is expensive” problem in a fundamental way: there is no code to maintain. There are formulas, conditions, and declarative logic that express what the business needs directly. The maintenance cost stays low because the logic remains readable regardless of who originally wrote it and regardless of how many years have passed.
Scratchpads vs. Systems
One of the more useful distinctions to emerge from the vibe coding conversation is between disposable personal software and production-grade systems. A quick script to reshape data during a migration, a temporary validation rule you need for two weeks during a rollout, a one-off bulk update: these are scratchpads. They’re meant to be used and thrown away.
North52 handles scratchpad needs well. Zero deployment friction, no CI/CD pipeline, no plugin registration tool. You author a formula and it’s live. But enterprise business logic is not a scratchpad. Tax calculations, regulatory compliance rules, multi-step approval orchestrations, SLA enforcement: these need to be durable, traceable, and maintainable for years. They need to survive staff turnover, platform upgrades, and the inevitable moment when someone asks “why does this work this way?” and needs an actual answer.
Vibe-coded solutions optimise for immediacy. They’re brilliant at getting something working right now. North52 optimises for both immediacy and longevity, which is a combination that matters enormously in enterprise environments. The same formula engine, the same environment, whether you need a quick fix today or a business rule that will still be running and comprehensible in 2029.
The spreadsheet analogy is worth dwelling on. North52’s formula language deliberately echoes Excel formulas. That’s a design choice, not a limitation. It means the business analyst who defined the requirement can often read the implementation. It means the consultant who arrives three years later to modify the logic doesn’t need to set up Visual Studio. It means the audit trail between “what the business asked for” and “what the system does” is short and legible.
Where This Leaves Us
The vibe coding revolution is real and it will change how a lot of software gets built. But in environments like Dynamics 365, where business logic needs to be governed, audited, maintained across years, and understood by people who didn’t write it, the value proposition of a declarative rules engine actually strengthens as code generation gets easier. More people generating more code means more ungoverned logic, more hidden dependencies, more plugins that nobody owns. North52 moves in the opposite direction: toward consolidation, readability, and business-level expression of intent.
The organizations that will handle this transition well are the ones that recognize a counterintuitive truth: the easier it becomes to generate code, the more disciplined you need to be about when and where you actually use it.