I’ve built a machine, that builds machines, that build large pieces of software. One of them ran for 39 days building a preliminary proof-of-concept copy of Word, most features largely there, mostly on its own. It got a lot of things right—though the ruler and margin controls you’d expect at the top of the page were conspicuously absent. More on that later.
This isn’t “AI helped me code” autocomplete. It’s a bespoke agentic loop I call a “dev machine.” It wakes up, reads a state file, picks the next thing to build, builds it, tests it, commits it, and goes back to sleep. Over those 39 days, my dev machine ran 565 sessions, made 3,706 commits, and produced about 350,000 lines of TypeScript. And the most interesting thing I learned had nothing to do with whether the code worked (it did). The interesting part is what broke—and why.
Let’s talk about how I got this to work: four failures (which is why the project is called “word4”).
Four tries to get one loop #
The first attempt, which I charmingly named “wordbs” because I thought it was a nonsense idea at the time, was 150,000 lines of trying to build everything at once: an OT engine, canvas rendering, OOXML parsing, mail merge. It drowned in its own complexity before anything usable existed. The second attempt that counts, word3 (there was something in between that actually worked, but aimed at a different target, hence the jump), was the opposite: clean, about 8,000 lines, 486 passing tests, genuinely nice architecture. But it was just a single-user app because I hadn’t “coached” the model and it quietly decided to skip that part. Trying to bolt CRDT-based collaboration onto it afterward broke the working editor.
Word4 v1 had the right instinct (CRDT first, validation gates, specs up front), and then nobody executed it. There was no orchestrator, no loop: just a folder full of good intentions.
What actually changed things came from a different project. I was building a terminal UI with a technique that was a proto-dev-machine, and I told it, “If you run out of things to do, just keep adding features that make sense.” Then I went away for the weekend. I’d set this one up, almost by accident, so that a) it was more careful with both design and the task list, b) it had a robust test environment, and c) the main thread acted only as an orchestrator. Those ingredients let it run for 38 hours on its own, spawning 440 sub-agents across 167 commits (RIP my token budget).
I set out to formalize those ingredients in a system I call “the dev foundry.” This is the machine-that-builds-machines.
There are three core things a dev machine loop needs (aside from a good enough model). First, it requires the ability to build specs “progressively,” in machine-readable form, so it never really gets lost building something and can design as it goes. Second, it needs a robust event/task stack that keeps context clean. The main loop did nothing but orchestration on that stack, spinning up a fresh sub-agent with fresh context for each new task, and keeping tasks at a scale a single sub-agent could actually finish. Finally, it needs a good test environment, robust, with a target it can understand and write tests against as it designs features. These combine into a “machine” that never gets lost. It just grinds away. The more formal dev machines add one last thing: maintenance tasks in the list, so the machine remembers to do refactoring, run CI/CD pushes, and even take bugs from me on the live site and push fixes (then deploy them) automatically, as long as the loop is running.
A “dev machine” is a bespoke loop for one specific project. A “dev foundry” is the agent and process that builds dev machines. The foundry creates machines. I like this technique—it’s a good way to build leverage. One way to think about it is that, for a given model, there’s a “radius” of problems it can solve independently. The dev foundry sets it up to break the larger problem into problems of that size (and if you’re lucky, the problem of decomposition is itself a problem of that size, and the model can do almost all of the work). Machines build software. The foundry is skeptical, on purpose: It runs a six-step admissions gate that checks whether the problem you have will actually fit the dev-machine pattern, including repeating back the downstream implications of your stated goals and making you agree with them before it will build anything.
The dev machine loop #
Here is the entire loop:
That’s it. The spec is the product. The machine is just a loop that executes specs. Every session starts with a clean context and gets its instructions entirely from files on disk, because the alternative (one long session holding everything in its head) doesn’t work. The word4 architecture spec was 947 lines written in about an hour of conversation, and it paid compound interest: 621 commits in the first week, 1,351 by week six. That initial hour was the highest-leverage hour in the whole project.
(There’s a guardrail I’ve grown to love. Every generated project ships an AGENTS.md that tells any human who opens an AI session in the repo: Do NOT implement directly, run the recipe. Because a well-meaning human editing files by hand bypasses the state machine and causes exactly the drift you built the machine to avoid. The machine has to protect itself from us.)
The part where it went wrong #
Now the good part: After 534 sessions, the machine proudly reported 1,111 features completed. And when I actually looked, a lot of those “features” were the machine mapping obscure OOXML properties one at a time (each one counting as a feature), plus writing tests for code that already worked. Meanwhile, a basic ruler—the margin control at the top of every word processor you’ve ever used—had been sitting in the candidate list for 22 straight sessions and had never once been picked. Zero lines of ruler code existed after 25 days.
Why? Because the OOXML property work was deterministic. It was always available, it always passed review, and it always incremented the counter. The ruler was ambiguous and hard and might fail. So the machine, handed a choice between “reliably produce a green checkmark” and “do the valuable but risky thing” chose the checkmark every single time. The test-to-source ratio drifted to 4:1 against a 2:1 target. Staging deploys sat “overdue” for a hundred sessions and never escalated.
This is priority inversion, and it is not a bug in the model. The machine did exactly what I asked: It faithfully wrote down every problem in its state file, including the ones it was busy creating. It just had no judgment about which work was worth doing. It optimized the metric it could see. That’s the real finding, and it’s why “unsupervised” is the wrong word for any of this: The machine is honest, but it isn’t strategic. Strategy is still my job, and if I don’t show up to do it, I get 1,111 features and no ruler.
Scar tissue #
A few things I’d tell you if you tried this yourself. Robustness is not incremental. You can’t arrive at it gradually. Every new machine I’ve generated fails its first overnight run, always in the gap between the template and the specific reality of the project. Word4’s first night died in a 514-attempt retry loop, because Cloudflare’s bot detection started challenging the Anthropic API during a long unattended run (I fixed it partly by putting the container on network_mode: host
, so the bridge NAT stopped looking like a bot). I now run a three-layer recovery stack: an entrypoint retry loop, a host watchdog, and a host monitor, each catching failures the others miss. That is not elegance. That is scar tissue.
And once you have more than one machine, they start to entangle. I’ve generated machines for word4 and a few other projects now, and the shared operational patterns kept getting tangled up with the per-project customization, so I borrowed the Docker base-image model: a foundry-owned base layer, a machine-owned project layer, and one script to push improvements across the whole fleet at once.
If you want to build your own dev machine
The good news is you don’t have to start from my scar tissue. All of this is open source and built on Amplifier, the agent framework underneath everything I’ve described. Amplifier is the substrate—the modules, agents, recipes, and orchestration primitives: github.com/microsoft/amplifier. The foundry itself—the admissions gate, the STATE.yaml loop, the AGENTS.md guardrail, the progressive specs, the recovery stack—ships as an Amplifier bundle: github.com/ramparte/amplifier-bundle-dev-machine. Clone that and you have the loop this whole piece is about.
Two things I’d tell you before you run one overnight. The highest-leverage hour is still the spec, not the code—spend it on the architecture doc and a test target the machine can check itself against, because that’s what the loop compounds on. And budget for the machine having no judgment: It will honestly, tirelessly hand you 1,111 features and no ruler unless you show up to say which one matters. The tooling gives you the loop. The strategy is still yours—and I think it’s going to stay that way for a while.