A few months ago I wrote about a Chrome App I built in 2015 and abandoned when Google killed the platform. Roku URL Player and Remote. A few thousand installs, a 3.1-star average, and a lot of one-star reviews from people trying to stream YouTube.

I ended that post with "The extension still exists. It still has users. I am not one of them."

Then I came back to it.

How I got the source code back

I no longer had the original project folder. I was reasonably sure I had deleted it at some point, the way you clean up things you have decided to stop caring about.

But Chrome extensions are distributed as .crx files, which are zip archives. The source is right there. I downloaded the .crx directly from the Chrome Web Store CDN, renamed it to .zip, and unzipped it. Three JavaScript files and a folder of SVG icons. ssdp.js was 362 lines. main.js was eight.

The source was sitting in the store the entire time. I just had not thought to look.

What eleven-year-old code looks like

The code works. That was the first thing I noticed. The SSDP multicast logic, the ECP HTTP calls, the channel icon fetching: structurally sound, nothing embarrassing.

The variable names include amuk and tukde. Those are Marathi words, my first language. Pieces, fragments. Not something a linter flags but something that tells you who wrote it and when.

There is a comment in the UI code that says "stop the fucking wheel". The wheel was the loading spinner. I had, at some point, spent enough time debugging why it would not stop spinning that I felt that comment was warranted.

The code is clearly hand-written by one person working alone in the evenings, without documentation, figuring out the Roku ECP protocol from scratch and reading the Chrome Apps socket API while it was still current. That context is visible in the code in ways that are hard to describe precisely.

What I actually wanted to do

I wanted to see what AI-assisted development felt like on a real project with real history, not a toy example.

The honest answer is that it felt like having a fast, patient collaborator who is excellent at execution and needs you to supply all the judgment.

The hard decisions were mine: chrome.socket maps to Node's dgram module, chrome.storage.sync maps to localStorage, chrome.app.window maps to a BrowserWindow. Those mappings were obvious to me because I had written the original and understood what each API was doing. The AI translated them cleanly and quickly. What would have taken me a long weekend of evenings took one session.

The things that required judgment: knowing the URL player was not worth maintaining. Knowing that multi-Roku support was the right thing to add. Knowing that the channel pad mattered. Those did not come from the AI. They came from nine years of watching what people actually used the thing for.

The thing the reviewers wanted all along

The request was there from the beginning. Wilfrido Perez reviewed in August 2015, within the first few months of launch: "I have multiple roku devices in my network. The app always detects one and the find button is disabled. I cant pair the app to any other device in my network." Marc Bernard Schauber reviewed in September 2015: "I have two Rokus and this does not let you choose. So it found the wrong one and won't control the roku I need to control." I had never built that feature because I only had one Roku. The problem was in the data. I did not have the context to recognize it as the problem.

The Electron port discovers all devices on the network simultaneously, fetches their names in parallel, and shows a picker. If there is only one device it connects automatically. If there are two or more it shows a sheet with all of them labeled by their friendly name and lets you switch.

This took about an hour to add, mostly because the architecture made it straightforward: the SSDP scan already runs for several seconds, so collecting multiple responses instead of resolving on the first one was a small change.

The reviews from 2015 said so. I did not have the context to act on them.

What got dropped

The URL player is gone. The companion Roku channel that made it work has gone through enough platform changes that I do not know what state it is in, and I do not want to find out. The remote-control half was always more useful anyway. The blog post I wrote earlier said as much. The Electron app is just a remote.

This felt like the right call. Not everything from the original is worth preserving.

A note on testing

The app has been tested against a Node.js emulator that speaks real SSDP and ECP. It has not yet been tested against physical Roku hardware because I am waiting on two Rokus I ordered off eBay.

If you build it and your physical Roku does not respond, the project is at github.com/abhiapsunde/roku-remote and pull requests are welcome. The emulator in emulator/ will let you develop and test without hardware. The protocol is well-documented and the code is small enough to read in an afternoon.

What I think about AI-assisted development now

I went in skeptical of the hype and came out with a more specific opinion.

AI is fast and accurate at translation tasks: porting an API from one runtime to another, implementing a design from a spec, writing test cases for a function you have already designed. For that category of work it is genuinely useful in a way that changes the shape of an evening project.

It is not useful for knowing what to build, what to drop, or what the product actually is. That requires having shipped something, watched people use it wrong, and read the one-star reviews. The AI did not know the URL player was a dead end. I did.

The part I keep thinking about is this: the most valuable thing I brought to this session was not programming ability. It was the context from nine years of people using something I made. That context is not trainable. You accumulate it by shipping and watching.

The extension still exists. It still has users. I am, briefly, one of them again.