DEV Community

Cover image for Bubbles: a new kind of software, where one reply becomes a running stack
flisk
flisk

Posted on

Bubbles: a new kind of software, where one reply becomes a running stack

#devops #grok #ai #opensource

Reply to a post on X with @grok bubbles and a few words about an app. Grok answers with a link. Open the link and you get a running local stack: a web frontend, an API, a database, and a worker, each with its own service.json, a repo built in CI, and, when a runner is free, a live run for up to two hours.

We call this kind of software bubbles. It is not an AI agent, and it is not a code generator. This post explains what it is, how it works, what broke, and what is still rough.

What a "bubble" is

A bubble is a small, complete unit of software that is made from a short description and then checked by ordinary code. Three properties make it a category and not just a demo:

  1. The words pick the parts, nothing else. A fixed menu maps words to parts: postgres adds a database, worker adds a queue, solidity adds a chain node and an indexer. Words that are not on the menu are ignored. Nothing is generated by a model.
  2. Every output is checked before anyone sees it. The plan goes through a validator, then the real Flisk CLI builds the project, and flisk config verify runs in CI. A bubble that does not verify does not get a link.
  3. It is a link, not a session. The result is a web address made of a handle and the words. Share it, bookmark it, open it tomorrow. The same words give the same stack.

Grok is only the trigger. The stack is written by code.

Why not let the model write it?

We tried that first, and it failed the way you would expect. The model confidently invented commands and service types that do not exist. So we removed it from the critical path. Grok asks for a link; a Cloudflare Worker turns the words into a plan; a GitHub Actions run creates the project with the CLI and pushes a branch.

The trade-off is real. A bubble only knows what is on the menu, so an unusual architecture gets a plain default. That is the price of a stack that is the same every time.

How the pipeline works

  • Worker: reads the handle and words, builds the plan, checks it against rules, and stores the record. Opening a link that does not exist yet starts the build.
  • CI build: a GitHub Actions run scaffolds the project with flisk, creates one service.json per service, and pushes branch demo/<id> to a public repo.
  • Live run: a second workflow runs flisk up on a GitHub-hosted Ubuntu runner with Docker and Tilt. Two Cloudflare quick tunnels expose the app and a read-only Tilt UI. Live state is a small live.json on a live/<id> branch, so the Worker reads it from GitHub.
  • Records: every demo is one JSON file in the same public repo. No separate database.

What broke, honestly

  • The free storage limit paused saving for hours. Our first design stored records in Cloudflare KV, which has a daily write limit. Once it was hit, new demos could not be saved, and that stopped the whole pipeline. We moved live state to GitHub first, so running demos kept working. Then we moved the records too, so nothing needs KV now.
  • Runners were not the bottleneck. Every live run started. Each one then failed on the last step, because it tried to save its links to KV.
  • Next.js did not work on the first try. The generated dev server tried to write .next inside a bind-mounted folder that the container user could not write to. The fix is in review. Next.js support in demos waits for the next flisk release.
  • The Grok trigger is not reliable yet. Grok sometimes searches instead of answering with a link. We ask it to reply with an exact address, so it is easy to check, but that does not make it certain.

What is still rough

  • The menu is small. Bubbles cannot describe a custom architecture.
  • A live run is temporary and shared, so it can be busy.
  • The first load of a live run can take minutes.
  • Only one integration (Thor Commerce) is wired by hand. Everything else is a logged request.

Make it yours

Every demo is a plain git branch. The demo page has a "Make it yours" card with the commands to copy the branch into your own repository. Change anything, run it locally with flisk up, and send us what you improved. We will show good changes on the demo page.

Try it: https://demo.flisk.sh. Read how it works in full: https://demo.flisk.sh/how-it-works. The code is in the open: https://github.com/flisk-sh/flisk.

Bubbles are experimental. Tell us what breaks.

Top comments (1)

Collapse
 
flisk profile image
flisk •

How the pipeline works
Worker: reads the handle and words, builds the plan, checks it against rules, and stores the record. Opening a link that does not exist yet starts the build.
CI build: a GitHub Actions run scaffolds the project with flisk, creates one service.json per service, and pushes branch demo/ to a public repo.
Live run: a second workflow runs flisk up on a GitHub-hosted Ubuntu runner with Docker and Tilt. Two Cloudflare quick tunnels expose the app and a read-only Tilt UI. Live state is a small live.json on a live/ branch, so the Worker reads it from GitHub.
Records: every demo is one JSON file in the same public repo. No separate database.