PRODUCT IN THE AI AGE · PART 3

When Cheaper Implementation Changes the Modernization Decision

By Lindsay Bell · Product & Engineering Leader

Product teams accumulate reasons to preserve what they already have.

Existing behavior is familiar. Integrations depend on it. Customers have adapted their workflows around it. Engineers understand at least some of its limitations, and rebuilding it can appear more expensive than continuing to patch it.

AI may change part of that calculation. If implementation and test-authoring effort fall, approaches that previously seemed impractical can become worth considering.

The question is how much of the total cost has actually changed.

The cost of an experiment and the cost of a production decision

Discarding a prototype is usually different from reversing a production change.

A prototype may have no external dependencies, no customer data to migrate, and no established behavior that anyone relies on. Its purpose may be to answer a question and then be thrown away.

Production software participates in a larger system. It has users, permissions, integrations, operational expectations, and sometimes contractual obligations.

AI can help rewrite code in either setting. That does not make the surrounding consequences equivalent.

When we say that building the wrong thing has become cheaper, we should specify which situation we mean. The statement is easier to defend for an experiment that has not yet acquired dependencies.

Why 0–1 and 1–10 feel different

In early product work, the team may still be discovering the customer, the workflow, and the shape of the solution. Changing direction is part of the work.

An established product has more accumulated commitments. A technically improved workflow can still be disruptive to customers who depend on the previous one. A simpler data model can still require a difficult migration.

These are tendencies rather than fixed categories. A new product in a regulated or tightly integrated environment can carry substantial change costs. An established product can also contain an isolated feature that is relatively easy to replace.

The useful question is: who and what depends on the behavior we are changing?

Reassess the options before preserving the compromise

Lower implementation costs can expand the set of reasonable options.

The options are not interchangeable. Refactoring changes internal structure while preserving observable behavior. A rewrite replaces an implementation; a broader redesign may deliberately change behavior and customer workflows. I use modernization here to encompass these different choices, each with its own risks.

A team may be able to compare several approaches through working prototypes. It may be able to explore a replacement while preserving the existing experience. It may discover that a longstanding workaround is no longer the least expensive path.

That deserves consideration. Fear of a major change should prompt examination of the risks and alternatives, rather than automatically settle the decision.

But a rebuild needs a purpose beyond the availability of faster tools. It should address a customer problem, a meaningful constraint, or a cost the organization understands.

Otherwise, inexpensive implementation can simply make unnecessary change easier to produce.

Plan the transition as part of the product

For an established product, the transition is part of what must be designed.

How will existing data behave? Which integrations need to remain compatible? Can customers adopt the change gradually? What evidence would cause the team to pause? What would recovery involve?

Those questions belong in discovery and planning, alongside the proposed functionality.

Quality work needs to cover the transition as well as the destination. A new workflow can pass its own tests while the route from the old workflow remains incomplete.

AI can assist with implementation, test generation, and documentation. People still need to determine which obligations matter and whether the resulting evidence is sufficient.

Preserve short learning cycles

A large modernization effort does not require one large release.

Incremental replacement is an established approach; Martin Fowler’s description of the Strangler Fig pattern provides one example. The question here is how AI changes the economics of pursuing it. Strangler Fig

Where the architecture permits, teams can test assumptions, introduce changes selectively, and compare behavior before expanding adoption. The intent is to limit the consequences of being wrong while building evidence for the next decision.

That is consistent with Agile’s emphasis on frequent delivery, technical excellence, and adaptation. Faster implementation gives teams more options for applying those principles; it does not make feedback less important. Agile principles

Make the decision with current economics

The estimate that justified preserving a system several years ago may no longer describe the available options. Neither does a fast prototype establish that replacement is straightforward.

I would pursue modernization when a recurring customer limitation, an operating burden, or an architectural constraint prevents valuable work—and when the team can explain how the proposed change addresses it. I would want a credible transition plan and a way to evaluate the result.

I would defer a rewrite whose principal justification is that AI can generate a replacement quickly. I would also defer when we cannot explain existing dependencies or validate migration behavior. In those cases, a smaller investigation or an isolated change may create the evidence needed for a larger decision.

Product leaders should revisit both sides of the decision: the cost of continuing with the current system and the full cost of changing it.

AI may reduce enough of the implementation effort to make a major change worthwhile. The responsibility is to recognize that opportunity while accounting for the customers, workflows, and systems that must make the transition with us.