Conjure

Overview

Conjure explores how people—primarily K–8 learners—can create software with LLMs without first needing to understand programming, development environments, or other computer science concepts.

The system removes much of the technical infrastructure normally required to build and publish a web application while still giving users control over what gets created. Learning Science principles were incorporated into the agent's persona so that users could ask about unfamiliar terminology or computational concepts when they wanted to learn more, without requiring that knowledge before they could begin creating.

Design Rationale

While tools such as Claude and ChatGPT make it increasingly possible to vibe code, turning generated code into a working application can still require substantial technical knowledge. Users may need to understand file structures, development environments, dependencies, hosting, deployment, and how to run and troubleshoot their code.

With Conjure, we wanted to remove as much of that infrastructure as possible from the user's experience. The code is hidden entirely. Instead, users describe what they want to create or change, wait for those changes to be applied, and immediately see the updated application alongside their conversation with the agent.

Hiding the code, however, raises another question: how do users retain meaningful control over what the agent creates?

After each change, users make an explicit curation decision. They can accept the change, continue iterating on it, revert to an earlier version, or reject it entirely. These decisions determine which changes ultimately become part of their application.

The agent was also explicitly instructed not to make ambiguous design decisions on the user's behalf. When a request did not provide enough information, the agent was encouraged to ask follow-up questions rather than silently choosing an interpretation. Our goal was to preserve the user's autonomy over the design of their application while reducing the technical knowledge required to implement those decisions.

Architecture

Conjure consists of three primary components: the web application, a local agent running on the user's computer, and the infrastructure used to store and deploy projects.

The main application was built in React and handles account management, project creation, project selection, and interaction with the LLM.

When a user creates a project, a GitHub App automatically creates a repository inside a predefined organization. Each repository begins from a template application containing several architectural constraints and conventions. These constraints help keep generated projects relatively lightweight and reduce the likelihood that the agent introduces unnecessary infrastructure, such as expensive server-side services.

From the user's perspective, interaction resembles a conventional LLM chat interface. They describe what they want their application to do, and the agent modifies the project accordingly.

The agent's prompt includes several behavioral constraints. It avoids returning source code directly in the conversation, encourages users to describe the outcome they want, and can explain programming terminology or concepts when users ask for additional information. Projects also contain a conventions file describing aspects of the codebase—such as where new pages should be created—so that future changes follow a consistent structure.

When the user submits an actionable request, Conjure calls the Claude Sonnet API with the relevant project files as context. The agent generates the necessary code changes and performs basic checks for detectable errors.

Those changes are then sent from the web application to a local service running on the user's computer. The local service applies the changes to the project and updates the running development environment, allowing the user to immediately see the result in the preview beside their conversation.

Importantly, the version-control operations underlying this workflow remain invisible to the user.

If the user accepts a change, it is committed to the project's main branch. If they choose to iterate, Conjure preserves that version while allowing another variation to be explored. If they revert, the project returns to an earlier accepted state. If they reject a change, the experimental version is discarded and the project returns to the current accepted version.

The user interacts with these operations through simple decision buttons in the chat interface rather than through Git, branches, commits, or other development tools.

Capturing Visual Debugging

We also experimented with capturing how users visually investigated problems in the applications they created.

Whenever a user selected one of the decision options—such as accept, iterate, revert, or reject—the system attempted to capture a screenshot of what they were currently viewing. We were interested in whether these screenshots could help us reconstruct what users were attending to when they made a decision or understand how they communicated visual problems when they did not know the technical terminology needed to describe them.

Rather than requiring participants to manually capture and upload screenshots, we used a headless Chromium browser to automatically capture the page at the URL and vertical position they were viewing.

This approach exposed an important limitation. Many participants created single-page applications where substantial state changes occurred without changes to the URL. Some also implemented user accounts and authenticated experiences. Because our screenshot infrastructure did not reproduce this client-side and authentication state, the resulting screenshot could differ from what the participant was actually seeing.

Although this prevented the capture mechanism from working as reliably as we intended, it highlighted an interesting challenge for studying debugging in interactive, stateful applications: reproducing what a user saw can require substantially more information than simply preserving the URL.

Once users were satisfied with their applications, they could publish them directly through Conjure using Firebase Hosting.

Deployment required only pressing a Deploy button. The hosting and deployment process occurred behind the scenes, allowing users to make their applications publicly accessible without needing to understand build pipelines, hosting platforms, domains, or other web deployment concepts.

Participants could then share their applications with friends, family members, and peers, including other participants who could provide feedback on what they had created.

Deployment

Conjure was deployed during a week-long summer program in Summer 2026. The deployment involved two groups of young learners: students enrolled in a maker-based summer program hosted by the space, and students participating through a community-impact organization serving children with comparatively limited prior exposure to computing technologies.