Beyond the Chatbot: 5 Generative UI Patterns That Get AI Features Actually Used

Most enterprise teams have a system nobody wants to touch. It runs payroll, prices insurance policies, or routes orders, and it has done so reliably for fifteen years. It also runs on an outdated framework, has no tests, and the people who understood it best left the company a long time ago.

When a system gets to this point, someone usually proposes rewriting it from scratch. That tends to be the most expensive option available. Leaving the system alone costs money too, though. McKinsey estimates that tech debt amounts to 20–40% of the value of an organization's entire technology estate, and CIOs report that 10–20% of budget meant for new products gets diverted to dealing with it.

AI coding tools change this. They don't make a rewrite safe. They make the careful, incremental alternative much cheaper, and that alternative has always been the better choice.

Why the big rewrite keeps failing

A rewrite looks clean on a whiteboard. In practice it means:

• Running two systems at once. The old one still needs fixes and features while the new one is being built, so the team is effectively doing the work twice.
• Rediscovering hidden business rules. Years of edge cases, regulatory patches, and one-off customer exceptions live only in the code. A rewrite has to find every one of them, or it breaks something in production.
• Delivering nothing for a long time. The business sees no value until the switchover, and the switchover is the riskiest moment of the whole project.

The alternative is Martin Fowler's Strangler Fig pattern. You grow new functionality around the old system, move traffic over one slice at a time, and retire legacy components only once nothing depends on them. The system keeps running throughout, and each step can be rolled back.

The pattern's weak point has always been cost. Understanding a tangled module well enough to extract it, writing tests to pin its behavior down, and carefully refactoring it takes a lot of slow, expensive engineering time. AI speeds up exactly this work.

Where AI actually helps

1. Understanding code nobody remembers

This is the least glamorous use case, and probably the one that pays off most. Before you can change legacy code, you need to know what it does. AI can summarize modules, trace data flows, explain obscure idioms, and draft documentation for code that has never had any.

The best results come from pairing an LLM with structured analysis of the codebase rather than pasting in raw files. Thoughtworks built a tool that combines an LLM with a knowledge graph generated from the code's syntax trees, and cut reverse engineering of a COBOL mainframe module from six weeks to two.

2. Building a safety net of tests

Legacy systems rarely have good test coverage, and refactoring without tests is gambling. AI can generate characterization tests: tests that record what the code does today, bugs included, so any change in behavior shows up immediately. A human still needs to review which behaviors are intended. Getting a first draft of hundreds of tests in a day instead of a month makes a big difference, though.

3. Large-scale upgrades and migrations

Framework upgrades, language version bumps, and API migrations are repetitive, spread across the codebase, and tedious, which makes them a good fit for AI. Two well-documented examples:

• Amazon used its Q Developer agent to upgrade internal applications to Java 17. According to CEO Andy Jassy, a typical upgrade went from around 50 developer-days to a few hours, saving an estimated 4,500 developer-years of work. Developers shipped 79% of the AI-generated changes without modification.
• Google studied 39 LLM-assisted migrations carried out over twelve months. About 74% of the code changes were generated by the LLM, and developers estimated the total migration time was cut by around 50% compared with earlier manual migrations.

Neither company let the model run unsupervised. Both used AI to produce changes and relied on engineers and existing tooling to review, test, and ship them.

4. Targeted refactoring

Within a single slice of the system, AI assistants are good at mechanical but error-prone work: breaking up very long functions, extracting interfaces so a component can be replaced, removing dead code, and replacing deprecated libraries. Work that used to fill a week-long refactoring ticket can be proposed in an afternoon and then checked against your new test suite.

A practical playbook

Here's how these pieces fit together into a modernization plan that doesn't depend on a single high-risk launch:

1. Map the system first. Use AI-assisted analysis to document modules, dependencies, and data flows. Identify which parts change most often and which carry the most business risk.
2. Pick the first slice. Choose a component that is valuable to modernize but loosely coupled, so you have an early win with limited risk.
3. Pin down current behavior. Generate characterization tests around that slice and have engineers review them before any code changes.
4. Refactor or extract in small steps. Let AI propose changes, keep each pull request small, and require human review on every one.
5. Route traffic gradually. Put the new component behind a facade or feature flag, shift a percentage of traffic to it, and monitor.
6. Retire and repeat. Once the legacy piece is no longer called, delete it. Then choose the next slice.

Each cycle delivers something the business can use, and the team learns something that makes the next cycle faster.

Pitfalls to watch for

AI speeds up modernization, but it also brings new ways to fail.

• Oversized changes. The 2024 DORA report found that greater AI adoption was associated with a drop in software delivery stability, likely because AI makes it easy to produce large batches of change. Keep pull requests small on purpose.
• Confident but wrong explanations. An AI summary of a COBOL routine can sound authoritative and still miss a critical edge case. Treat AI-generated documentation as a starting point to check against tests and subject-matter experts.
• Missing context. Models don't know why a strange-looking rule exists. Before "cleaning up" odd logic, check whether it encodes a regulation or a contractual obligation.
• Security and compliance. Decide which code and data can be sent to which tools, especially in regulated industries, and make sure AI-generated code goes through the same security scanning as everything else.

The bottom line

Most enterprises don't need to rewrite their legacy software. They need to understand it, protect it with tests, and replace it gradually, one well-chosen slice at a time. That approach was always the sound one. It was just slow and expensive. AI makes the slow parts much faster, provided engineers stay in control of what gets merged.

If you have a system everyone is afraid to touch, don't start by planning a replacement. Start by using AI to map it and find the first piece worth modernizing.