Preconfiguration: Writes Coding Agent Setup Files From One Spec and Tests Them on a Clean Machine
Cloud coding agents start each task on a fresh machine. Before the agent can run a single test, something has to install the right runtime, start a database, configure environment variables, and download dependencies. Every platform that runs agents wants those instructions in its own file: Copilot expects a setup workflow, Cursor builds a Dockerfile, other platforms want shell scripts or configuration in other formats. A team that uses two or three agents writes the same setup two or three times, and mistakes usually show up later as an agent session that stalls because a database port wasn’t open or a runtime was the wrong version.
Preconfiguration treats those files as build output. You describe the machine once in a short preconfig.yaml: the languages and runtimes you need, the services that have to run, any downloads or build steps. Then preconfig build writes the setup file for each platform you target. The output is correct by construction, not because you were careful when editing, but because you only edited one source.
preconfig check reads your existing setup files against each platform’s rules and catches quiet mistakes: a Copilot job with the wrong field name, a Dockerfile that won’t build on the Python image you specified, a shell script missing a dependency. These are the mistakes that don’t show up until an agent runs the setup and fails halfway through.
Then preconfig verify does what a reviewer cannot do alone. It runs the setup you wrote on an empty Ubuntu container, lets it build and download and configure, and then runs your project’s tests. A setup file can look perfect and still fail; a machine that started completely empty, ran your setup, and passed your tests is proof that it works. When a setup breaks, Preconfig Doctor reads the log, which can run past a thousand lines, and names the cause. If the fix belongs in the spec, it writes it there. Doctor works from rules with no model involved, so the same log always gets the same answer.
Both tools are Alphas, tested on one Linux machine. Runs on the actual agent platforms come with the Beta. The live demo mixes recorded runs with the real code running in your browser, and Doctor has a demo of its own where you can see it read a real failing setup log and draft the fix.
For engineers who keep multiple projects alive, or whose team uses more than one cloud coding platform, having one place to keep your setup correct is a gift. You change a library version or add a service, edit the spec once, rebuild, verify, and you’re done.
The value proposition for app developers is that setup stops being a per-platform chore. You define the machine once, generators handle the rest, and before anything goes live you’ve already proven the setup works on a real clean machine running the actual tests. When something does break in production, at least you know the baseline works.
Preconfiguration is designed for teams that run multiple projects across multiple agent platforms, where the integration cost of managing separate setup files is high enough to justify a single source of truth. It’s also useful for any team whose setup is complex enough that mistakes are likely: database init scripts, service dependencies, environment variables, build-step ordering, all the things that can go wrong silently.