Live Demo

A small Python service needs PostgreSQL, Redis and its tests before an AI coding agent can do anything useful with it. Six steps show what Preconfiguration does about it, from a draft spec to a proven machine. Every line in the terminal below is what the Alpha printed on the sample repositories, and the two verify runs were recorded on a clean Ubuntu 24.04 container. Under the replay, the Alpha’s own engine runs in your browser. There is nothing to sign up for or install, and nothing you do here leaves this page.

Sample repositories, real Alpha engine. orders-api and its hand-written setup files were written for the demo, and no coding agent runs in it. preconfig and everything it printed are real.

How to Run It

  1. Press Play. The six steps play in about a minute, each ending with a short conclusion. Pause at any time, or pick a step.
  2. Watch the panel. Next to the terminal, each step shows what the command did: the files detect read, the platforms build wrote for, the findings check made, the steps verify timed.
  3. Build it again here. In step 2, the engine in your browser builds the same spec and compares its seven files with the command line’s.
  4. Try your own. Below the replay, edit a spec and see every platform’s file, or check a setup file of your own.

On a wide screen the demo shows the terminal and the panel side by side: open it full screen.

The Controls

Control What it does
Play, Pause, Resume Plays the six steps in order, pauses and carries on. The whole replay takes about a minute
Back, Next Moves to the previous or next step and plays it
Restart Goes back to step 1 and plays from there
Step 1 to Step 6 Jumps to that step and plays it
Build it again in this page In step 2: builds the spec with the engine in your browser and compares the files

The Six Steps

  1. Draft the spec from the repository. preconfig detect reads orders-api’s .python-version, pyproject.toml, requirements.txt, compose.yaml and .env.example, and drafts preconfig.yaml. Comments in the draft say which file each part came from, and it builds the same files as the spec the team wrote by hand.
  2. Build every platform’s files from one spec. preconfig build writes seven files for five platforms: the dev container and its services, GitHub Copilot’s setup workflow, Cursor’s environment and Dockerfile, cloud-init and the setup script. A second check finds nothing to fix.
  3. Check setup files written by hand. The same service with a Copilot workflow, a Cursor environment and a dev container written separately. preconfig check finds 15 errors and 2 warnings: a misnamed job that would stop Copilot with an error, a timeout over its limit, a key Cursor’s schema doesn’t allow, a dev container without the databases, and four files the targets need that are missing.
  4. Verify it on a clean machine. preconfig verify runs the setup script and the tests on a fresh Ubuntu 24.04 container. READY in 49.6 seconds, with Python 3.12.3, PostgreSQL 16.15 and Redis 7.0.15, and 4 tests passed.
  5. Catch a missing service before an agent does. The same repository with Redis left out of the spec. preconfig warns at once, and verify shows the cost: the setup works, 3 tests fail on a refused Redis connection, and verify exits with 1 at the ready step.
  6. Change one line, and every platform follows. The team moves to PostgreSQL 17. check lists every file now out of date, build rewrites five of them, and check is clean again.

Reading the Panel

  • The repository, in step 1, marks each file detect read and what it took from it. The code and the tests are left alone.
  • The platforms, in step 2, light up as build writes their files. The tabs under them show each file.
  • The findings, in step 3, come file by file, with what each mistake would do on its platform. The counters always add up to what check printed.
  • The timeline, in steps 4 and 5, has a bar for each step of the setup, at its recorded time. Under it runs what the machine printed.
  • The change, in step 6, shows the one line in the spec and each file build rewrote or left alone, with the differences check printed.

The Two Panels

  • Build your own spec. Edit preconfig.yaml, or start from one of the samples: orders-api, a Node.js shop with pnpm and PostgreSQL 17, a Go worker with Redis 8, a project with Node.js and Python together, and a spec full of mistakes. The engine checks it as you type, with the same messages as the command line, and shows every file it writes.
  • Check a setup file. Paste a Copilot workflow, a Cursor environment, a devcontainer.json or a cloud-init file and check it against its platform’s format, or a setup script, which is compared with the spec. With the box ticked, it is also compared with the spec in the first panel, and the difference is shown.

Things to Try

  1. Let it play once. Then compare step 3 with step 2: the same service, 15 errors against none.
  2. Break the spec. In the first panel, pick “A spec with mistakes”: a name with a space, Node.js 21, a typo in a tool, a token in env, a service the Alpha can’t run yet, and setpu: for setup:. Each gets its own message and hint.
  3. Upgrade something. Pick orders-api, change PostgreSQL to 17 or Python to 3.13, and watch the files change.
  4. Check the demo’s own mistakes. In the second panel, pick “Copilot: a job named setup”, then “A workflow preconfig wrote”.
  5. Catch drift. Pick “A workflow preconfig wrote”, tick the box, then change the spec in the first panel and check again.

If It Does Not Start

The demo is made for current browsers on computers and phones, with JavaScript switched on; so far it has been tested in Chromium, at desktop and phone widths. The replay needs nothing else. The two panels need WebAssembly: the engine comes with the page, about 1.4 MB as text (about 500 KB compressed), and runs inside it. If a panel says the engine didn’t start, try another browser, or allow scripts on this page if an extension blocks them.

What Is Real Here

Real:

  • Every line in the terminal in steps 1, 2, 3 and 6: what the Alpha’s command line printed on the sample repositories on September 29, 2026, replayed at a readable pace.
  • Steps 4 and 5: two runs of preconfig verify on a clean Ubuntu 24.04 container on September 29, 2026, from verify’s own JSON events and the machine’s own output, replayed five times faster. The minutes and seconds shown are the recorded ones.
  • The files, findings and messages in the two panels, and the build in step 2: the Alpha’s Go code, compiled to WebAssembly with TinyGo. A test runs the browser build and the standard Go build on the same 39 inputs and gets the same answers, and the files match the command line’s byte for byte.

Stand-ins:

  • orders-api and the hand-written files of step 3. They were written for the demo, to show a common kind of project and common mistakes.
  • The platforms. No Copilot, Cursor or Codespaces session ran here. Each file was checked against its platform’s schema and tools, and the setup script ran on a clean machine.
  • The network of the test machine, which reaches the internet through a proxy that inspects TLS. verify ran with --network host and the proxy’s certificate, shown in the demo as proxy-ca.crt.

The Demo Kit

The same engine runs offline in a few seconds with the demo kit: ./run-demo.sh drafts, builds and checks the sample repository, ./run-demo.sh --verify proves it on a clean container where Docker is installed, and run-demo.cmd does the same on Windows. The kit holds preconfig binaries for Linux, macOS and Windows, the sample repositories and the browser demo, without source code. So far it has run on Linux x86-64 only: the other binaries compile but haven’t been run, and neither has run-demo.cmd. The kit is available on request.

Next, in the Beta, the generated files run on the agent platforms themselves, with real repositories. The roadmap has the plan.