AI vs. Rules Is the Wrong Argument

I keep watching capable people argue the wrong question. One camp says: stop trusting brittle rules; put a model on it. The other says: stop gambling on probabilistic systems; encode the policy and ship the rule.

I am not picking either camp. I am not anti-AI.

I am not anti-rules. Both camps are responding to real pain. Neither camp is describing how trustworthy work actually gets done. The useful question is not whether an organization should choose AI or rules.

It is which parts of a workflow still require reasoning under uncertainty—and which parts the organization already understands well enough to execute deterministically. Those are different decisions inside the same unit of work. Treating them as a single ideology is how programs oscillate between “AI everywhere” and “rules everywhere,” and end up with neither.

The camps are both half-right

Ambiguous intake, conflicting evidence, novel exceptions, and contested judgment are exactly where generative systems can help—if they sit inside boundaries that make outcomes recoverable. Schema checks, arithmetic, permission gates, known mappings, mandatory scans, and stable postconditions should not be reinvented by a model every time. Known constraints should become software. The failure mode is not choosing the wrong side.

It is forcing an entire workflow onto one side. A denial appeal is not “all AI” or “all rules.” Some fields must validate deterministically. Some payer-policy interpretation still requires investigation.

Some actions need human accountability. Some yesterday’s hard-won pattern should become today’s governed check—until the payer changes the world underneath it. A production change is the same shape.

Lint and tests should be unavoidable. Root-cause diagnosis may still need reasoning.

Rollback criteria should be explicit. A recurring incident class should eventually stop being rediscovered from a blank chat. If your architecture can only express “ask the model” or “fire the rule,” you will keep arguing about tools while the work stays mis-typed.

How the false binary shows up in real programs

I see the argument surface in three familiar places.

First, procurement. A team is asked to pick an “AI platform” or a “rules/BPM modernization” as if those are mutually exclusive strategies for the same workflow portfolio. The purchase then becomes a loyalty test. Everything that does not fit the chosen camp is treated as a temporary exception instead of a first-class path.

Second, architecture reviews. Someone proposes wrapping a known validation in an agent “for flexibility.” Someone else proposes freezing an ambiguous exception class into a decision table “for control.” Both proposals can be locally rational. Together, without a way to type steps by uncertainty, they produce systems that are either over-probabilistic or over-rigid—and expensive either way.

Third, operating metrics. Programs celebrate model calls, seat adoption, or rules coverage as if any of those alone proved trustworthy completion. Throughput without correct placement is how organizations amplify the wrong mechanism efficiently. None of this means AI tools or rules engines are the enemy.

It means the unit of design has to be the decision—or the step—inside the workflow, not the brand of the tool attached to the whole process.

Uncertainty is not uniform across a workflow

Earlier I argued for the Principle of Least AI: use probabilistic intelligence where uncertainty requires reasoning, and deterministic mechanisms where the answer is already sufficiently known. I also argued that the useful unit of AI transformation is the workflow—intake, judgment, action, validation, and learning—not the chatbot task. Those two points meet here.

Inside one workflow, uncertainty is uneven. Intake may be messy: free text, incomplete packets, conflicting identifiers.

Reasoning helps. Validation may already be sharp: totals must reconcile; required artifacts must exist; a deployment must pass a scan. Rules help.

Judgment may be genuinely contested. Human accountability stays. Learning may show that a once-novel family of cases has become boring under stable conditions.

The organization should be allowed to graduate that boredom into capability—without pretending boredom is permanent.

This is not rediscovering classic BPM case management, rules-lifecycle governance, or MLOps promote-to-prod under a new label. Those practices already manage known paths and model promotion. The distinctive claim is narrower: type uncertainty inside the same workflow unit, and keep movement between reasoning and deterministic execution reversible when evidence, assumptions, or conditions change—including when a “known” rule stops being true.

This is observational, not a universal measured survey. A falsifiable mismatch shows up when programs treat “AI vs. automation” as a single procurement decision: the model is asked to do arithmetic; the rules engine is asked to interpret novelty; humans become the glue for both failures. The architectural need is narrower and sharper:

Represent different uncertainty profiles inside the same unit of work—and move work between them as evidence changes.

In a design review, the minimum worth typing for each consequential step is blunt: what the step decides, how uncertain it still is, who or what has authority to act, and what signal would invalidate that authority. That typing can sit above or beside the CI gates, runbooks, CAB/RFC paths, rules engines, BPM paths, and reasoning tools you already run. It does not require a greenfield hybrid platform.

Promotion is how learning becomes leverage

A hybrid partition that never changes its boundary is only a static split. Useful systems need a path from repeated successful reasoning to deterministic capability. That path is promotion. Promotion is not “the model got lucky three times.”

It is an organizational decision with evidence:

• What outcomes, reviews, or checks validated the pattern?
• Under what input conditions does it apply?
• Which adjacent cases must stay on a reasoning path?
• What signals should invalidate it?
• Who can approve promotion—and who can force reconsideration?

Without those questions, “we automated it” is just a confident rename of tribal habit. With them, the organization stops paying for rediscovery of what it already earned. That is the maturity loop Least AI points at: early exploration, then governed certainty where certainty is real, with scarce reasoning reserved for what remains uncertain.

I am not claiming a formula for when promotion is ready. Volume alone is not enough. Quiet quarters hide fragile assumptions. The claim is that promotion must be possible, explicit, and owned—or the hybrid boundary freezes into another form of process debt.

Demotion is how trust stays honest

There is a matching danger on the other side. Today’s correct rule can become tomorrow’s legacy defect. A payer changes documentation requirements.

A jurisdiction adopts a new code. A vendor changes an API.

A workload changes shape. A business objective shifts. If deterministic automation has no path back to investigation, the organization has not gained maturity.

It has gained confident wrongness. Demotion is the reverse motion: suspend or narrow a governed path when invalidation signals appear, return affected cases to reasoning or human judgment, and rebuild only after new evidence earns trust again.

I have seen the premature version.

A team promotes a “stable” routing rule after a quiet quarter. Then an upstream policy or dependency changes. The rule still fires confidently. Exceptions pile up in a queue nobody designed for reconsideration. Recovery means treating the rule as suspect again—not arguing that rules were a mistake forever.

Without demotion, rules camps win the argument by accident—until reality changes and the system cannot admit it. Without promotion, AI camps win by keeping every familiar problem expensive forever. Trustworthy systems need both directions.

Stop scoring the debate. Score the placement.

A practical way out of the camps is to stop asking which tool is fashionable and start asking, for a consequential workflow:

1. Which steps are already known well enough to execute deterministically? 2. Which steps still contain uncertainty that requires reasoning? 3. Which decisions must remain human-owned regardless of model quality? 4. What evidence would justify promoting a repeated reasoning pattern into a governed path? 5. What signals would force demotion of a path that used to be safe? 6. If the chat history disappeared tomorrow, would those answers still be recoverable?

Those questions do not require a product category name. They do require a design discipline: type steps by uncertainty, place mechanisms accordingly, and keep movement between probabilistic and deterministic paths owned—not frozen—as experience accumulates. For transformation offices, the Monday implication is also non-product. Change vendor scorecards and stage-gates so they ask known / uncertain / human-owned placement questions—not AI-versus-rules loyalty.

I am not claiming any particular platform already fulfills that responsibility. I am saying the responsibility is organizational, not optional, if “AI transformation” is meant to produce trustworthy operating leverage rather than another round of ideological tooling.

The wrong argument wastes the right tools

AI is valuable because some work does not fit neatly into rigid software. Rules are valuable because some work does. The organization that keeps arguing AI versus rules will keep buying whichever side is currently loudest. The organization that places both by uncertainty—and can promote and demote between them—will spend less energy on camps and more on finishing work well.

That is not a call to eliminate intelligence. It is not a call to freeze the enterprise into permanent procedures. It is a call to stop pretending those are alternatives. Different portions of work have different uncertainty profiles.

Architecture should respect that—and remain reversible when the profiles move. The next question is operational, not tribal: once you reject the false binary, how do you separate discretionary judgment from known execution so both stay explicit, owned, and able to move?