Fourteen hours. One AI coding agent — Claude Code running Opus 4.8. Sixty thousand lines of legacy PHP, rebuilt as a NodeJS/TypeScript backend that had to behave exactly like the original.

That’s the headline everyone wants. But the number isn’t the story. The story is what those fourteen hours actually looked like.

The code in question is a REST service: entirely backend, exposed through authenticated endpoints. The porting requirement was refreshingly clear — reproduce the same endpoints, the same behavior, the same contract. Nothing more, nothing less.

I had one structural advantage that made the whole exercise tractable: my frontend can switch backends with a single URL fragment. Point it at the PHP service, everything works. Point it at the new TypeScript service, everything should work identically. That switch became my ground truth. If a screen behaved the same against both backends, parity held. If it didn’t, I had a bug to chase.

Here’s the part I want to be honest about, because the “the AI did it all by itself” narrative is doing real damage to how teams plan this kind of work.

You cannot leave this unsupervised.

Every so often, Claude Code stopped and asked. It needed clarification on intent that wasn’t obvious from the source. It needed me to exercise the frontend and confirm a behavior before it committed to an implementation. These weren’t failures — they were exactly the right moments to pause. An agent that never asks is far more dangerous than one that does.

So the fourteen hours weren’t fourteen hours of me watching a progress bar. They were fourteen hours of a tight loop: the agent proposed and built, I validated against the live frontend, and we corrected course together. Fast, but genuinely hands-on.

At no point did I ask for tests. On its own initiative, Claude Code wrote unit tests for every backend endpoint.

That matters more than the raw speed. A port you can’t verify is a liability, not a deliverable. Having a test suite generated alongside the code — covering the exact surface I cared about — is what turned “it seems to work” into “I can prove it works.”

By the end, the TypeScript system was up and serving the same level of functionality as the original. Not a prototype. A drop-in replacement.

I’m now porting the same backend to Python to see whether the timing holds. My hypothesis: it lands in roughly the same window.

I also suspect a compiled target — Java or C# — would take noticeably longer. Not because the language is harder, but because the compile step slows the iteration loop and makes it more cumbersome to spin up and run unit tests on the fly. The flexibility of an interpreted, fast-feedback environment is part of why this went so quickly. I’ll report back once I have the Python numbers.

An agent like Opus 4.8 can collapse a multi-week port into a single working day — but only inside a loop with a human who knows the system, a clear notion of “correct,” and a cheap way to check it. The speed is real. The autonomy is not total. And frankly, it shouldn’t be.

If you’re planning a migration like this, don’t budget for a magic button. Budget for a very fast pair-programming partner who occasionally needs you to look up from your desk.

Have you tried an AI-driven port at this scale? I’d like to hear where it broke for you — and where it surprised you.

You can find more of my articles at https://didierphmartin.com.