In the Age of Vibe Coding, How Does RSS Become the Best Distribution Solution for Personal Micro-Apps?

When Building Apps Becomes as Simple as Publishing Blog Posts

An interesting trend is emerging: with the rise of Vibe Coding, more and more developers are rapidly producing large numbers of small tools and micro-applications. These apps are highly personal, context-specific, and updated with extreme frequency. Matt Webb recently proposed a seemingly retro yet remarkably forward-looking idea—we need to use RSS to share these emerging vibe-coded apps.

Simon Willison strongly agreed and quickly put it into action, having Claude add an Atom feed and icons to his /elsewhere/tools/ page, enabling subscription-based distribution of his tools page.

What Is Vibe Coding?

Vibe Coding is an emerging AI programming paradigm: developers describe their needs to AI in natural language, and AI rapidly generates usable code and applications. This approach dramatically lowers the barrier to software development, making the cost of "building a small tool" approach that of "writing a blog post."

The concept was first coined by Andrej Karpathy (OpenAI co-founder, former Tesla AI Director) in early 2025. He described his state when using AI to code as "fully immersed in the vibes, embracing exponential growth, forgetting that code even exists."

Core Tools and Workflow of Vibe Coding

The core tools of this paradigm include Cursor, Windsurf, Replit Agent, Claude Code, and other AI coding assistants that can generate complete functional modules or even entire applications from natural language instructions. Unlike traditional GitHub Copilot-style code completion, Vibe Coding emphasizes end-to-end application generation—developers act more like product managers than programmers, completing development through describing requirements, reviewing results, and iterating with feedback.

The rise of this paradigm is directly related to the leap in large language model (LLM) code generation capabilities, particularly the breakthrough performance of models like Claude 3.5 Sonnet and GPT-4o in code understanding and generation.

The Technical Evolution Behind Vibe Coding

The emergence of Vibe Coding is not accidental—it's the natural evolution after AI-assisted programming went through three distinct phases. The first phase was code completion (2021-2022), represented by GitHub Copilot, where AI provided line-level or function-level auto-completion suggestions while developers wrote code—essentially a smart Tab key. The second phase was conversational programming (2023), where ChatGPT and Claude enabled developers to generate code snippets through conversation, though they still needed to manually copy-paste into their projects. The third phase is Vibe Coding (2024-2025), where AI coding assistants directly manipulate project files, run terminal commands, and debug errors, while developers only need to describe intent and review results.

The underlying driving force of this evolution is the capability leap in large language models' code understanding—from GPT-3.5 to Claude 3.5 Sonnet, model context windows expanded from 4K tokens to 200K tokens, enabling them to understand and operate on entire codebases rather than isolated code snippets. This quantitative change in context capability triggered a qualitative shift in workflow: AI no longer just completes a line of code, but can understand an entire project's architecture, dependencies, and business logic, enabling truly end-to-end application generation.

This brings about a fundamental change: the speed and volume of application production has undergone a qualitative shift. In the past, releasing an app was a carefully prepared big event; now, it's more like a part of daily expression. Everyone might own dozens of micro-tools built for specific scenarios, and the value of these tools often lies in sharing them.

Why Use RSS to Distribute Vibe Coding Apps?

Traditional Distribution Methods Can't Keep Up

When apps become abundant and frequent, traditional distribution methods (app stores, sharing links on social media) feel clunky and inefficient. Matt Webb keenly observed:

When vibe-coding accelerates app development, apps become more personal, more context-specific, more frequent. Publishing a tool or micro-app no longer feels like launching a website—it's more like publishing a post on a blog.

Matt Webb is a British designer and technology thinker who co-founded the renowned design consultancy Berg London, known for exploring interaction design in IoT and internet products. He has long focused on the "small internet" and personal technology topics and was an active participant in Web 2.0-era blog culture. His proposal to distribute vibe-coded apps via RSS extends his consistent design philosophy: technology should serve personal expression rather than being monopolized by platforms.

This proposal also echoes the spirit of the "Small Web" movement in recent years—advocating a return to personal websites, independent publishing, and a de-platformed internet ecosystem. The core argument of this movement is that the internet shouldn't be dominated by just a few super-platforms (Google, Meta, X/Twitter), and individuals should own their own digital spaces and distribution channels. Representative projects include IndieWeb (a community standard collection advocating interconnected personal websites, defining protocols like Webmention and Micropub that allow independent sites to interact like social networks), Mastodon (a decentralized social network based on the ActivityPub protocol), and the Gemini protocol (an internet protocol simpler than HTTP that deliberately limits features to return to content itself).

The rise of this movement is closely related to several factors: social media platform algorithms' monopolistic control over content visibility, the policy turmoil of Twitter/X after 2023 that drove mass exodus of tech community users, and the EU's Digital Markets Act (DMA) legislative push for platform interoperability. In this context, using RSS rather than some new platform to distribute vibe-coded apps is not just a technical choice but a statement of values—choosing open protocols means choosing to give creators rather than platforms control over distribution.

Since publishing apps increasingly resembles publishing blog posts, the most successful content distribution protocol from the blog era—RSS/Atom—naturally becomes a choice worth revisiting.

The Natural Advantages of the RSS Protocol

RSS (Really Simple Syndication) was first born in 1999, developed by Netscape for its portal site. Atom was standardized by the IETF in 2003 as an alternative protocol, resolving RSS's multi-version fragmentation problem. Both share the same core principle: content publishers maintain a structured XML file (feed) on their server containing the title, summary, link, and timestamp of their latest content; subscribers' readers (such as Feedly, Inoreader, NetNewsWire) periodically poll these feed files to pull new content.

RSS experienced its golden age between 2005-2010, with Google Reader being the largest RSS reader, but after Google Reader shut down in 2013, RSS's mainstream usage rate dropped dramatically as social media's algorithmic recommendations replaced active user subscription. However, RSS never truly died—the podcast ecosystem is still entirely built on RSS to this day, and the tech community has consistently maintained active RSS usage habits.

The podcast domain's success provides an important reference model for RSS in micro-app distribution. Over 4 million podcasts worldwide are still distributed via RSS feeds—when creators publish a new episode, the audio file's link and metadata are written into the RSS feed, and clients like Apple Podcasts, Spotify, and Overcast periodically pull these feeds for updates. The reason this ecosystem has been able to operate continuously for over twenty years lies in RSS's neutrality as an intermediary layer protocol: creators aren't locked into any single platform, listeners can freely choose their client, and new podcast apps can tap into the entire ecosystem without permission. Notably, Spotify has attempted in recent years to break this open ecosystem through exclusive content and proprietary APIs, but has faced widespread resistance from creators and users—which proves the resilience of open protocols from the opposite side. If micro-app distribution can replicate the open architecture of the podcast ecosystem, it could potentially avoid repeating the mistakes of app store monopolies.

RSS possesses several characteristics that are highly aligned with current personal app distribution needs:

• Decentralized: No dependency on any platform; creators fully control their distribution channels
• Standardized: Mature protocol specifications with a rich ecosystem of tools
• Lightweight: Suitable for high-frequency, fine-grained content updates
• Subscribable: Users actively choose what to follow, resulting in a high signal-to-noise ratio

Imagine this scenario: you subscribe to the tool feeds of a few developers you trust in your RSS reader, and whenever they quickly build a useful small tool with AI, a new entry appears in your reader with an "Install" button. This experience is both elegant and efficient.

The Key Unsolved Problem: Install to Where?

When Matt Webb proposed this vision, he honestly left behind a follow-up question: "But install to where?"

This question reveals the core gap in the current ecosystem. RSS solves the problems of "discovery" and "subscription," but the runtime environment, installation mechanism, and security sandbox for vibe-coded apps are not yet in place. We need to consider:

• Are these micro-apps Web Apps running in the browser, or native apps?
• How do we handle permissions and security?
• Do we need a new infrastructure similar to a "personal app runtime"?

The Closest Technical Solutions Currently Available

From a technical dimension, there are several directions worth watching:

PWA (Progressive Web App) allows web pages to be "installed" to a device's home screen and run offline, but its capabilities are limited by the browser sandbox. WebAssembly (Wasm) can run code at near-native performance in the browser, providing possibilities for complex applications.

More cutting-edge explorations include "edge function" runtimes provided by platforms like Deno and Val Town, where users can deploy and run small server-side applications written by others with one click. Additionally, Apple's App Intents framework and Android's Instant Apps also provide possible paths for lightweight app execution.

The Deeper Challenges of Security and State Persistence

The question "install to where" involves several intertwined technical difficulties. First is the security sandbox problem: unlike reading a blog post, running code written by others poses potential security risks—malicious code could steal user data, abuse system resources, or conduct network attacks. The browser's Same-Origin Policy and Content Security Policy (CSP) provide a degree of isolation, but are far from sufficient for apps that need access to the local file system or hardware devices.

Second is the state persistence problem: where should data produced by micro-apps be stored? The browser's localStorage has limited capacity (typically 5-10MB), and while IndexedDB is larger, it lacks cross-app data interoperability. How user data flows between different micro-apps, how it's backed up, and how it's migrated—these are all design problems that remain unsolved.

Some cutting-edge projects are exploring solutions. Anthropic's MCP (Model Context Protocol) attempts to standardize how AI applications interact with local data sources, enabling AI tools to securely access users' files, databases, and APIs. WASI (WebAssembly System Interface) aims to provide secure system-level API access for WebAssembly applications, allowing code running in a sandbox to interact with the operating system in controlled ways. These technologies are still in early stages, but they collectively point toward a possible future: a standardized, secure personal micro-app runtime environment.

However, there is currently no unified, secure, user-friendly "personal micro-app runtime" standard, which is exactly the infrastructure gap that Matt Webb's open question points to.

Simon Willison's Practice: Using AI to Build Distribution Channels for AI Tools

Simon Willison's rapid response is itself the best footnote to this trend. He had Claude (AI) add an Atom feed to his tools page—using AI to build the distribution infrastructure for AI tools—a recursive practice that carries significant symbolic meaning.

Simon Willison is the co-creator of the Django web framework, and in recent years has become one of the most active practitioners in the AI tools space. His Datasette (an open-source tool for exploring and publishing data) and LLM (a command-line tool for interacting with large language models) are widely popular in the developer community.

Datasette is an open-source project he launched in 2017, with the core concept of instantly transforming any SQLite database file into a browsable, searchable, API-accessible web interface. This tool is widely used in data journalism, government open data, and research data sharing, with its plugin ecosystem exceeding 100 extensions. LLM allows users to interact with various large language models—including OpenAI, Anthropic, and local Ollama—through a unified command-line interface, storing conversation history in a local SQLite database. This design reflects his consistent philosophy that "data should belong to the user."

His tools page tools.simonwillison.net gathers numerous single-page web applications rapidly developed with AI assistance from Claude, GPT-4, and others, covering scenarios like data visualization, text processing, and API debugging. Willison's practice itself is a typical case of Vibe Coding: he frequently shares on social media how he generates a complete tool through AI conversation in just a few minutes.

Most of these tools adopt a pattern he calls "single-file HTML applications": the entire app is packaged in one HTML file with all CSS and JavaScript inlined, requiring no build tools, no package managers, and no servers—users simply open the file in a browser to use it. This minimalist distribution form naturally complements RSS's lightweight characteristics—each entry in an RSS feed points to a self-contained HTML file, users click and use, with no installation, no dependencies, and no permission pop-ups. This is perhaps the most pragmatic early answer to the "install to where" question: for the vast majority of lightweight tools, the browser itself is the best runtime.

Now these tools can be subscribed to and tracked via the standard RSS/Atom feed protocol—anyone can simply add his feed URL to their RSS reader to discover his newly published tools as soon as they're released.

Looking Ahead: A Personal Software Renaissance Is Coming

We may be standing at the beginning of a "personal software renaissance." When Vibe Coding drives the marginal cost of creating apps toward zero, software will return from being an industrial product to being a medium for personal expression. And to make this ecosystem flourish, what we need is not yet another app store, but open, decentralized distribution protocols like RSS.

This idea may seem nostalgic, but it actually points to the future. Just as blogs in the 2000s turned everyone into a publisher, Vibe Coding combined with RSS distribution has the potential to turn everyone into a software creator and distributor. The difference is that this time we don't need to build infrastructure from scratch—the RSS protocol has existed for over twenty years, with a mature and stable ecosystem of tools. All we need to do is give it a new mission.

Key Takeaways

• The essence of Vibe Coding: Coined by Andrej Karpathy, it represents a new paradigm of end-to-end app generation driven by natural language through AI—the third evolutionary stage of AI-assisted programming, from code completion to conversational programming to complete application generation
• The RSS distribution proposal: Matt Webb proposed using RSS/Atom protocols to distribute and subscribe to personally developed micro-tool apps, continuing the de-platforming spirit of the "Small Web" movement, sharing the same value foundation with projects like IndieWeb and Mastodon
• RSS's enduring vitality: Born in 1999, despite declining mainstream usage, its decentralized, standardized, and lightweight characteristics naturally suit high-frequency, fine-grained app distribution. The podcast ecosystem's 20+ years of successful operation proves the resilience of open protocols
• Core unsolved problem: Where do apps get installed? Technical challenges including security sandboxing, state persistence, and cross-app data interoperability remain to be solved. Emerging standards like MCP and WASI are exploring directions, while single-file HTML apps may be the most pragmatic early answer
• Pioneers in practice: Django co-creator Simon Willison has already taken the lead, using AI to add an Atom feed to his tools page. His "single-file HTML application" distribution model naturally complements RSS, achieving subscription-based distribution of AI tools