We have been tightening the product definition for Vifu.

AI-native games are getting easier to prototype. The harder part is turning a prototype into something that can run, connect to AI and persistent agents, preview close to production, and eventually publish.

That is the layer we want Vifu to own.

Vifu is the AI-native game runtime platform: the runtime and backend layer for AI-native web games and playable experiences.

This does not mean Vifu replaces a game engine, asset creation, or the creative development workflow. A creator should be able to keep their current work in progress, their code editor, their assets, and their way of building. Vifu should provide the runtime path around that work: local preview, backend APIs, agent integration, release metadata, and publishing.

Why the IDE and CLI matter

The desktop IDE alpha is not meant to be a generic IDE. It is a local workspace for AI-native playables.

The goal is to let creators open or create a project, run it locally, preview it through the Vifu-compatible runtime path, manage assets, inspect the project, and use the same CLI-backed flow for create, run, test, build, generate, and publish.

Creators should not have to leave their own working environment just to make the game compatible with Vifu. They should also not need to operate their own backend before they can confidently publish.

Some users will write most of the game themselves. Some will start from templates. Some will use our internal agents through the CLI to generate playable code, then iterate. Some will use external coding agents such as Codex or other code agents inside their normal workflow.

Vifu should support that shape instead of forcing one workflow.

Runtime platform, not a full production stack

The runtime platform definition is intentionally narrow.

Vifu should help with:

• running browser-compatible games through a stable runtime path
• connecting games to managed AI endpoints, identity, session state, and persistent agents
• exposing game state, events, actions, resources, and host capabilities through the Vifu SDK
• previewing local builds in a way that matches the publish/runtime path
• publishing AI-native playable experiences without rebuilding backend and release infrastructure

Vifu should not try to replace:

• the game engine
• asset creation
• game design
• the creator's code editor
• the user's existing work in progress

This boundary is important. We want Vifu to be useful to developers, designers, and creators who have ideas, code, assets, or partial prototypes, but do not want to build and operate the runtime/backend layer themselves.

What we are preparing

The next development milestone is the desktop IDE alpha.

The alpha should make the local path clearer:

• open and manage a local game workspace
• run and preview browser-compatible games
• manage assets and template-based projects
• use CLI-backed commands from the desktop surface
• run coding agents to iterate on source code
• connect the result to the Vifu runtime and publishing path

This is still development work, not a finished platform claim. But the direction is now clearer: Vifu is not just a site, an SDK, or a companion feature. It is the runtime platform that helps AI-native playable experiences move from local work to something users can actually run, test, share, and publish.