Introduction

Ready machines for coding agents: describe what a project needs once, and each agent platform gets a setup file it can read, checked against its rules, with the setup run on a clean machine before any agent starts.

Preconfiguration.com is a project to build that. Its engine, preconfig, is one small program. It reads a short spec, preconfig.yaml, writes the setup file each platform reads, checks the setup files a repository already has, and runs the whole setup on a clean machine to prove it works. When a setup fails anyway, it reads the log, names the cause and, when the cause is in the spec, writes the fix there.

The engine works today. It is one binary of 3.6 MB built on Go’s standard library alone, it writes files for five platforms, and on a clean Ubuntu 24.04 machine it took a sample service from nothing to passing tests, with PostgreSQL and Redis running, in about a minute. A live demo replays it in your browser, and a second one shows Doctor reading failed setups. The next step is the agent platforms themselves, with real repositories.

Why Agents Need Ready Machines

AI coding agents now take a task and work on their own, most of them on a fresh machine in the cloud. Before they can build or test anything, that machine needs the right runtime, the packages, and the services the tests talk to. When it doesn’t have them, the agent guesses: it installs by trial and error, skips the tests it can’t run, or hands back code nobody tested. GitHub warns that this is slow and unreliable, and Cursor calls environment setup the most important step for good work from its cloud agents.

Every platform wants the setup in its own file: a workflow for Copilot, an environment file and a Dockerfile for Cursor, a devcontainer.json for Codespaces, a script for the rest. Most teams use more than one agent, so the same setup gets written several times by hand, drifts apart, and breaks where nobody is watching: in the middle of an agent session. One spec: the runtimes, services, setup and ready check, written once. Every platform’s file: written by the compiler, in each platform’s format. A check: of the files a repository already has, against each format and against the spec. A proof: the setup and the tests, run on a clean machine. A doctor: when a setup fails, its log read, the cause named and, when the cause is in the spec, the fix written there. How it works

What the Alpha Has Shown So Far

On a clean Ubuntu 24.04 container, the generated setup for a sample Python service installed Python 3.12, PostgreSQL 16 and Redis 7, started them and passed the service’s tests in 49.6 to 73.0 seconds over three runs. With Redis left out of the spec, verify stopped at the ready step with the test runner’s own error, three times out of three. On hand-written setup files for the same service, check found 15 errors and 2 warnings, from a misnamed job that would stop Copilot with an error to a dev container with no databases. The tests caught 32 of 32 bugs planted in the engine on purpose.

Preconfig Doctor, the second engine, was tuned on 28 recorded cases, then tested on 11 more recorded after its rules were frozen. It was right on 8, said “unknown” on 2 and was scored wrong on 1, for naming the network without the host. In all 74 answers, tuning and holdout together, it never wrote a wrong change. Every change it wrote, run again on a clean machine, got past its failure. Preconfig Doctor

All of this ran on one Linux machine with sample repositories. No coding agent platform has run the generated files yet: they pass each platform’s schema and tools, and the setup script ran on a clean machine. Some install paths, Node.js and Go among them, couldn’t run on that machine’s network. That is what the Beta is for. The Alpha in detail

Where the Project Stands

The Alpha is done: detect, build, check and verify for five targets, and doctor for failed setups, with tests, measurements and two demos. The Beta comes next and takes about 12 weeks: every target run on its own platform with real repositories, Java, Ruby, Rust and MySQL, checks on every pull request, Doctor on the platforms’ own failures, and four weeks of teams’ agents working on generated setups. Toward v1.0, the project publishes the spec format, stabilizes the command line and runs pilots. v1.0 freezes the spec and the commands, so a spec written for it keeps building. See the roadmap

Try It in Your Browser

The live demo plays six steps on a small Python service: a spec drafted from the repository, the files for five platforms, a check of hand-written setup files, a clean machine proven READY, a missing service caught, and an upgrade made in one line. Under the replay, the Alpha’s own engine runs in your browser, so you can edit a spec and see every platform’s file, or check a setup file of your own. It is open to everyone, with no sign-up and nothing to install. Open the live demo

The Doctor demo does the same for a setup that failed: pick one of nine recorded failures or paste a log of your own, and Doctor names the cause and, where the fix belongs in the spec, writes it, all in your browser.