It's Eddy, a self-hosted server management app. It provisions fresh servers and deploys PHP applications with zero downtime. It does one job, perfectly for me: I point it at a server, and my Laravel apps run. It's also a full Laravel application: dashboard, queues, SSH, Caddy config. Roughly 40,000 lines. Pre-AI, you didn't rebuild that over a weekend.

Open source, archived by its author in 2024. And it only knows how to provision Ubuntu 22.04 servers. The latest LTS is now 26.04.

I never expected anyone to revive it. The real alternative was paying for a managed service, but I already had Eddy self-hosted, I loved it, and I didn't want to pay for something I owned. I forked it. That was a dead end too. Eddy is built on Splade, which the same author archived in 2025. Keeping the fork alive meant resurrecting a dead stack first.

So I took a third option. I pointed AI at the original source, told it to rebuild the app with Livewire and Laravel Reverb, and left it alone for 45 minutes. That was the longest I'd ever left an agent alone.

The first shot worked. I gave the rebuild my DigitalOcean credentials, and it provisioned a real server and deployed my app to it. A few UI things weren't polished. But after less than an hour, Eddy itself was running on a current stack for the first time in years.

The surprise? The AI wasn't the hero. My best explanation: the abandoned project itself was the ingredient — a complete, working example of what "done" looks like. One run isn't proof. But if I'm right, you'll know when it's safe to walk away.

The setup was a fresh Laravel app and one prompt:

This is a fresh Laravel app using Livewire and Flux for UI. I want to reimplement project Eddy, mainly because it uses a deprecated stack called "Splade" and I'm more comfortable maintaining a Livewire project. Make a plan for the implementation.

I ran it with ZCode. I pointed it at a clone of the Eddy repo. It read the codebase itself.

I asked for a plan first. It took 25 minutes. The plan proposed Livewire polling for realtime status. I swapped that for Laravel Reverb. You don't poll a provisioning job that runs for minutes. Beyond the prompt, that was all.

Then I went for a walk. I didn't know how long it would take, so I stayed out about an hour. When I came back, it was done. The whole run took 45 minutes.

I expected the worst from provisioning, the core of Eddy. It connects to a server over SSH, uploads bash scripts, and parses the output. If any step fails, the app is useless.

Provisioning worked on the first try.

That was day-one AI code with live access to my cloud account. A fresh key, but on my main account.

Nothing was broken, but the UI wasn't polished. There's a reason for that. The backend had a complete working example to copy. The UI didn't: the old UI framework has no equivalent in the new one. That layer had to be rebuilt from scratch, and it shows.

The rebuild mirrors Eddy's structure. The bash scripts carried over. The core carried over, on Livewire instead of Splade. It's now on Laravel 13, up from Eddy's 10, written the way current Laravel expects. Even the tests were rewritten, from PHPUnit to Pest. They pass.

It still provisions Ubuntu 22.04. Deliberately. I wasn't trying to improve Eddy, not yet. I wanted the same tool on a new stack. Before it becomes my daily driver, the testing list is long: daemons, SSH keys, firewall rules, backups. And then the original reason for this rebuild: Ubuntu 26.04. Now it's a normal upgrade instead of a dig through a dead framework.

What it cost: one prompt, 25 minutes of plan review, a few minutes of corrections. In 70 minutes, the run consumed 92% of my five-hour coding plan quota. In dollars, the rebuild cost nothing extra: it fit inside the $80-a-month plan I already pay. Would I have rebuilt it by hand, over weeks? Honestly, no. I'd have lost steam along the way and dropped it. The agent didn't save me weeks of work. Without it, there was no rebuild.

So why did this work? I think it comes down to the reference. The agent didn't invent Eddy. It transplanted it: every recipe and behavior already written down in code. And I could walk away because I'm Eddy's daily user. I know exactly how I use it, so I knew exactly what to test.

But there's a rival explanation. These models have seen a thousand Laravel-to-Laravel migrations in their training data. Porting an app to a newer version of its own framework is what they're best at. One run can't separate those two explanations. If the reference did the work, this recipe works for any dead tool with a repo. If it's just training data, it only works on familiar ground. Even my own results can't settle it. The backend had a reference and came out clean. The UI had none and came out rough. But Splade apps are rare, so the UI is also the part these models have seen least of. I won't know until I try it on something less popular.