Idea Sketch #3: Symbiont — A Playground Layer for Documentation

Documentation is usually static, but learning is not. 

When I’m learning a new language, library, or framework, I don’t want documentation to behave like a dictionary. I don’t just want to search for a term, read an API signature, or collect a few references. I want to build a working mental model. I want to see what the code does, change one thing, break it, fix it, and slowly understand what the abstraction actually means.

This is where the idea for Symbiont started.

The original question was simple: "could we turn any technical documentation website into a more interactive learning playground, without depending on the authors of that language or library to build a playground for us?"

A lot of documentation sites already serve agents pretty well. If a model needs to answer questions about a framework, it can retrieve docs, crawl pages, read package examples, and synthesize an answer. Some projects may even expose documentation in a format designed for AI tools (e.g., DeepWiki). That is useful, but I think it points to a slightly different future: maybe documentation is increasingly written for agents to consume, while humans need something else layered on top. Humans still need to learn.

Even if agents can write more code for us, developers still need enough understanding to guide, debug, judge, and shape what the agent is doing. We need to know the syntax differences, the important concepts, the “why did this error happen?” moments, and the feeling of writing something ourselves. The human layer is not just retrieval. It is practice and stimulations.

So Symbiont is not meant to be a generic “chat with docs” tool. The goal is more specific: Turn static technical documentation into an interactive local sandbox for learning by doing.

The name comes from the idea of something that lives inside a host and helps it. Symbiont does not replace the documentation page. It lives inside it, gently adding a runnable layer where the page is already useful.

From static examples to runnable moments

The first version focuses on one simple interaction: code blocks

When you open a documentation page, the Chrome extension detects code blocks and adds a small action to open a sandbox. The code is cloned into an in-page editor, so the original documentation remains untouched. From there, you can run the snippet, edit it, run it again, and see the output without leaving the page.

For v0, I started with Mojo and Bash examples.

• Mojo is a good test case because it is a new language to me, and when I'm reading docs specifically to understand syntax, signatures, and how it differs from Python or other systems languages.
• Bash is useful because many documentation pages contain shell commands, setup steps, and small examples that are easier to learn by trying.

Under the hood, Symbiont has a Chrome extension (with a registered service worker) on the frontend and a local Python backend. The extension handles code-block detection and the in-page sandbox UI. The backend runs snippets in Docker-isolated environments and returns the output. There is also an interactive terminal path, so snippets that ask for input can still work. Sessions are stored locally, so the system can remember what you were trying on a page.

The implementation is small, but the core loop works:

1. Read the docs.
2. Open a sandbox.
3. Run the code.
4. Change it.
5. See what happens.
6. Come back later.

Open questions

How different it is compared with a chatbot?

A Q&A interface is useful, and Symbiont may eventually include one. But I don't think it should be the center of the experience.

A chatbot still keeps the user in a question-answer mode. It helps you retrieve information, but it does not always help you internalize it. For learning technical material, the important moment is often not “what does this mean?” but “what happens if I change this?” Plus you don't need to set up the environment yourself.

This reminds me of UIUC’s CS 124 playground, where students can learn new programming languages like Java and Kotlin directly in the browser, without having to set up the environment on their own computers. What stands out even more is its duplex/commentary mode: for certain code blocks, you can listen to the instructor explain the code while the code block updates itself. It feels almost like watching a piano play by itself. The course also has a public-facing LearnCS playground, so non-students can experience the entire flow too.

Local vs. cloud runner

For v0, running everything locally makes sense. It keeps the architecture simple, avoids infrastructure costs, and lets me experiment without worrying about multi-tenant security. The extension talks to a local backend, Docker provides isolation, and everything stays on the user's machine.

But if Symbiont were ever meant to be a real product, I suspect a cloud-hosted execution layer would be necessary. Asking users to install Docker, run a backend service, and manage local environments is hard to call that frictionless. The ideal experience is probably:

• Install the extension (plus run a one-time configuration)
• Open documentation
• Click Run

That's all. But moving execution to the cloud introduces a completely different set of problems: infrastructure costs, latency, authentication, abuse prevention, and the challenge of safely running arbitrary code for many users at once.

Local execution is easier to build; cloud execution is easier to use.

Is the problem important enough to solve in the first place?

For some ecosystems, setting up a local environment is already straightforward. If I can install a package, open a REPL, or run a quick example in a few minutes, maybe the documentation does not need another playground layer. Many frameworks already provide examples, starter templates, or dedicated sandboxes.

In that sense, Symbiont is not trying to invent a new sandbox. Tools like StackBlitz, CodeSandbox, Replit, CoderPad, and others already do that very well.

What feels different is the placement.

Those tools ask you to leave the documentation and enter a separate environment. Symbiont asks whether the playground can simply appear where the learning is already happening. Instead of copying an example into another tab, opening a project, and configuring an environment, the example becomes runnable in place. Maybe that is valuable. Maybe it is not.

One way to think about Symbiont is as a plug-and-play playground layer that can attach itself to documentation pages that do not already have one. In fact, it would not surprise me if existing sandbox platforms eventually implemented something similar themselves. The underlying idea is fairly simple: examples should be executable at the moment you encounter them. Whether that convenience is enough to justify the extra complexity remains an open question.

The interaction model is the part I care about most: the documentation page becomes a place where code can be tried, modified, and learned from directly.

Future directions

• Inline editing. Instead of opening a separate floating sandbox window, the code block itself could become editable. The user would read the docs, tweak the code directly where it appears, click Run, and see output rendered below the block. That feels more connected to the page: no context switch, no separate editor, just the documentation becoming alive.

• Another direction is error-aware help. When a snippet fails, the system already has useful context: the code, the error, the page URL, the nearest heading, and maybe the surrounding documentation. That is the perfect moment for AI to help. Not by giving a generic answer, but by explaining this specific failure in this specific learning context.
• Later, Symbiont could support broader Q&A across documentation. If the user is reading one page but asks something that belongs elsewhere, the system could fetch nearby docs, related sections, or official examples. But I still think that should support the playground, not replace it. The main experience should stay grounded in trying code.

Not every language, library, or framework team has time to build a custom learning environment. But maybe the browser can provide one on demand. Maybe any documentation page can grow a small playground layer. Maybe examples should not only be copied into our editor later; maybe they can become runnable at the moment we encounter them.

That is what I want Symbiont to explore:

A small helper living inside documentation, turning reading into practice.