Most software products are built for the top of a demand curve, where a limited set of features serves the largest group of users, while a long tail of individual needs is left unaddressed because supporting it does not scale in the traditional sense Most software products are built for the top of a demand curve, where a limited set of features serves the largest group of users, while a long tail of individual needs is left unaddressed because supporting it does not scale in the traditional sense (and attempting to do so often leads to scope creep).. <\/p>\n
Jeremy Morrell argues that large language models change this calculation, since they lower the cost of authoring an extension to the point where serving a single user’s edge case becomes economically viable, provided the surrounding platform can deploy and secure that extension safely.<\/p>\n
The interesting part of the argument is not that LLMs can generate code, which is now a familiar claim, but that the harder problem has always been the deployment and trust boundary around that code, not its authorship. Webhooks require the user to operate a separate service and handle delivery failures themselves, and most local extension models, such as IDE plugins or Obsidian’s ecosystem, ask the user to trust every author whose extension they install, which is a workable tradeoff for a notes app but not for a system holding financial transactions or private messages. Salesforce solved a version of this problem two decades ago by building its own compiler, runtime, and standard library so that customer logic could run safely inside a shared multi-tenant platform, well before serverless made that pattern common.<\/p>\n
What makes the current moment diffferent is that the primitives Salesforce had to build from scratch now exist off the shelf, whether as V8 isolates, WebAssembly with WASI, or microVMs, and each comes with a different tradeoff between cold start latency, isolation strength, and language flexibility. Morrell’s argument for an object capability model over a traditional API proxy is worth sitting with regardless of which runtime a team chooses, since restricting untrusted code to explicit, narrow references such as getApprovedEmail() rather than a scoped API token removes an entire category of exfiltration risk by construction, instead of relying on a proxy layer to catch every malicious pattern after the fact.<\/p>\n
For teams building internal tooling or customer facing platforms, the practical takeaway is that extensibility is no longer purely a UX or roadmap decision, it is also an infrastructure decision, and the primitive chosen early on will determine how much custom logic a platform can safely absorb once users start asking an LLM to write it for them.<\/p>\n
https:\/\/jeremymorrell.dev\/blog\/extensible-software-in-the-age-of-llms\/<\/p>\n","protected":false},"excerpt":{"rendered":"
Most software products are built for the top of a demand curve, where a limited set of features serves the largest group of users, while a long tail of individual needs is left unaddressed because supporting it does not scale … Continue reading