AIFactory takes a signed plan and builds it, each task inside its own throwaway Kubernetes Job. The last three weeks were less about new capability and more about a category of bug that is specific to autonomous systems: the builder reporting state that was true of its intention rather than of the world.

The last few weeks of AIFactory work were not about new features you click. They were about the build itself getting cheaper to run, faster to start, better at remembering what it already learned, and safer to let loose on a repo. Four changes, each small on its own, add up to a build node you can actually afford to run at scale.

Most autonomous coders are trusted on their word. They report a green test suite and you believe them, because there is no cheap way to check. AIFactory is built so that word costs nothing and the evidence costs everything: a passing test checkbox is impossible unless a real test runner actually executed. On 2026-07-19 we drove a plain GitHub issue through the whole pipeline, plan to verdict, with no humans in the loop, and this is the build side of that run.

The most dangerous way for an autonomous coder to fail is quietly. A wrong patch gets caught by tests. A patch that never gets written looks, from a distance, a lot like a build that is still thinking. This cycle we put a number on that distance and then closed it.

AIFactory builds software autonomously: it takes a plan, writes the code in an isolated git worktree, and opens a pull request. This round of work moved it onto the current models, added a third coding runtime, and connected it to the rest of the family.

When a build can only run on one node, you do not have a cluster — you have one machine with extra steps. This is the story of removing the last thing that pinned an AIFactory build to a single node, why it took three small changes instead of one, and exactly where the honest line sits between "shipped" and "proven."

This was a concurrency week. AIFactory started it as a single-instance app that ran one build at a time inside its own pod, and ended it with a control plane that can run many builds at once across replicas, plus the plumbing for moving the heavy work out of the web-server pod entirely and into per-task Kubernetes Jobs. The last part is not finished — and the honest version of that is the most useful thing in this post, so it gets its own section near the end.

A few weeks ago we taught the build executor to run independent subtasks in parallel, across multiple LLM providers at once. That work was about throughput, and it worked. But it left a blind spot: when a build finished, the cost and the timing came back as a single aggregate. Total tokens. Total dollars. Total wall-clock. Useful, but it couldn't answer the question you actually ask after a parallel run: which worker spent that money, on which provider, in which model, and where did the time go?

This session was about closing that gap. The headline is per-worker observability. The theme is that all of it is additive — the parallel build spine didn't change, we just put instruments on it. The same session also carried a GitHub Actions security pass and a god-file decomposition, because they were sitting in the same backlog and they unblock the work above.

This week I did something uncomfortable: I stopped shipping features and reviewed AIFactory honestly — against its own goals, and against the 2026 field of autonomous coding tools. Not the demo-day version. The version you'd give an investor who's going to check.

The short verdict: the pipeline works, end to end, and on the axis that actually matters in 2026 — governance and verification — it's ahead of the pack. But we had published zero numbers. We built the part of the problem that doesn't commoditize and then never measured it. This post is what we found and what we're doing about it.

The 3.4 line is about seeing and steering a build while it runs — and trimming the overhead when a job is small. Here's what landed.