Uitbreidbare software in het tijdperk van LLM's

De meeste websoftware waar we vandaag de dag mee werken is statisch. Ontwikkelaars hebben een beperkte hoeveelheid tijd en aandacht, waardoor ze zich concentreren op het bouwen van functies die de grootste groep gebruikers dienen. De top van de vraagcurve wordt goed bediend door bestaande software, maar er is een 'long-tail' van onvervulde behoeften die voor elke gebruiker anders is.

Gebruikersbehoeften in kaartsoftware

Zelfs als ontwikkelaars enorm gemotiveerd zouden zijn om elke mogelijke functie toe te voegen, kunnen gebruikersinterfaces slechts tot een bepaalde mate complex worden voordat ze onbruikbaar worden. Elke extra functie compliceert het product voor alle andere gebruikers. Als de markt voor die specifieke functie klein is, kan het het product actief verslechteren voor iedereen die die functie niet nodig heeft.

In deze context is de opkomst van door LLM's ondersteunde codering werkelijk empowerend voor iedereen die behoefte heeft aan iets dat in die 'long-tail' valt.

Software is "kneedbaar" geworden

Het is duidelijk geworden dat LLM's uitstekend zijn in het bouwen van Software voor Eén. Persoonlijke applicaties die alle complexiteit en verantwoordelijkheid van enterprise-software omzeilen en precies zijn afgestemd op de workflow van één persoon.

Pete Koomen van Y Combinator ziet hierin een kans voor wat zij "Small Software" noemen. Agenten maken het eenvoudig om persoonlijke tools te bouwen voor jezelf of je team. Echter, het implementeren, beveiligen en delen van die software is nog steeds veel ingewikkelder dan het creëren ervan. Een cloud die specifiek is gebouwd voor small software zou die complexiteit kunnen wegnemen en op maat gemaakte tools net zo makkelijk deelbaar maken als een Google Doc.

Pi is een goed voorbeeld van wat ik beschouw als LLM-native software: een beproefde kern, maar bijna eindeloos uitbreidbaar door simpelweg erom te vragen, waarbij gebruikers hun aanpassingen met anderen kunnen delen. In het afgelopen jaar hebben gebruikers plotseling het vermogen gekregen om code 'uit te spreken'. De meeste bestaande software kan hier geen gebruik van maken; Pi doet dat wel.

Ik vermoed dat we meer software zullen zien die dit patroon van zelf-extensie volgt. De meeste huidige voorbeelden van pluggable software zijn echter lokale programma's: AI-agenten, IDE's, mods voor videogames, Blender-add-ons of CAD-extensies. Dit zijn vaak professionele tools met een hoge instapdrempel.

Het web is het meest succesvolle distributiesysteem voor software ter wereld. Dat zou niet achter moeten blijven. Mijn hypothese is dat er een nieuwe kans is voor Extensible Software op het web. LLM's verlagen de kosten voor het schrijven van extensies drastisch, en moderne sandbox-primitieven verlagen de implementatiekosten en bieden goede beveiligingsgrenzen. We kunnen onze app bouwen als een solide, betrouwbare kern en gebruikers toestaan deze veilig uit te breiden door LLM's de ontbrekende stukjes te laten invullen.

Disclaimer: Ik werk momenteel bij Cloudflare, waar de geschriften van Kenton Varda mijn denken hierover sterk hebben beïnvloed. Ik zal later beargumenteren waarom Dynamic Workers goed passen bij dit model, maar eerst behandel ik enkele alternatieven.

Hoe zou dit eruitzien?

Veel websystemen vertrouwen vandaag de dag op webhooks om gebruikers in staat te stellen te reageren op wijzigingen in de app. Dit werkt redelijk, maar stelt een hoge lat voor extensies: men moet een volledig aparte service bouwen en beheren, inclusief het oplossen van leveringsproblemen.

Ik wil kunnen inhaken op record-updates en mijn eigen logica kunnen toevoegen. Bijvoorbeeld: "Wanneer ik deze tag aan een record toevoeg, voer dan mijn functie uit" of "Voer deze actie dagelijks via een cron-job voor mij uit".

Eigenlijk wil ik daar helemaal niet over na te hoeven denken. Ik wil mijn 'read-it-later' app simpelweg vertellen:

  • "Stuur elk artikel dat ik favoriet markeer en langer is dan 4000 woorden naar mijn e-reader."
  • "Zoek elke week naar nieuwe papers op arXiv binnen [mijn specialisme], voeg bovenaan een samenvatting toe over hoe dit relateert aan mijn werk, en tag het met [tag]."
  • "Het standaardalgoritme maakt een puinhoop van [website die ik vaak lees]. Pak een paar voorbeelden en maak een custom parser hiervoor."

En dan zou een robot de benodigde code moeten genereren, deze op de juiste extensiepunten moeten koppelen en het uitvoeren. Ook zou ik dit moeten kunnen delen met anderen die dezelfde functie willen.

Toepassingsgebieden voor LLM-native extensies

AI-Agenten

Dit is de meest voor de hand liggende toepassing. Pi, Deepseek en OpenCode experimenteren hier al mee. In plaats van elke nieuwe functie aan de kern toe te voegen, biedt Pi stabiele hooks voor tools, commando's, events en UI. Zo kan een verzoek worden omgezet in een kleine TypeScript-extensie die ter plekke wordt geladen. Deze extensies kunnen worden gebundeld in pakketten die gedeeld kunnen worden.

Het probleem is dat de huidige doelgroep klein is; je moet comfortabel zijn met het draaien van custom software op je lokale machine. In bedrijfsomgevingen is men vaak niet bereid software te draaien die niemand ooit heeft gecontroleerd. Tenzij je Pi zelf sandboxed, draaien extensies met dezelfde rechten als Pi zelf. Accountants, artsen en advocaten verdienen betere tools: agenten die veilig en eenvoudig kunnen worden aangepast aan hun domein en workflow.

Interne Bedrijfsplatforms

Bedrijven verzamelen enorme hoeveelheden data. Werknemers moeten dit kunnen inzien, bevragen en correleren. Veel bedrijven experimenteren nu met 'vibe coding', waarbij AI-enthousiaste werknemers hun eigen tooling bouwen en implementeren op een PaaS. Dit creëert echter problemen op de lange termijn: onderhoud, datatoegang, auditing en compliance (zoals GDPR).

Wat als we een plek bieden om code te implementeren waar geen auth-tokens kunnen lekken? Waar datatoegang wordt beheerd door een intern platformteam dat ervoor zorgt dat alle compliance-regels worden nageleefd? Dit geeft ruimte voor eigen automatiseringen en custom views, maar dan wel veilig.

Supportplatforms

Bij complexe supporttickets moet men vaak door dashboards graven en logs doorzoeken. Het zou waardevol zijn om extensies te maken die data uit specifieke systemen direct in de supportinterface tonen. Hooks zouden agenten kunnen triggeren om een eerste onderzoek te doen voordat een mens ernaar kijkt. Ook het toevoegen van knoppen voor veelvoorkomende taken (zoals "reset quota X") zou het proces versnellen.

Observability-platforms

De meeste observability-tools convergeren naar dezelfde functies: log-zoekopdrachten, trace waterfalls en dashboards. Maar moderne apps zijn dynamischer geworden; acties van agenten kunnen uren of dagen duren. In plaats van statische weergaven, zouden we moeten kunnen experimenteren met eigen visualisaties en logica, zoals:

  • Arbitraire transformaties van data bij binnenkomst.
  • Alarms die eigen scripts triggeren (deterministische code of een agent).
  • Het uitvoeren van eigen code tijdens risicovolle momenten (deploys of feature flag rollouts).
  • Het omzetten van een specifiek ID in de logs naar een directe link naar dat resource op een ander platform.

Uitbreidbare software op het web is moeilijker dan het lijkt

Ik heb het tot nu toe eenvoudig doen klinken, maar dat is het niet. Neem Obsidian als voorbeeld. Het lijkt een simpele Markdown-editor, maar via plugins kun je het transformeren tot een Kanban-bord of een database. Deze kracht heeft echter een prijs: je moet elke plugin volledig vertrouwen. Voor een notitie-app is dit acceptabel, maar bij software die gevoelige data bevat (financiële transacties, privégegevens), stort dit model in.

Het uitvoeren van arbitraire code brengt grote beveiligingsrisico's met zich mee:

  • Fouten of oneindige loops in gebruikerscode mogen de service niet platleggen.
  • Gebruikers mogen geen API-keys naar derden kunnen doorsturen.
  • Gevoelige data mag niet geëxfiltreerd kunnen worden.
  • Het systeem mag niet misbruikt kunnen worden voor Denial of Service (DoS) aanvallen.
  • Bescherming tegen Spectre-aanvallen.
  • Voorkomen dat mensen gratis compute gebruiken voor crypto-mining.

Is dit al eens gedaan?

Ja, Salesforce doet dit al sinds 2007 op enorme schaal. Salesforce is in feite een massaal, multi-tenant programmeerbaar platform. In de beginjaren dwongen ze gebruikers om te schrijven in Apex, een custom Java-achtige taal.

Kijkend naar moderne serverless-concepten, zie je dat Salesforce veel van deze principes al toepaste:

  • Custom endpoints: De platform handelt routing, authenticatie en isolatie af.
  • Scheduled logic: Custom logica uitvoeren op een schema.

Salesforce bouwde hiervoor een eigen compiler, type-systeem en runtime omdat er destijds geen goedkope manier was om gesandboxed code voor gebruikers te draaien. In 2026 hebben we meer opties.

Een nieuwe primitief

Om dit te realiseren hebben we een primitief nodig met de volgende eigenschappen:

  1. Economisch: Het moet bijna niets kosten als het niet wordt uitgevoerd en fracties van een cent per executie kosten.
  2. Snelle cold starts: De opstarttijd moet in enkele milliseconden worden gemeten om de gebruikerservaring niet te hinderen.
  3. Controle over limieten: Strikte handhaving van CPU, geheugen, netwerkverzoeken en log-volume.
  4. Solide isolatie: Geen effect op andere gebruikers bij crashes of kwaadaardige code (inclusief bescherming tegen speculatieve executie).
  5. Veilige acties via 'Capabilities': In plaats van API-keys of complexe proxies, krijgt de onbetrouwbare code een specifieke referentie naar een functie (bijv. getApprovedEmail()). De code kan dan alleen acties ondernemen via de referenties die hem zijn meegegeven.

Welke technologie past hierbij?

Er zijn verschillende opties voor de isolatie-laag:

  • Interpreters: Zoals Lua of QuickJS. Effectief, maar beperkt in performance.
  • V8 Isolates: Google's V8-engine is extreem gehard. Cloudflare gebruikt isolates voor Workers. Dit is een zeer snelle en efficiënte manier van isolatie.
  • MicroVMs: Zoals Firecracker. Deze bieden een sterkere isolatiegrens en kunnen volledige binaries draaien, maar hebben meer overhead dan isolates.
  • WASM + WASI: WebAssembly start met een schone lei zonder ingebouwde HTTP-modules. WASI definieert een standaardinterface voor capabilities.

Cloudflare's Dynamic Workers

Cloudflare's Dynamic Workers zijn specifiek gebouwd met dit scenario in gedachten. Ze voldoen aan de bovengenoemde criteria en bieden extra's die bij andere oplossingen handmatig gebouwd moeten worden:

  • Observability: Ingebouwde OpenTelemetry-tracing.
  • Multi-tenant opslag: SQLite-databases via Durable Objects of R2 buckets.
  • Durable Execution: Dynamic Workflows voor acties die minuten of dagen duren.
  • Source Control: Versiebeheer direct in het product.
  • Hosted LLM's: Toegang tot LLM's via Workers AI voor gebruik binnen extensies.

Conclusie

Ik heb bijna tien jaar bij platforms gewerkt en ik kan zeggen: het transformeren van een app naar een platform is niet eenvoudig. Het vereist veel voorbereidend denkwerk en langdurige ondersteuning.

Maar het is het waard. Het is inspirerend om te zien hoe creatief gebruikers kunnen zijn wanneer je ze de tools geeft om de software naar hun eigen hand te zetten. Platforms zijn moeilijk, maar de beloning is groot.

***

Bijlage: Inspiratiebronnen

  • Kenton Varda's geschriften en presentaties.
  • Sandstorm.io
  • Cloudflare OS
  • Ink and Switch’s Malleable Software
  • Andy Matuschak’s Apps and programming: two accidental tyrannies

Voetnoten

  1. Ik vermoed dat zelfs in een wereld versneld door LLM's, een klein percentage van de gebruikers het grootste deel van de extensies zal schrijven.
  2. 'Vibe coding' platforms zijn in feite een generieke versie hiervan, maar ik verwacht dat ze meer gespecialiseerde enterprise-toegang zullen toevoegen.
  3. Dit negeert de noodzaak om UI aan de cliëntzijde te sandboxen; dat is een onderwerp voor een apart artikel.
  4. Voor wie bekend is met Workers: dit lijkt op 'bindings'. Bindings en Service Workers werken op een Object Capability RPC-systeem.
  5. Ik heb besloten om geen gratis LLM-gebruik aan het openbare internet aan te bieden, in mijn eigen financieel belang.