DEV Community: Nirmal Jingar

Before You Refactor Legacy Code, Map the Decisions Hidden Inside It

Nirmal Jingar — Tue, 09 Jun 2026 12:10:41 +0000

Before you refactor legacy code, ask one question:

What decision am I about to change?

Not what class am I cleaning up.
Not what service am I extracting.
Not what function am I rewriting.
Not what dependency am I removing.

What decision am I changing?

That question would have saved me from one of the most expensive mistakes I have seen in software modernization.

A change looked safe. It passed code review. It passed tests. It passed the approval gates.

Within 48 hours, it cost millions.

Nothing crashed. No alarms fired. The system kept running.

It just started making worse decisions.

That is the kind of failure that is hard to catch with normal engineering checks. The code works. The deployment succeeds. The metrics may even look normal at first.

But the business outcome changes.

The lesson was simple:

We did not break the system because we changed code. We broke it because we changed a decision we did not fully understand.

Legacy code is not just messy implementation

When engineers inherit legacy code, it is natural to see the mess first.

Long methods.
Nested conditionals.
Duplicated logic.
Old comments.
Strange defaults.
Special cases.
Branches nobody wants to touch.

The instinct is to clean it up.

That instinct is often right. Legacy code can slow teams down. It can make releases risky. It can hide bugs. It can increase operational cost. It can make onboarding painful.

But there is a trap.

Some of that mess is not just bad implementation.

Some of it is hidden business logic.

Some of it is decision debt.

Technical debt is code that is hard to change.

Decision debt is behavior that no one can explain anymore.

That distinction matters.

If you treat decision debt like simple technical debt, you can accidentally delete business knowledge.

What hidden business logic looks like

Hidden business logic rarely announces itself clearly.

It usually looks like ordinary code.

A condition.
A fallback.
A default value.
A mapping.
An exception.
A temporary workaround that became permanent.
A comment that made sense five years ago.

Here are common places where I look for it:

Eligibility rules
Routing logic
Pricing rules
Fallback behavior
Customer exceptions
Operational constraints
Vendor workarounds
Data assumptions
Old compensations for external system bugs
Hardcoded thresholds
Manual overrides
Feature flags with unclear ownership
Special handling for rare states
Logic that protects downstream systems

This is why refactoring legacy code is not only a software architecture problem.

It is also a recovery problem.

You are trying to recover the intent behind behavior before you change the behavior.

Load-bearing decisions

A useful way to think about this is the idea of a load-bearing decision.

In a house, many walls can be moved. You can redesign the layout, open up space, and make the structure feel new.

But some walls are load-bearing.

They hold up parts of the structure you cannot see.

Legacy systems have the same pattern.

Some decisions are safe to change. They are cosmetic, obsolete, duplicated, or purely technical.

Other decisions are load-bearing.

They may protect:

Revenue
Customer experience
Operational workflows
Edge cases
Compliance constraints
Performance under specific conditions
Data quality
Downstream dependencies
Historical failure modes

The dangerous part is that load-bearing decisions often look ugly.

They can look like hacks. They can look outdated. They can look inefficient. They can look like technical debt.

Sometimes they are.

But sometimes they are the reason the system still works.

Why tests and reviews miss this

Code review is good at catching many things.

Readability.
Maintainability.
Obvious bugs.
Security issues.
Consistency with patterns.
Test coverage.

Tests are also useful. They can validate expected outputs. They can prevent regressions. They can document some behavior.

But tests and reviews often miss decision intent.

A test can tell you this input currently produces that output.

It may not tell you why that output matters.

A reviewer can tell you the code is cleaner.

They may not know which business decision changed.

An approval gate can tell you the deployment is safe.

It may not ask what behavior the system is protecting.

That is how a change can pass every technical check and still damage the business.

The missing question is not always, “Does this work?”

Sometimes the missing question is:

What decision changed, and do we understand it?

A migration example

During one migration, we were moving a core service.

At first, it looked like a normal software migration.

Move the logic.
Update the interface.
Validate the output.
Release the new version.

The team knew the code base. We had done migrations before.

This time, we used AI before touching the code.

Not to generate the replacement service.

Not to move faster.

We used it to map the decisions inside the old service.

The service looked like one unit of logic.

It was not.

It contained 31 distinct decisions accumulated over 8 years.

Some were still valid.

Some existed for a client that no longer existed.

Some compensated for a third-party bug that had already been fixed.

Without the map, we probably would have migrated all 31 decisions into the new system.

That would have meant copying old assumptions, obsolete rules, and unnecessary compensations into cleaner architecture.

With the map, we made a different choice.

We migrated 9 decisions.

The other 22 were documented, flagged for review, or scheduled for deliberate cleanup.

That changed the migration.

The value of AI in that moment was not code generation. It was decision discovery.

It helped us see what we were actually changing.

Using AI for decision discovery

Most AI-assisted engineering conversations focus on writing code.

That is useful, but it is not enough for legacy system modernization.

Before asking AI to generate replacement code, ask it to explain the decisions embedded in the current code.

Here are prompts I would use.

Prompt 1: Find business decisions

List every business decision this function appears to make. 
For each decision, explain the input, output, condition, and possible business meaning.
Do not rewrite the code yet.

Prompt 2: Separate implementation from decision

Separate technical implementation details from business decisions in this code.
Group the findings into:
1. Pure implementation
2. Business rules
3. Data assumptions
4. Fallback behavior
5. External system dependencies

Prompt 3: Find load-bearing decisions

Identify decisions in this code that may be load-bearing.
A load-bearing decision is behavior that may protect revenue, customer experience, operational flow, compliance, downstream systems, or rare edge cases.
Explain why each decision may be risky to change.

Prompt 4: Analyze conditionals

Review every conditional branch in this code.
For each branch, explain:
- What decision it represents
- What input triggers it
- What behavior changes
- What might break if the branch is removed

Prompt 5: Find fallback behavior

Find all fallback behavior in this code.
For each fallback, explain what failure, missing data, dependency issue, or historical constraint it may be protecting against.

Prompt 6: Create a decision map

Create a decision map for this service.
For each decision, include:
- Decision name
- Inputs
- Output
- Business purpose
- Known assumptions
- Dependencies
- Risk if changed
- Suggested migration action

Prompt 7: Identify obsolete rules

Identify rules that may depend on historical context.
Flag decisions that may be obsolete, client-specific, vendor-specific, or compensating for old system behavior.
Do not recommend deleting anything unless the reason is clear.

The important part is the last sentence.

Do not let AI confidently delete behavior it does not understand.

Use it to surface questions. Use it to create a map. Use it to accelerate investigation.

The engineer still owns judgment.

A pre-refactor checklist

Before refactoring legacy code, I now want answers to these questions:

What decision does this code make?
What inputs influence the decision?
What output or behavior changes if I remove it?
Who depends on this behavior?
Is the rule still valid?
Is it protecting an edge case?
Is it compensating for another system?
Is it customer-specific, vendor-specific, or market-specific?
Do tests cover the decision or only the implementation?
Is the current behavior intentional or accidental?
What should be migrated, rewritten, deleted, or reviewed?

If you cannot answer these questions, you may still be able to refactor.

But you are refactoring with unknown risk.

That may be fine for low-impact code.

It is not fine for systems that make business-critical decisions.

A simple decision record format

When mapping legacy logic, I like to capture each decision in a lightweight format.

No heavy process. No large document. Just enough context to avoid losing intent again.

Decision:
Apply fallback routing when primary destination is unavailable.

Inputs:
Primary destination status, fallback configuration, request type.

Output:
A fallback destination is selected instead of failing the request.

Known context:
Originally added to prevent failed requests when the primary destination could not be used.

Risk if changed:
Requests may fail instead of being routed through a safe fallback path.

Owner:
Needs confirmation from service owner or business owner.

Migration action:
Migrate for now. Add observability. Review whether the fallback is still needed.

This format forces the right conversation.

Not “Is this code ugly?”

But “What decision does this represent, and what should we do with it?”

What to migrate, rewrite, delete, or review

Once decisions are mapped, the migration becomes more deliberate.

I usually think in four buckets.

Migrate

The decision is still valid and clearly understood.

Keep the behavior. Improve the implementation if needed.

Rewrite

The decision is valid, but the implementation is outdated.

Preserve the intent. Change the code.

Delete

The decision is obsolete and the risk is understood.

Remove it deliberately. Add monitoring if the impact is not fully certain.

Review

The decision may matter, but the context is unclear.

Do not blindly migrate it. Do not blindly delete it. Document it, assign an owner, and review it.

This is where many migrations go wrong.

Teams often treat all old behavior as either something to copy or something to clean up.

Decision mapping gives you more options.

Where this fits in modernization

This applies to many types of work:

Refactoring legacy code
Monolith migration
Service extraction
API rewrites
AI code migration
Replatforming
Replacing vendor integrations
Simplifying business rules
Removing old feature flags
Consolidating duplicated logic
Reducing technical debt

In each case, the technical change is only part of the work.

The safer path is:

Map decisions
Recover intent
Classify risk
Decide migration action
Refactor or rewrite
Validate business behavior
Document what changed

That sequence is slower than blindly rewriting code.

It is faster than breaking something important and spending months rediscovering why the old system worked.

AI is useful when it makes the invisible visible

I do not think AI removes the need for senior engineering judgment.

For legacy systems, I think the opposite is true.

AI makes senior judgment more valuable by surfacing the hidden logic that deserves attention.

It can help scan a large code base.
It can identify patterns.
It can group rules.
It can summarize decision paths.
It can find inconsistencies.
It can generate questions engineers should ask before changing behavior.

But AI should not be treated as the decision maker.

It should be treated as a decision discovery tool.

That shift matters.

The goal is not simply to migrate code faster.

The goal is to understand what the code is deciding before you migrate it.

The takeaway

Before you refactor legacy code, map the decisions hidden inside it.

Some of those decisions are obsolete. Some are accidental. Some are ugly. Some should be deleted.

But some are load-bearing.

They protect behavior that is not obvious from the code alone.

The safest modernization does not start with rewriting code.

It starts with recovering intent.

The unit of transformation is not the system.

It is the decision.

This article is adapted from my Medium essay and TEDx talk on decision recovery in legacy system modernization.

Medium article: https://medium.com/@nirmal.jingar/systems-are-not-made-of-code-they-are-made-of-decisions-4b7fa2ead212
TEDx talk: https://www.youtube.com/watch?v=pxUChqiyp2Y

Building Reliable AI Decision Systems for Enterprise Supply Chains

Nirmal Jingar — Wed, 20 May 2026 21:38:46 +0000

Artificial intelligence is rapidly transforming enterprise operations, but one uncomfortable reality remains:

Most AI systems are still not trustworthy enough to directly control mission-critical infrastructure.

This becomes especially visible in supply chain operations, where small decision failures can create cascading consequences across inventory, transportation, procurement, fulfillment, and customer experience.

Modern supply chains already operate under continuous stress:

demand volatility
transportation disruptions
supplier instability
weather events
labor shortages
geopolitical risk
fluctuating costs

Traditional enterprise systems were built for predictability. Today’s operating environment is anything but predictable.

At the same time, large language models (LLMs) have introduced a new generation of reasoning capabilities that can interpret operational context far beyond what traditional planning systems can handle.

The challenge is figuring out how to safely combine:

AI reasoning
optimization systems
enterprise governance
operational reliability

The answer is not autonomous AI replacing enterprise control systems.

The answer is building reliable AI decision infrastructure.

Why Traditional Supply Chain Systems Struggle

Most enterprise supply chain platforms are built on deterministic models:

forecasting engines
inventory optimization systems
routing solvers
operations research frameworks
replenishment planners

These systems are extremely good at mathematical optimization under known conditions.

But they often fail when the environment changes rapidly because they primarily depend on:

structured datasets
static rules
historical assumptions
predefined constraints

Real-world disruptions rarely arrive in structured formats.

A transportation crisis may first appear as:

carrier emails
port congestion reports
weather alerts
social media signals
supplier communication
unstructured logistics updates

Traditional systems cannot reason about these signals effectively.

Why Pure LLM-Based Systems Are Risky

LLMs solve a different problem.

They excel at:

semantic interpretation
contextual reasoning
summarization
pattern recognition
unstructured data analysis

An LLM can quickly synthesize:

disruption reports
operational anomalies
inventory instability signals
supplier delays
regional risk indicators

But using LLMs directly for operational execution creates major enterprise risks:

hallucinated recommendations
inconsistent reasoning
non-deterministic behavior
weak auditability
governance gaps
unpredictable outcomes

This is the core enterprise AI problem:

Highly intelligent systems are not automatically reliable systems.

And reliability matters more than intelligence when real-world infrastructure is involved.

The Enterprise AI Architecture Gap

Today’s enterprise AI landscape often splits into two extremes.

Deterministic Enterprise Systems

These systems are:

reliable
auditable
governed
mathematically constrained

But they lack contextual awareness.

Generative AI Systems

These systems are:

adaptive
flexible
reasoning-capable
context-aware

But they lack deterministic guarantees.

The future of enterprise AI likely belongs to architectures that combine both.

A Better Architectural Model

A safer enterprise AI model follows a simple principle:

LLMs should contribute reasoning, while deterministic systems retain execution authority.

This distinction is critical.

Instead of allowing an LLM to directly execute operational actions like:

inventory allocation
logistics routing
procurement execution
replenishment decisions

…the LLM contributes structured operational intelligence.

For example, the AI layer may:

identify high-risk transportation regions
detect abnormal supplier instability
estimate disruption severity
recommend inventory protection strategies
prioritize operational objectives
highlight conflicting constraints

The final operational decisions are still made by constrained optimization systems such as:

mixed integer linear programming (MILP)
stochastic optimization
deterministic planning engines
operations research solvers

This creates separation between:

reasoning
optimization
execution
governance

That separation is essential for enterprise trust.

The Importance of Symbolic Grounding

One of the biggest problems in enterprise AI is converting probabilistic reasoning into operationally safe inputs.

This is where symbolic grounding becomes important.

Without grounding, LLM outputs remain:

ambiguous
non-verifiable
difficult to operationalize safely

A symbolic grounding layer translates semantic reasoning into:

measurable variables
bounded constraints
optimization parameters
auditable operational inputs

For example:

Instead of an LLM saying:

“Transportation instability appears elevated in the Southeast region.”

The grounding layer converts that into structured operational constraints such as:

increased route risk penalties
reduced carrier confidence scores
tighter inventory protection thresholds
regional fulfillment balancing adjustments

The optimization engine can then safely incorporate these constraints into deterministic planning models.

This prevents unconstrained language generation from directly controlling enterprise infrastructure.

Safety Must Be Infrastructure, Not an Afterthought

Most AI discussions focus heavily on intelligence.

Far fewer focus on operational safety.

That is a mistake.

Enterprise systems require:

bounded risk
predictable execution
explainability
governance enforcement
compliance validation
measurable guarantees

A reliable AI architecture should include safety-constrained execution layers that evaluate candidate actions before execution.

These layers may validate:

service-level compliance
transportation capacity limits
inventory protection policies
operational risk thresholds
financial exposure constraints
regulatory requirements

Unsafe actions are rejected before they reach production execution systems.

This shifts safety from:

reactive governance

to:

embedded infrastructure governance

That difference matters enormously in enterprise environments.

A Real-World Operational Scenario

Consider a large retail supply chain during peak seasonal demand.

Suddenly:

severe weather disrupts major transportation corridors
ports become congested
carrier reliability drops
inbound inventory delays increase
demand volatility spikes simultaneously

Traditional systems often struggle because disruption signals arrive too quickly and across too many disconnected channels.

An AI-assisted decision architecture could continuously ingest:

weather alerts
carrier updates
supplier lead-time changes
inventory telemetry
regional transportation data
operational incident reports

The reasoning layer may identify:

high-risk transportation zones
unstable routing regions
increasing stockout probability
fulfillment imbalance risks
service-level exposure

These insights are then translated into constrained optimization inputs.

The optimization layer recalculates:

inventory allocation
replenishment quantities
fulfillment balancing
carrier prioritization
routing strategies

Meanwhile, safety systems validate every candidate action against operational policies before execution.

This creates a system where:

AI improves contextual awareness
optimization preserves deterministic control
governance systems enforce reliability
human operators retain accountability

The goal is not autonomous enterprise infrastructure.

The goal is resilient and governable operational intelligence.

The Future of Enterprise AI Is Reliability

Enterprise AI adoption is increasingly becoming less about model capability and more about infrastructure trust.

Organizations are starting to realize that successful production AI requires:

deterministic safeguards
constrained execution
governance-aware orchestration
explainability boundaries
operational validation
reliability guarantees

The most valuable enterprise AI systems will not necessarily be the most autonomous systems.

They will be the systems enterprises can trust.

Final Thoughts

AI reasoning capabilities are advancing rapidly.

But enterprise-scale operational systems require more than intelligence alone.

They require:

reliability
governance
safety
deterministic control
operational accountability
measurable guarantees

The next generation of enterprise AI systems will likely combine:

probabilistic reasoning
deterministic optimization
safety-aware validation
governance-constrained execution

That combination may ultimately define the future of production-grade enterprise AI infrastructure.

Because in critical enterprise environments, reliability is not optional.

It is the product.

Citation

Nirmal K. Jingar (2026)

Reliable LLM-Powered Decision Engines for Large-Scale Supply Chain Operations: Architecture, Safety, and Performance Guarantees

IEEE IC_ASET 2026

https://doi.org/10.1109/IC_ASET69920.2026.11502212