There's a conversation happening right now in engineering and product leadership at large companies that goes roughly like this: We have fifteen years of technical debt. We've been told for a decade that rewriting it would take two to three years and cost a fortune. Now someone is showing us that AI can do a significant chunk of that work in weeks. So — do we do it?

The answer, increasingly, is yes. And the projects are starting.

What's interesting is how familiar the team composition looks when these projects kick off. You need engineers, obviously — to direct the AI tooling, validate the output, and own the technical decisions. You need QA, because generated code still breaks in ways that need human eyes. You need product management, because requirements don't write themselves and someone has to decide what the new system actually does. These roles all have clear analogs. Everyone knows why they're in the room.

Then there's a role that most modernization projects either skip entirely or bring in too late. The person who understands the system from the user's side — not the code side, not the requirements document side, but the lived-experience side. The person who can answer questions like: Why do users open three windows simultaneously to complete this task? Why does everyone ignore this button? What is this field actually being used for, versus what it was designed for?

That's the missing person.

The System Knowledge Problem

Every legacy product, without exception, has accumulated something that doesn't appear in any documentation: a layer of workarounds, compensating behaviors, and tribal knowledge that users have built up over years to make the system actually work for them.

The formal workflow says: do A, then B, then C. The actual workflow — the one your most experienced users follow — says: do A, skip B entirely because it's broken, do C, then go into this other screen and manually fix the thing that C got wrong, then export to Excel because the reporting module never worked properly.

None of that is in the codebase. None of it is in the requirements document. It lives in the heads of the people who use the system every day, and in the subtle ways the interface has been shaped over time to accommodate what people actually need versus what the original designers intended.

When you rewrite a legacy system without someone doing that archaeology first, you make a very expensive mistake: you faithfully recreate the documented system, clean up the technical debt, and ship something that is faster and more maintainable — and which breaks the workflows that users actually depend on. Not the workflows anyone knew about. The ones nobody wrote down.

The support tickets start coming in. Users say the new system is worse. Engineering is confused because it objectively isn't. And the project, which was supposed to be a win, becomes a controversy.

What the Work Actually Looks Like

The UX role in a legacy modernization project isn't primarily about designing new screens. It's about understanding the existing system deeply enough to know what has to be preserved, what can be improved, and what can finally be cut.

That means sitting with the people who use the system — not in formal research sessions with clipboards, but in the actual workflow, watching what they do, asking why, learning the system from the inside. It means building relationships with the engineers who built the thing and know where the bodies are buried. It means being the person in the room who can say: that field looks like it's doing one thing but it's actually doing three things, and if we simplify it the way the new design suggests, we're going to break the invoicing workflow for the east coast team.

It also means being present during the build, not just at the beginning and end. AI-assisted development moves fast. Decisions get made at speed. If design input only happens at the requirements phase and the QA phase, entire interaction patterns get locked in before anyone with user context has seen them. The embedded model — where the designer is in the daily engineering conversation, giving feedback in real time, catching things before they ship — is the only model that actually works at this pace.

This is not glamorous work. There are no beautiful prototypes to show at the all-hands meeting. The value is almost entirely invisible until something goes wrong — and when the work is done well, nothing goes wrong, which means the designer gets very little credit. That's fine. That's the job.

Why This Moment Is Different

Senior designers have always understood the value of system knowledge. What's changed is the stakes.

When a system gets rewritten manually over three years, there's time to discover the workarounds and compensating behaviors organically. Someone notices the invoicing problem six months in. It gets fixed. The project absorbs it.

When a system gets rewritten in weeks, there's no time for organic discovery. The decisions are made fast, the code is generated fast, and the thing ships. If nobody was doing the UX archaeology in parallel — mapping the real workflows, identifying the load-bearing behaviors, flagging the invisible dependencies — that work simply doesn't happen. And the mistakes it would have caught go into production.

The speed that makes AI-assisted modernization so compelling is exactly what makes the missing person so costly to leave out.

The Good News

The good news is that this role is not mysterious. It doesn't require a new methodology or a new kind of designer. It requires a senior designer with real enterprise experience, the interpersonal skills to earn trust quickly in an existing team, and the technical fluency to participate in engineering conversations rather than just observe them.

It requires someone who has been in enough legacy systems to recognize what they're looking at. Who knows that the weird thing on screen four isn't a bug to be designed away — it's the thing three hundred users depend on to close their month-end. Who can hold the whole system in their head while the engineers are holding the whole codebase in theirs.

That person exists. Most modernization projects just don't think to look for them until it's too late.

Paul Shellooe is a Principal Product Designer and Enterprise UX Architect with deep experience embedded with Fortune 500 engineering teams. He specializes in legacy modernization and complex enterprise software. Based in Lisbon, Portugal.