No Play SRF for Tizen? Then AI will just build one.

Play SRF is available as an app for Android TV, Apple TV, and Amazon Fire TV. However, my Samsung TV runs on Tizen. Is there an official app for it? Nope. In this case, SRF recommends screen mirroring or an additional streaming box.

That works. But it's not exactly elegant. I wanted to turn on the TV, open Play SRF, and get started—without a smartphone, without a Cast button, and without another box gathering dust next to the TV.

So I decided to conduct an experiment: Can an AI coding agent analyze the Android TV app and use it to build a working Tizen app?

About an hour later, Play SRF was streaming directly on my Samsung TV.

The result was practical. The more important insight, however, was something else: Our assumptions about what AI can and cannot do are becoming outdated at a damn fast pace.

No conversion with the push of a button

First, a technical clarification: The AI didn't simply convert an Android file into a Tizen file. Unfortunately, the world isn't quite that convenient yet.

Android TV and Samsung Tizen use different app models, UI technologies, media players, package formats, and signatures. Android code does not simply run on Tizen. An APK—the installation package for an Android app—cannot therefore be exported to another format like a Word document.

The better approach: The Android app served as the specification.

The AI analyzed which SRF services the app accesses, how it structures content, and which streams it uses for videos and live TV. Based on this, it implemented a standalone Tizen client as a web app. That is exactly what reverse engineering means in this context: understanding behavior and reimplementing it for a different platform, not copying someone else’s code.

In other words: She didn't copy the engine. She understood what the vehicle was supposed to do and built a suitable powertrain for a different platform.

What the AI Actually Did

The process consisted of several steps that typically require a fair amount of research and specialized knowledge:

1. Find the right Android TV package. Not every Play-SRF file contains the same app. The AI checked the package name, TV-specific components, and platform features.
2. Reconstruct the app's behavior. She identified the relevant SRF interfaces for the home page, programs, search, live TV, and sports.
3. Rebuild the user interface for Tizen. Android TV's components were converted to HTML, CSS, and JavaScript. Navigation and focus had to work with the Samsung remote control.
4. Translate video playback. Regular broadcasts, live streams, and DRM-protected content require different technical approaches.
5. Sign and install the app. Even a private app requires a valid developer certificate to run on a Samsung TV.
6. Test it on the actual device. A browser and emulator are not sufficient for remote control, DRM, and Samsung's Media Player.

The finished app displayed the current Play-SRF lineup, program details, and episodes. Search, live TV, live sports, replays, the watchlist, and playback progress also worked. Everything was controlled using the standard remote control.

Not bad for a spontaneous after-work use case.

The hard part wasn't the surface

A TV interface with a few rows and tiles is easy to navigate. Things got interesting with the video.

An on-demand stream was accessible, but it only displayed a black screen on the Samsung TV. The AI analyzed the network requests and the player's status directly on the device. Two subtitle parameters caused Samsung's player to malfunction. The solution specifically removed only these parameters. Access tokens and other important values were preserved.

Live TV was even trickier. The streams were protected by DRM—digital rights management. Samsung’s native AVPlay player received valid licenses, but still wouldn’t start playing the content. A classic case of: Everything looks good, but nothing works. Great.

Instead of continuing to blindly adjust settings, the AI changed its technical approach. Regular videos continued to play through AVPlay. Protected live streams used Shaka Player via Samsung's web video interfaces.

That meant the livestreams worked as well.

This detail is more important than the specific player. The AI didn't just write code. It observed behavior on real hardware, formulated hypotheses, ruled out dead ends, and chose an alternative architecture. This is exactly where AI coding has changed significantly.

The moment I had to change my way of thinking

In an article from January 2025, Nicola described his attempt to migrate a medium-sized Angular app with AI to React. The goal was to automatically rewrite about 80 components and 20,000 lines of code. After five days, he abandoned the experiment. The effort required for review and fixes was too high. The result could not be validated with a reasonable amount of effort.

His conclusion at the time: AI was a helpful assistant, but not yet a viable tool for extensive rewrites. The whole Case Study on Migrating from Angular to React You can read about it in his article.

My experiment seems to contradict this conclusion. It's not quite that simple.

Migrating a production-ready business application with 20,000 lines of code is a different task than implementing a focused TV app from scratch. During a migration, existing functions, edge cases, and quality requirements must be fully preserved. My Tizen project was tasked with recreating a smaller, clearly defined subset of the product.

So, apples and oranges? Yes. But both fall under the same category—which has become quite fast-paced—of AI cuisine.

The key difference lies in the operating mode. Modern coding agents no longer just process individual prompts. They can explore a repository, analyze external systems, execute commands, write tests, evaluate logs, and work toward a goal through multiple steps. Autocomplete has evolved into a technical agent with a feedback loop.

That's exactly why I had to rethink my previous assumptions.

AI knowledge has an expiration date

We tend to generalize from our past experiences. If a tool fails at a task, then that task is considered “not yet suitable for AI.” This makes sense in mature technology fields.

AI is dangerous.

Models, tools, and work methods evolve simultaneously. A task that was unreliable or uneconomical twelve months ago can now be completed in an afternoon—or even in an hour. Conversely, an impressive demo is far from being a robust production process.

How do you figure out what works today? Not through leaderboards. And not through the hundredth LinkedIn forecast, either. You have to try it out.

Six Rules for Meaningful AI Experiments

You don't need a reverse-engineering project for this. A good experiment starts with a real challenge in your everyday life.

1. Choose a specific outcome

"Try AI Coding" is not a goal. "Get Play SRF on my Samsung TV" Sure. A clear result forces the AI to go beyond just pretty code snippets.

2. First, help the system understand

Please don't ask the AI to rewrite everything right away. Let it explain the architecture, interfaces, data flows, and risks. In my case, the key insight was to use the Android app as a behavioral reference.

3. Establish short feedback loops

Generate code, run it, observe the results, and make corrections. The faster this cycle is, the more useful the agent becomes. Tests, logs, and reproducible build scripts provide it with reliable signals.

4. Test early in a real-world setting

A browser cannot play content on a Samsung TV. DRM, hardware players, and remote control functionality only reveal their unique characteristics when used on the device itself. The same applies to production-ready APIs, real data, and actual user workflows.

5. Evaluate the result, not the amount of AI code

Generating a lot of code isn't progress. What matters are functionality, maintainability, security, and verifiable quality. An agent that produces 10,000 lines of code might just have created a bigger problem for you—very efficiently, in fact.

6. Set clear boundaries

The Tizen app was a private interoperability project. It does not bypass DRM, geoblocking, advertisements, age ratings, or time-based restrictions. I am not publishing either the extracted components or the signed app.

AI lowers the technical barrier. It does not remove legal, security-related, or ethical constraints.

What we can take away from this

The biggest opportunity doesn't lie in having an agent rewrite every existing application tomorrow. That would be bold. Maybe even a little crazy.

A more intriguing question is: Which projects have so far been too small, too expensive, or too specialized to be implemented?

An internal process with many manual steps. A prototype for a new customer journey. An integration between two systems. An old application that, at first, no one really understands how it works. That’s exactly where AI agents can drastically reduce the cost of an experiment.

That changes the equation. Ideas no longer have to be discussed for months on end before you know whether they’ll work. You can build a real prototype sooner, test it on actual infrastructure, and make decisions based on concrete insights.

But speed alone isn't enough. You need people who can refine the goal, evaluate the architecture, and recognize when a compelling prototype is still a long way from a production-ready solution.

At smartive, we don’t conduct these kinds of experiments just for the sake of it. We use them to work with our clients to identify where AI is already delivering real value, what risks remain, and how this can lead to a robust digital solution.

After all, the most important AI skill right now isn't knowing every answer. It's the willingness to regularly question one's own assumptions.

My Samsung TV can now stream SRF. And once again, I realize that when it comes to AI, it’s worth regularly questioning old assumptions.