Gadgets: Personal app vibe coding that is actually safe

What happens when an app works for almost everyone, but lacks the feature that makes it useful to you? AI could let you add that feature yourself. The harder question is where your modified app would run. Personal AI code generation challenges infrastructure built to give every user the same application. The word personal is the crucial part: generating another centrally hosted product does not solve the problem of modifying your own copy.

Kenton Varda starts with a familiar development cycle. A developer builds an app and distributes it to users. Some need additional features, so they submit requests. A product manager files those requests in Jira, where most disappear. Occasionally, a request matches something the product manager wants, and it reaches the roadmap.

As those features accumulate, each serves a small subset of users while adding conditionals to the shared codebase. The developer proposes a rewrite with a plug-in architecture: features can become extensions, and the core can stay clean. But new requests must now wait for the architecture. Implementing them first would supposedly waste work. Years pass, the rewrite remains unfinished, and users conclude that the product has been abandoned.

AI offers another distribution of the work. The developer supplies an initial app; each user's agent adds the features that person needs. Users do not inherit everyone else's special cases, and the original developer can preserve a small core. That possibility depends on users being able to run different code, not merely request different settings in one shared program.

Mobile platforms put an obstacle before execution even begins: installing software outside the approved distribution system. Varda delivers this as a polemic about Apple and Google's gatekeeping, exaggerating the remaining developer population down to five companies and comparing access to unsigned software with buying a gun in the United States. His imagined Google representative tells the user to return after a day of reflection. This is satire about control over one's device, not an installation procedure.

The web provides an escape: anyone can publish an application. Varda points to that openness as a counterexample to the claim that independent distribution must produce a security disaster. Yet web hosting introduces a different constraint. The developer runs one approved version on a server, and every user's requests go to it. Central updates are convenient precisely because users do not control their own running versions.

Many vibe-coding platforms make web apps because the web is an accessible target, but retain that centralized deployment model. They make producing an application easier without changing who controls its execution. Personal customization needs both: the ability to generate a change and an infrastructure boundary within which that change belongs to one user or group.

The presentation itself contains a small example of agent customization. Claude made the word “breaks” wiggle, alongside its red color and underline. Varda kept the animation because he found it absurd, joking that this unexpected design choice must be an original contribution from AI—and therefore evidence of superintelligence.

Kenton Varda then introduces his connection to the infrastructure problem: he started Cloudflare Workers in 2017 and identifies himself as its continuing lead engineer. Varda reports that Workers has millions of developers and serves trillions of requests per day. Those are his platform-scale figures; the talk supplies no counting definition or measurement interval. His experiment here is a side project built on Workers, and the presentation the audience has been watching is an app created inside it.

The Gadgets home screen begins with a familiar prompt box. Varda enters: “Make a silly counter app. Silly max it.” Generation returns an error, which he attributes to the internet connection. The recording does not show a successfully generated counter; he moves on to the existing applications.

The useful analogy is an Office suite. In Google Docs, you might have hundreds of documents that you open, edit, and share. Here, the items are gadgets, and each is an application containing its own code. Two items in the same workspace can therefore behave like entirely different applications, rather than different documents interpreted by one fixed editor.

Varda's examples make the range concrete:

• Collaborative whiteboard: an app he describes as generated from one prompt.
• Spanish-email filtering: a personal tool for handling messages in a language he does not know.
• Pull-request sorting: a gadget for organizing GitHub reviews he needs to complete.

These are small tools shaped around particular work, managed together like documents.

A useful gadget can become a blueprint: export its code without its data, then let someone else instantiate a new gadget from that code. The distinction is small but essential.

For example, the export boundary can be expressed in JavaScript by explicitly selecting code rather than serializing the entire gadget:

function exportBlueprint(gadget) {
  return { code: structuredClone(gadget.code) };
}

const deck = {
  code: { "app.js": "export const title = 'Slides';" },
  data: { slides: [{ title: "Private planning" }] }
};

const blueprint = exportBlueprint(deck);
console.assert(!Object.hasOwn(blueprint, "data"));

The function illustrates the code/data distinction; the private slide content stays out of the exported object.

The workspace includes blueprints for a document editor, a Kanban board, and a slide builder. Varda instantiates the slide builder, which his Cloudflare colleague Philip, a product manager, had built—Varda believes—in an afternoon. The result is an editable deck.

One slide-builder gadget contains one slide deck. Creating another deck means creating another gadget instance. That choice aligns the application boundary with the thing users want to share. A Google Docs-style dialog creates a share link, while the platform implements collaboration permissions and access control. The generated slide application does not have to decide which of many decks a visitor may access; that decision belongs outside its code, at the gadget boundary.

Varda switches to another instance of the slide app containing his original, discarded talk deck. He blames the deck's shortcomings on his own content, not Philip's software. Opening its conversation reveals how it was made: every app in the platform integrates with agents, and Varda had given Claude a Google Doc describing the slides he wanted. He also explicitly permitted it to add features to the slide app if the deck required them.

Claude read the application code and the document, then identified a missing capability: slide three needed strikethrough formatting. It added support rather than forcing the slide to fit the existing editor.

Other slides needed centered text, so Claude added that too. Slides five and six posed a more interesting problem: Varda wanted an arbitrary drawing of a cloud, while the editor supported boxes and arrows rather than free-form diagrams. Claude added an SVG insertion field and then generated the SVG to put into it. The new interface was not especially convenient for a human author, but it was exactly usable by the agent that had created it. The agent changed both the document and the tool needed to produce the document.

Allowing raw SVG raises an immediate security question: SVG can contain JavaScript. If the agent has introduced a cross-site scripting vulnerability, what can the injected code reach? Varda's answer depends on confinement around the whole application, not on trusting the generated editor to sanitize every input correctly.

The communication path crosses several boundaries:

1. Sandboxed client: the gadget UI runs in a null-origin iframe. Varda describes a Content Security Policy that prevents outside communication and access to cookies.
2. Parent-frame channel: the client can use postMessage to communicate with its parent. A Cap'n Web RPC session carries calls through that channel, onward through the server, and into the gadget's server code.
3. Sandboxed server: that code is a Durable Object on Cloudflare Workers, running in a dynamic worker sandbox that also prevents outside communication.

The generated client and server can communicate with each other and produce the user's interface, without receiving unrestricted access to the surrounding world.

Varda makes the sweeping claim that security bugs in this code do not matter because they cannot leak data out of the confined environment. The supported architectural lesson is narrower: a generated-code bug need not grant authority beyond the gadget's existing boundary. The platform's isolation, communication channels, and granted capabilities still have to hold. Network confinement is configuration-dependent: the current Dynamic Workers API documents globalOutbound: null as blocking fetch and connect; omitting it inherits the parent's networking. That current API detail explains the requirement without establishing the prototype's exact configuration.

Useful personal tools eventually need to reach outside their sandbox. Varda says the platform includes a system for safe access to external services, but leaves its mechanism for another talk. The recording therefore establishes that integration is part of the design without explaining its permission protocol.

Everything shown except the LLM is built on Workers. There are no containers: dynamic workers execute the application code, and Durable Objects provide persistence. Varda's description of having no database is best understood here as avoiding a separately operated database service, not as claiming that persistence involves no database technology. The environment is running locally on his laptop, which explains why existing gadgets remain usable after the online generation request fails.

Local execution uses workerd, the open-source Workers runtime, which can also be self-hosted. Self-hosting untrusted code requires care: the runtime's documentation warns that workerd alone is not a hardened sandbox and needs additional isolation against implementation bugs. Varda's motivation is concrete: the platform has Home Assistant and Spotify connectors, and he wants to run it in his basement for home automation.

The talk ends with a change to the original release plan. When Varda submitted the proposal, Gadgets was a side project he intended to put on GitHub immediately after presenting it, so attendees could download and experiment with it. Interest inside Cloudflare subsequently made it a more serious project.

Varda recounts CTO Dane asking him to delay the release for a few weeks and handle it more deliberately. He apologizes that the promised open sourcing is not happening that day, while saying it will happen soon. That is the Gadgets prototype's status at the end of this recording, distinct from the already open-source workerd runtime beneath it. The proposed unit of personal software is nevertheless visible: an app whose code can change with its task, whose data belongs to one shareable instance, and whose authority is enforced by the platform around it.