Cloud coding agents run on fresh machines, and before a test can run, the runtime has to be installed, the database has to start, environment variables have to be configured. Every platform that runs agents expects these instructions in its own file. Copilot wants a workflow. Cursor expects a Dockerfile. Other platforms want shell scripts. The result is setup duplication—the same environment, described three different ways, and they drift because humans edit them separately.
Preconfiguration treats setup as a build artifact. You describe the machine once in a short preconfig.yaml: the languages, runtimes, services, downloads, build steps. Then preconfig build generates the correct setup file for each platform. The output is correct by construction because you only edited one source.
The technical innovation is reproducibility verification. preconfig verify runs the setup you wrote on a clean Ubuntu container, lets it build and download and configure, and then runs your project’s tests. That’s not a theory of reproducibility—that’s proof. A machine that started empty and passed your tests proves the setup works.
preconfig check reads your existing setup files against each platform’s schema rules and flags mistakes: a Copilot workflow with the wrong field name, a Dockerfile using an incompatible base image, a shell script that assumes a tool is pre-installed. These are the mistakes that don’t show up until the setup runs and fails halfway through.
When a setup does break, Preconfig Doctor reads the log and names the cause. Doctor works from rules with no model behind it, so the same log always gets the same answer. If the fix belongs in the spec, it writes it there. The spec gets fixed once, and all platforms get the fix automatically on the next build.
Both tools are Alphas, tested on one Linux machine. Runs on actual agent platforms come with the Beta. The live demo mixes recorded runs with real code running in your browser, and Doctor has a demo of its own where you can see it read a failing setup log and draft the fix.
The technical appeal is configuration consistency. In infrastructure, drift is the enemy—setup drifts, versions diverge, one platform works while another doesn’t, and nobody knows why. Preconfiguration eliminates drift by making setup a build output, not hand-edited files. The innovation is treating configuration as a derivation problem instead of a replication problem.