AI mapped 150,000 lines of legacy code overnight. Monday morning, the real work started.

July 10, 2026

Andrzej Martens CEO

That overnight is real. AI agents can inventory a legacy PHP e-commerce codebase – every file, every dependency, every function – and produce by breakfast a map that used to take a senior engineer three weeks.

Monday morning is also real. That’s when someone reads the map and figures out what to do with it. The map is not the modernization. It’s the point where the modernization can start being planned honestly.

If you’re comparing agency proposals that mention AI, this piece is about the gap between the two – what AI does in the overnight, what it doesn’t do on Monday morning, and what that means for the pitches on your desk.

What the market is selling about AI legacy code modernization

There’s a story going around about AI legacy code modernization. It goes: AI now reads your code, understands your business rules, generates tests, refactors modules, and cuts modernization timelines by 40-50%. That number is cited from McKinsey, echoed by BCG, reprinted across IT strategy websites.

The number isn’t wrong. It’s just built for someone else.

The 40-50% comes from enterprises modernizing hundreds of legacy systems at once. Cost centers with governance boards. Not companies with one legacy PHP e-commerce platform that’s been patched by three teams over eight years, where the question “where does the discount logic live” has several answers, all of them partially correct.

Dig into where the 40-50% comes from and it splits: 40-50% acceleration on code understanding and documentation, yes – but on understanding business intent, the actual “why” behind decisions in the code, AI saves you zero percent. That part still takes people. Talking to you, mostly.

That’s the part that isn’t in the pitch deck.

What the overnight actually delivers

Which doesn’t mean AI is useless. Used well, it changes three things in a legacy takeover.

Reading what’s in the code.

The overnight map from the top of this piece – that’s this. But here’s its limit: the map tells you what’s there, not what matters. Fifteen thousand functions, inventoried and cross-referenced, and no indication which twelve of them hold your revenue together. A human still ranks the map. What changed is that the ranking now starts from a complete picture instead of a partial one – and starts on Monday instead of in week three. The map that took two weeks now takes a night. The audit that follows still takes a team – but it starts from a complete map, not a partial one.

Mapping dependencies.

Legacy systems have hidden coupling. Function A silently depends on the specific behavior of Function B, written five years ago by someone who no longer works here. Finding those threads used to be slow and manual. AI finds them fast. Not perfectly – it misses things, and it flags things that aren’t real. But senior engineers who used to grep through code all day now check a shortlist.

Translating code into English.

This one matters most for you. AI can read a 300-line function and explain, in plain language, what it does. When it says “this appears to calculate a loyalty discount for customers who have placed more than five orders in the last twelve months, with a special case for orders from Germany,” you can verify that against how your business actually works. You couldn’t do that from raw code. Now you can.

They also change what an audit costs – and how. The cost doesn’t disappear; it moves. You stop paying for weeks of a senior engineer reading code and start paying for two things instead: AI processing (real money at this scale, but a fraction of engineering weeks) and senior hours spent verifying what the AI produced. That second line is where audits now succeed or fail. An agency that budgets generously for verification understands the work. An agency whose quote is all AI and no verification hours is quoting you for the overnight and hoping you won’t ask about Monday.

What Monday morning looks like

Now the harder part of AI legacy code modernization.

AI won’t tell you why your codebase has a special case for customer ID 47. It sees the special case. It cannot know that customer 47 is your largest B2B account, that the special case was added after a call in 2021, and that removing it would cost you the contract.

Stack Overflow’s 2025 developer survey found 84% of engineers using AI coding tools, but only 60% viewing them favorably – down from 70% two years earlier. The most common complaint, from two thirds of respondents: AI output that is “almost right.” Not wrong enough to catch. Not right enough to trust. In an e-commerce platform, “almost right” looks like a discount calculated incorrectly for 3% of orders – quietly, for a quarter, until someone in accounting asks a question.

In a takeover project, everything is what surrounds it. The code is the visible part. The undocumented rules, the compliance decisions, the customer-specific carve-outs, the reasons a piece of logic exists – that’s the system. AI reads the visible part fast. The rest still comes from people. From your team walking a senior engineer through what actually matters. From whoever built the original system, if you can still reach them. From you. That’s where ownership actually lives – not in who wrote the code, but in who takes responsibility for understanding what it does and what happens when it breaks.

There’s a flip side worth knowing: the more of that context AI is given, the better it performs. An AI that knows you run B2B e-commerce with custom contract pricing reads your discount logic very differently than one that’s guessing. Which means how much an agency asks about your business before touching your code tells you something about how they’ll use the tools. Hold that thought – it comes back in a moment.
One more thing AI doesn’t shortcut: tests. When AI writes tests for code that has no test coverage, it writes tests that pass. Whether those tests are testing the right thing – the actual business behavior, the edge cases that matter – is a separate question. Without existing tests as a pattern to follow, AI is guessing what to check. That guessing is the moment where the whole exercise becomes theatre.

Red flags to watch for

Here’s what to listen for in the next pitch.

“AI will write your tests.” Fine. Who verifies that the tests are testing the right thing? If the answer is “the AI,” the answer is nobody. Ask for the human check.
“We’ll analyze your business rules with AI.” Also fine, in principle. Follow-up: how do you confirm the rules the AI extracted are complete? Legacy code holds decisions that aren’t in any comment. Without someone from your team validating what came out, the output is a plausible summary, not the truth.
The agency doesn’t ask about your business context before quoting the audit. This one’s telling. AI tools work well when they know what industry you’re in, who your customers are, what your business actually does. An agency running a generic pass over your code will burn hours on things that don’t matter and miss things that do. If they don’t ask, they’re running a universal tool. You’ll pay for the universality.
“AI will just rewrite the messy parts.” No. That’s the pitch of someone who wants to skip understanding. Rewriting without understanding is how you turn one legacy system into two.
No mention of test coverage anywhere in the plan. If AI is doing anything meaningful in your modernization and nobody is talking about how you’ll know it worked – you’re being sold speed you can’t verify.

What this means for you

Used well, AI in legacy code modernization should make the project cheaper, faster, or more thorough. Not all three at once. An agency promising all three either hasn’t done this yet or doesn’t understand the trade-offs.

The question isn’t whether an agency uses AI. Most will, within a year, if they don’t already. The question is whether they use it to accelerate work that still gets done – or to skip work that still needs doing.

A sound modernization with AI in it has a shape you can check any proposal against: map first (the overnight), then validate the map against your business (people, including yours), then build the test safety net, and only then change code. Any proposal that reorders this – changes before tests, tests before validation – is optimizing for the part that demos well.

You can tell in one meeting. Ask how they’d audit your code, and listen for whether the answer describes people or software. Ask what they’d verify by hand, and listen for whether “by hand” is a real list or an empty one. Ask about tests, and listen for whether the answer is a process or a promise.

What you’re really evaluating is where the ownership sits. Not who wrote the code – who takes responsibility for understanding what it does now, and for fixing what breaks tomorrow.

If you’d concluded that fixing your legacy without a full rewrite was out of reach – it’s worth another look. The ground has shifted. What wasn’t realistic two years ago is now.

The overnight is easy. Monday morning is what you’re actually paying for.

Andrzej Martens

CEO @ EfficientWeb

Talk to us about what your legacy actually needs. We’ll tell you what we’d tell anyone in your position.