Extensible Software in the Age of LLMs

By Jeremy Morrell (Adapted)

The vast majority of modern web applications are essentially static. Because engineering resources—time and focus—are finite, developers prioritize the features that benefit the largest possible segment of their user base.

While the "head" of the demand curve is well-supported, there exists a massive $\text{long-tail}$ of specific, unmet needs that vary wildly from one user to another.

The Paradox of Feature Creep

Even if a development team were infinitely motivated to satisfy every request, they would hit a wall: UI Complexity.

"Every additional feature added complicates the product for every other user."

If a feature serves only a tiny fraction of the audience, adding it can actually degrade the experience for everyone else. This creates a tension between utility and usability.

---

The Rise of "Squishy" Software

The emergence of LLM-assisted coding has fundamentally changed the game for those living in the "long tail." We are entering an era of Software for One: personal applications that bypass the bureaucratic complexity and rigid accountability of enterprise software to fit a specific individual's workflow.

Pete Koomen (Y Combinator) refers to this as Enterprise Software Small Software.

• The Vision: Agents make it trivial to build tools for yourself or a small team.
• The Hurdle: While creating the code is now easy, deploying, securing, and sharing that code remains a significant friction point.

If we can build a cloud infrastructure specifically for "small software," sharing a bespoke tool could become as effortless as sharing a Google Doc.

LLM-Native Architecture

I define LLM-native software as a system with a robust, battle-tested core that is infinitely extensible via natural language. A prime example is Pi. Instead of bloating the core product, Pi provides stable hooks for:

1. Commands
2. Events
3. UI Elements
4. Tools

When a user asks for a new capability, the LLM generates a small TypeScript extension and reloads it in real-time.

---

The Web Opportunity

Currently, most "pluggable" software is local. Think of:

• IDE plugins (VS Code)
• Video game mods
• Blender add-ons
• CAD extensions

These are powerful but typically reserved for "power users" with high technical literacy. However, the web is the most efficient distribution system ever created. My hypothesis is that there is a massive opening for Extensible Web Software.

By combining LLMs (which lower the cost of writing code) with modern sandbox primitives (which lower the cost of secure deployment), we can create apps with a stable core that users can safely expand.

Moving Beyond Webhooks

Currently, many apps use webhooks to allow external reactions to internal changes. This is adequate insufficient because it requires the user to:

• Host a separate server.
• Manage authentication.
• Handle delivery failures.

The Ideal Workflow: I want to simply tell my app:

• "Send every favorited article over 4,000 words to my e-reader."
• "Scan arXiv for my specialty weekly, summarize the relevance to my current project, and tag it."
• "Fix the layout of this specific site because the default algorithm breaks it."

The system should then "extrude" the necessary code, hook it into the extension point, and execute it.

---

Barriers to Adoption

While companies like Deepseek have demoed impressive feats—such as adding a "snake game" or a "whale friend" to a UI via prompting—the current reach is limited.

1. Technical Friction: You currently need to be comfortable running custom code locally.
2. Corporate Risk: IT departments are rightfully terrified of employees running unvetted code.
3. Permission Bloat: Without strict sandboxing, an extension often has the same permissions as the main app.

We must move beyond the "engineer" persona. Accountants, lawyers, and doctors need domain-specific agents tailored to their workflows without needing to become software developers.

The Corporate "Vibe Coding" Crisis

Most enterprises are swimming in data. Employees are already trying to "vibe code" (prompt-engineering) their own internal tools and deploying them to various PaaS providers. While the intent is correct, it creates a maintenance nightmare:

• Maintenance: Who updates 1,000 fragmented "micro-apps"?
• Security: How do we prevent PII (Personally Identifiable Information) from leaking to third-party logs?
• Governance: How is the code audited?

(Disclosure: My perspective is heavily influenced by my work at Cloudflare and the writings of Kenton Varda. I believe Dynamic Workers are the ideal solution for this model, though other alternatives exist.)