August 10, 2026
Phase 3 tackles the riskiest unsolved problem in autonomous software delivery: an instruction that looks complete but secretly leaves a decision unstated. We built a mechanical ambiguity detector that reads every spec three times through three different personalities and flags exactly the points where those readings disagree, before a single dollar is spent building. The detector correctly stops vague instructions and correctly passes clear ones without false alarms. With the two research-risk blockers retired, Phase 3 is complete.
Continue Reading: Phase 3: Can our software factory catch vague instructions before building?
August 5, 2026
A real enterprise build runs for hours, sometimes overnight. Until now, a crash eight hours in would lose all in-progress work and force us to re-pay for the parts already finished. Phase 2 gave the factory durable memory using the simplest possible foundation, and we proved it the honest way: we killed a real multi-part build with kill -9 partway through and watched it correctly resume without re-doing any completed work. The factory can now be trusted to run long, unattended jobs.
Continue Reading: Phase 2: Can our software factory survive a crash during overnight runs?
August 3, 2026
We set out to answer a make-or-break question: can our automated software factory safely modify software that already exists? We tested it on a real open-source program with three genuine improvement tasks of escalating difficulty, and it completed all three correctly on the first try for about 55 cents total, without breaking anything. Along the way we caught one of our own safety nets silently switched off, fixed it, and only then trusted the results. The verdict: proceed.
Continue Reading: Phase 1: Can our automated software factory safely change real software?
August 1, 2026
Phase 1 retires the roadmap's single largest risk: can the factory reliably and safely modify an existing codebase inside its gate system at all? This technical report records the exit criterion and its verdict: three change requests of increasing blast radius on a real 12k-LOC external repository, each merged first-try with gates green at trivial cost ($0.55 total), with the characterization rail demonstrably catching an injected regression. The architecture does not need to pivot.
Continue Reading: Phase 1 Go/No-Go: The Brownfield Capability Spike
July 16, 2026
An autonomous software factory runs on trust, but trust needs a ceiling. The risk_tier_gate is where that ceiling gets enforced, and risk-band routing is the mechanism that makes the ceiling dynamic. It sorts every change into a risk band, low, medium, or high, and routes accordingly. High-band changes go to a human every time, regardless of what the autonomy tier says. This is not a recommendation. It is a circuit breaker.
Continue Reading: What Is Risk-Band Routing in a Software Factory?
July 16, 2026
A software factory's gate engine is where governance lives. Today, that governance is written in Python. It works, it is tested, and it is correct. But Python is not the right language for policy, not in the long term. The right language is a declarative policy language like Rego (Open Policy Agent) or Cedar (AWS). This is about why the migration matters and what it unlocks.
Continue Reading: Why OPA/Cedar Policies Matter in Software Factories
July 16, 2026
The factory improves itself. It harvests escaped defects as regression cases, trains new critics, and promotes better components through shadow, canary, and live. But there is a problem that breaks all of this if left unsolved: environmental drift. If the repo changed between when you scored the incumbent and when you score the candidate, how do you know the score difference came from the component and not from the environment? Hermetic replay is the answer. It freezes the entire evaluation context at task time and re-runs against that exact snapshot.
Continue Reading: What Is Hermetic Replay in a Software Factory?
July 16, 2026
Every software factory has a part that moves work from step to step. That part is the control plane. It sequences station calls, records state transitions, and hands artifacts from one process stage to the next. It does not make decisions. It does not run models. It does not evaluate policies. It is the conveyor belt, and keeping it dumb is a deliberate architectural choice in the factory.
Continue Reading: What Is a Control Plane in a Software Factory?
July 16, 2026
The software factory needs a way to run multi-step processes that survive crashes, network failures, and hour-long model inference calls. Temporal is the leading candidate for that job. It is a durable workflow engine that tracks exactly where every process is, what it is waiting on, and what to do when something fails. But the factory treats Temporal as a replaceable implementation detail, not a load-bearing architectural choice.
Continue Reading: How Temporal Works as a Workflow Engine in a Software Factory
July 16, 2026
A software factory runs agents inside sandboxed stations. Those stations produce artifacts. But what keeps a compromised or prompt-injected agent from phoning home with your source code or customer data? The answer is an egress allowlist: a network rule that blocks every outbound connection except a handful of explicitly approved destinations. By default, nothing leaves the station. Only what's on the list gets through.
Continue Reading: What Is an Egress Allowlist in a Software Factory?
July 16, 2026
A software factory makes decisions without a human in the loop. Those decisions need to be auditable after the fact. But auditability is not enough if the record can be edited or deleted after the fact. Write-Once-Read-Many (WORM) storage solves this by making the provenance trail tamper-evident: once a record is written, it can never be changed. Only appended to. Trust in an autonomous system requires that kind of immutability, because the alternative is trusting that nobody will ever tamper with the logs.
Continue Reading: What Problem Does WORM Storage Solve in a Software Factory?
July 16, 2026
Every factory component, whether it is a new prompt bundle, a model routing rule, an adapter image, or a policy pack, goes through the same graduated promotion pipeline before it touches production traffic. The pipeline has four mandatory stages: offline eval, shadow, canary, and live. Each stage is gated by statistical significance checks and guard-metric non-inferiority conditions. Nothing skips a stage. This is how the factory safely improves itself over time.
Continue Reading: How Eval and Promotion: Shadow, Canary Work in a Software Factory
July 16, 2026
The eval loop makes the factory measurably better every run. But better at what? If you optimize for a single metric, the system will find ways to maximize that metric at the expense of everything else. Guard-metric non-inferiority is the safety condition that prevents that. It is the factory's answer to Goodhart's Law applied to automated improvement.
Continue Reading: What Is the Significance of Guard-Metric Non-Inferiority?
July 16, 2026
Goodhart's Law is not a theoretical concern when an automated improver can see its own eval set. It is an engineering constraint that the architecture must handle explicitly. A component that is repeatedly evaluated against the same corpus will eventually overfit. The improvements will be real on the eval set and imaginary in production. Goodhart defenses are the mechanisms that prevent this. They split the corpus, detect overfitting, and refresh stale cases.
Continue Reading: What Is the Purpose of Goodhart Defenses in AI and Agentic Loop Coding?
July 16, 2026
The risk-band routing system needs a risk scorer. The question is how to judge whether a risk scorer is any good. The naive approach is to check whether individual predictions match individual outcomes. Did this change turn out to be risky? That approach fails because risk is probabilistic. A well-calibrated risk scorer might predict a 30% chance of incident for a change, and the change might turn out fine. That does not mean the scorer was wrong. It means the 30% probability landed in the 70% safe zone. Calibration-based evaluation solves this.
Continue Reading: What Is Risk Scorer by Calibration in Software Factories?
July 16, 2026
Software factories process work in stages. Code moves from spec to plan to change-set to evidence to deployment. But not all work is sequential. Some tasks depend on others. Some tasks are independent. The dependency DAG is the structure that models this, ensuring nothing runs before its inputs are ready and nothing waits on work it does not need.
Continue Reading: What Is a Dependency DAG in a Software Factory?
July 16, 2026
A test oracle is only as good as its measured ability to catch bugs. I covered what a test oracle is in a previous post. This one is about what happens when you stop assuming your tests work and start measuring whether they actually do. That measurement is the oracle-strength floor, and it is how an autonomous factory decides if it can trust itself.
Continue Reading: What Is an Oracle-Strength Floor in an Autonomous Factory?
July 16, 2026
If you're running an autonomous software factory, a 'dark factory' where AI agents write, test, and deploy code with minimal human oversight, you've probably thought about governance tiers. Maybe you've mapped T0 paths where the system runs lights-out and T3 paths where a human must sign off before anything ships. So here's the question nobody asks until it bites them: what happens when a single change touches both?
Continue Reading: How the Tier-Max Rule Protects Autonomous Software Factories
July 14, 2026
The first thing that happens when someone submits a spec to a software factory is a gate: three checks that run before any work begins. No code generation, no planning, no dependency resolution. The gate validates that the spec is structurally correct, operationally unambiguous, and compliant with governance. If any of those checks fail, the spec bounces back to the author. This article is about why those three checks exist and why they matter.
Continue Reading: How Schema, Envelope, and Policy Matter in Software Factories
July 14, 2026
The concept of a test oracle is simple: it's the mechanism that tells you whether your code passed or failed. But in the context of an autonomous software factory, where code is generated, tested, and deployed with minimal human intervention, the quality of that oracle determines whether the entire system can be trusted. Weak oracles are the single biggest blocker to lights-out deployment, and measuring oracle strength is the factory's most important governance function.
Continue Reading: What Is a Test Oracle in an Autonomous Software Factory?
July 13, 2026
Autonomous software factories promise to compress months of engineering work into hours. But with autonomy comes a critical question: how do you know why a decision was made? Provenance is the permanent, append-only record of every decision, who made it, which policy gate fired, and what the outcome was. It's the accountability layer that transforms a black box into a trustworthy system.
Continue Reading: What Is Provenance in Software Factory Design?
July 13, 2026
In the current era of Enterprise AI, organizations are discovering a painful truth: there is a massive chasm between a "successful demo" and "measurable production ROI." To bridge this gap, a new breed of engineer has emerged: the Forward Deployed Engineer (FDE). Part elite coder, part strategic consultant, and part operational commando, the FDE is the secret weapon for companies that want their AI initiatives to survive first contact with reality…
Continue Reading: What is a Forward Deployed Engineer?