Contents:
Three months into an AI-assisted rewrite of a 30-year-old retail ERP, the CTO made the decision nobody had budgeted for: re-architect the new system and move it to a different stack.
The rewrite needed a rewrite.
I know the product owner. Let’s call him John. He is a successful serial entrepreneur with 35 years in technology. In a few weeks, his team generated more than 100,000 lines of code for a new ERP covering POS, warehouse management, and other core functionality. Product managers were adding features at a pace the old development model could not match.
For a while, the new product even seemed to be overtaking the system it was supposed to replace, a system that had accumulated three decades of business logic.
Then the progress stopped being progress. Nobody could give a credible release date. Engineers were spending their time stabilizing what had already been generated.
This is the part of AI-assisted modernization that gets misunderstood most often. The lesson is not that AI is bad at software rewriting. It is that generating a replacement is not the same thing as modernizing a business-critical product.
For a live, revenue-generating system, modernization has a different objective: increase the company’s ability to change the product without increasing the chance of losing what already works.
AI changes the economics of execution. It does not change the laws of software reliability.
AI can generate change. But someone still has to own the consequence.
Why budget can make the mistake worse
The teams most able to afford AI speed are often the ones with the most to lose.
A prototype team can generate the wrong thing for a weekend and throw it away. A funded company with a live product can run more AI agents, parallelize more migrations, generate more code, and move farther in the wrong direction before architecture, data, or operations reveal the mistake.
Having a budget does not reduce modernization risk by itself. Without strong feedback loops and guardrails, it can accelerate ungoverned change inside a fragile system.
DORA’s 2025 State of AI-assisted Software Development research, based on survey responses from nearly 5,000 technology professionals, reached a related conclusion: AI acts primarily as an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.
That is a useful way to think about software modernization. AI does not remove the need for a sound delivery system, but it increases the value of having one and the cost of not having one.
A safer operating model for AI-assisted software modernization
If I had to compress the approach into one sequence, it would be this:
- Understand what must remain true.
Map the architecture, dependencies, critical workflows, data, business rules, and constraints before changing the system.
- Stabilize what can hurt you.
Build a safety envelope around the product: tests, observability, environment isolation, scoped permissions, backups, rollback, and clear accountability.
- Modernize in bounded stages.
Choose valuable changes with a clear boundary between legacy and new components, prove behavior at that boundary, release gradually, and keep the old path reversible until the new one earns trust.
- Scale AI-assisted delivery.
Once the system can absorb change safely, let AI agents earn more capability inside explicit technical boundaries, independent verification gates, and risk-based human oversight.
All four steps happen while the product keeps running the business.
A rewrite asks the business to wait for a replacement. Modernization keeps converting risk into capability while customers continue using the product.
1. Understand what must remain true
Modernization discussions often jump straight to the future stack: cloud, microservices, a new frontend, new data infrastructure, maybe a full rewrite. That is backwards.
The first software modernization question should be: what does this product do today that the business cannot afford to lose?
A mature system contains far more than code. It contains undocumented business decisions: customer-specific rules, exception paths, data transformations, forgotten integrations, permissions, and operational workarounds that quietly became part of the product.
A rewrite starts from what the team can describe. A modernization program has to start from what the system actually does. Before AI changes the product, make the product legible. At minimum, establish a working map of:
- business-critical user journeys, hidden business rules, and known exceptions;
- system boundaries, dependencies, integrations, data flows, and areas with the highest change frequency or incident rate;
- security-sensitive paths, privileged actions, and regulated data;
- deployment, rollback, backup, incident-response capabilities, performance constraints, and service levels.
AI can help analyze repositories, trace dependencies, draft documentation, and compare old and new behavior. But its output is evidence to review, not the source of truth. The source of truth is the running product, its data, tests, logs, and the people who understand why the strange parts exist.
Modernization starts with truth, not code generation.
2. Stabilize what can hurt you
Once the system is understood, the next temptation is to start generating changes immediately. I would still wait. Speed is only an advantage when the system can absorb it.
Before accelerating delivery, create what I call a modernization safety envelope: the technical and organizational controls that limit the blast radius of a bad change.
For a business-critical product, that usually means:
- tests that capture critical existing behavior and detect regressions;
- observability that exposes regressions quickly;
- tested backups and rollback, not just a recovery document;
- separation between development, staging, and production;
- least-privilege access for people, tools, service accounts, and AI agents;
- feature flags, limited rollouts, or another mechanism for gradual exposure;
- explicit ownership for architecture, security, release approval, and incidents.
With agentic AI, add another layer. A coding agent can read repositories, run commands, install dependencies, call tools, change files, and invoke migrations. That changes the threat model.
Agent inputs need explicit trust boundaries. Repository content, third-party documentation, generated artifacts, tool output, and external context should not be trusted equally. OWASP’s Top 10 for Agentic Applications for 2026 highlights risks such as goal hijacking, tool misuse, and privilege abuse.
Don’t rely on the agent to behave. Limit what it can physically reach. Human approval is useful, but it is not a substitute for architecture.
A stronger control model separates four concerns:
- Capability: what tools and resources can the agent technically access?
- Containment: where can its code and commands execute, and what network or data can they reach?
- Verification: which independent gates must pass — automated checks where possible, plus review or evaluation where judgment is still required?
- Accountability: which decisions still require an engineer with authority over architecture or production consequences?
That means scoped credentials, allowlisted tools, sandboxed execution, restricted production access, clear context boundaries, and an auditable record of consequential actions.
The 2025 Replit database incident shows why. Replit acknowledged that its Agent deleted data from Jason Lemkin’s app database; the data was later restored through Rollback. The incident predated default separation of development and production databases. Replit later separated them and restricted the Agent from changing the production database during development.
The lesson is bigger than one tool. If an AI agent can act faster than a human can inspect every intermediate step, safety cannot depend on attention alone.
The faster the tool, the smaller its uncontrolled blast radius should be.
3. Modernize in bounded stages
Once the safety envelope exists, AI can become genuinely useful in software modernization. But the unit of work matters. Do not ask, “Can AI rewrite our product?” Ask, “What is the smallest valuable capability we can isolate, modernize, and put into operation reversibly?“
That is more demanding than simply choosing the smallest feature. The boundary should be evaluated across three dimensions: business value, coupling, and reversibility.
A high-value module can still be a poor first target if it shares data with half the product, has undocumented consumers, or cannot be rolled back independently. A less visible capability with a clean interface may be safer because the team can isolate it, compare behavior, and learn without putting the whole business at risk.
In practice, the goal is to create a reversible boundary around the capability. That may mean routing traffic gradually to a new component, abstracting a legacy dependency, or isolating incompatible domain models behind a translation layer. The pattern matters less than reversibility: old and new paths should coexist long enough to compare behavior and shift users safely.
Old and new code can coexist. Two uncontrolled sources of truth cannot. Define data ownership, avoid uncontrolled dual writes, synchronize and reconcile state where needed, and set cutover and retirement criteria before migration begins.
For each modernization increment:
- Define the behavior that must be preserved.
- Define or create the boundary between legacy and new components.
- Build tests and measurable acceptance criteria against that boundary.
- Let AI accelerate analysis, tests, refactoring, documentation, and repetitive migration work.
- Validate against production-like conditions, release gradually with observability and rollback, and retire the legacy path only after predefined criteria are met in real use.
This is slower than generating an entire replacement in a few weeks. It is much faster than discovering in month three that the replacement cannot ship.
Use the right software modernization technique for each part of the product. Some components need refactoring, some replatforming, some replacement. And some ugly legacy code should be left alone if it is stable, understood, not creating unacceptable risk, and not constraining the business.
A mature product does not need ideological purity. It needs a better rate of safe change.
4. Scale AI-assisted delivery without scaling the blast radius
The question “Can AI write production code?” is too broad to be useful. The answer depends on what the agent can do, what controls surround it, and what happens when it is wrong.
In my GITEX talk, I used an intentionally exaggerated Rust example: a hard-coded API key, a query built from untrusted input, and a hallucinated or outdated dependency. The example was deliberately obvious. Real failures are often less convenient.
That is why I prefer to define agent authority before debating model capability.
A simple four-mode model works well:
- Read
The agent can inspect approved code, documentation, test results, and logs within scoped data and environment boundaries. It cannot change the system.
- Propose
The agent can generate patches, plans, or pull requests, but cannot execute consequential changes.
- Execute in a sandbox
The agent can modify a branch, run commands, generate migrations, and execute tests in an isolated environment with scoped access.
- Execute consequential actions
Anything that can alter production data, deploy software, change privileged access, modify critical infrastructure, move money, or create an irreversible side effect belongs here. These actions need stronger controls and accountable ownership. Some should be impossible for the agent by design.
These are execution modes, not risk levels. Read-only access to sensitive data or secrets in production can be more sensitive than code execution inside a disposable sandbox. Risk depends on authority, data sensitivity, environment, and business consequence.
Agent autonomy should be earned through evidence. Start with narrow authority, measure how reliably a class of tasks clears verification gates, then expand permissions gradually. Treat agent autonomy like production traffic: increase it as confidence accumulates.
The goal is not to make senior engineers read every generated line.
Their role shifts upward: define architecture and invariants, design verification gates, constrain agent capabilities, review exceptions, and own consequential decisions.
That is expert-in-the-loop in an agentic environment: not a human approving everything, but an expert designing and owning the control system around the agent.
Two ideas matter here.
- The Slop Multiplier starts when unverified AI output becomes the new baseline and weak assumptions compound from one task to the next.
- The Filter Model breaks that loop: constrained execution, independent verification, expert review where judgment is needed, and staged release. The same agent should not define the requirement, implement it, and provide the only proof that it works.
AI agent → constrained execution → independent verification → risk-based human decision → staged production
Same tool, very different outcome.
Keep authority aligned with consequence.
Price modernization at system level, not code-generation level
AI has made implementation dramatically cheaper. But implementation is only one part of the lifecycle. Requirements, architecture, UX, security, testing, integration, deployment, operations, and long-term maintainability still exist when code appears faster.
If the board asks whether AI will make modernization cheaper, do not answer with the cost per generated feature. Answer with the economics of the whole change system.
Track metrics such as:
- lead time from an approved change to production;
- change failure and rollback rate;
- escaped defects and production incidents;
- review and rework effort per change;
- mean time to recovery;
- infrastructure and AI-tooling cost per delivered capability;
- maintenance burden after the modernized component is live.
Those numbers show whether AI lowers the cost of reliable change or simply shifts cost from implementation into verification, rework, and incidents.
The cost of failure is not theoretical. IBM’s 2025 Cost of a Data Breach Report put the global average cost of a data breach at $4.44 million. IBM also reported that 13% of organizations in its 2025 study had experienced breaches of AI models or applications, and 97% of that group lacked proper AI access controls.
That does not mean AI caused the average $4.44 million breach. It means the governance gap around AI is measurable and expensive enough to belong in the modernization business case.
Cheap generation is not cheap modernization if the saved implementation time reappears as review, rework, or recovery.
Turn modernization into a portfolio decision
For a company with several products, acquired systems, or internal platforms, modernization becomes a capital-allocation problem. Do not rank the portfolio by codebase age alone. Prioritize by business criticality, change pressure, technical condition, safety readiness, and where AI can reduce effort without uncontrolled authority.
Some products should be stabilized before they are modernized. Some can support an AI-assisted refactoring immediately. Some are better candidates for replacement. And some should remain largely untouched while investment goes to systems that are actually constraining the business.
The modernization roadmap should follow business risk and change economics, not the age of the codebase.
Six questions to ask before you approve an AI-assisted modernization program
If you are a CTO, CEO, product leader, or board member, you do not need to review pull requests to know whether the program is being run responsibly. Ask these six questions:
- What business capability are we modernizing first, and why is it the right boundary?
A good answer explains business value, coupling, and how the change can be reversed. “The whole platform” is rarely a safe first boundary.
- What behavior must remain unchanged, and how will we prove it?
Look for tests, contracts, production baselines, reconciliation, and measurable acceptance criteria, not confidence.
- What is the blast radius of a bad AI-generated change?
You should hear about environment isolation, scoped credentials, tool permissions, backups, rollback, feature flags, and staged releases.
- What can the agent technically do?
Which actions can it read, propose, or execute in a sandbox? What data and environments can it reach? Which actions require explicit approval? Which are impossible by design? If this has not been defined, the team does not have AI governance. It has tool access.
- Who is accountable for architecture, security, and production incidents?
The agent can assist with all three. It cannot be the accountable owner of any of them.
- What metrics will prove that modernization is improving the economics of change?
Velocity alone is not enough. You want faster delivery together with lower failure, lower rework, and a product that becomes easier to evolve over time.
If the team can answer all six clearly, AI can become a serious modernization advantage. If it cannot, more generation speed will usually magnify the uncertainty already inside the product.
How MobiDev approaches AI-assisted software product modernization
At MobiDev, we have been building and modernizing software products since 2009. More recently, we have invested more than 2,000 expert hours in shaping our approach to AI-driven software development.
That work has focused not simply on generating code faster, but on designing the controls around AI: context, execution boundaries, independent verification, and accountable engineering decisions.
We usually start with the same four questions this article does: what must remain true, what needs stabilization, where the first safe seam is, and how much authority AI should have. Our expert-in-the-loop approach separates context, execution, verification, and accountability so AI can accelerate work without owning the consequence.
For established products, that usually means combining application modernization with AI-assisted development instead of choosing between “keep the legacy system” and “rewrite everything with AI.”
The goal is not to preserve old software forever. The goal is to evolve it at the pace the business needs without turning modernization into one irreversible bet.
If your product is revenue-generating, difficult to change, and under pressure to adopt AI or accelerate delivery, start with the condition of the system, not the promise of the tool. MobiDev can help assess the architecture, define the safest modernization sequence, and identify where AI can add speed without creating uncontrolled risk.
For broader AI initiatives, our AI Implementation Diagnostics evaluates readiness across strategy, data, technology, and team.
