A Software Factory Is Configurable Autonomy — Not Faster Coding

The factory is not the agent

The industry keeps reaching for a factory metaphor because generation finally looks cheap. Prompt, get a diff, merge, repeat. That feels like a production line. It isn't. A production line has named stations, a refusal that is cheaper than scrap, and someone who still owns the part after it ships. Most "agent factories" have a queue and a model. They do not have a refusal.

A software factory is how the organization allocates unsupervised work. Which jobs may an agent take. How far it may go before a person has to decide. What evidence comes back. Who carries the consequence if the path was wrong. The agent is labor on that floor. The factory is the floor.

This is adjacent to a conversation Addy Osmani has been having about loops, harnesses, and who still reads the work.[1] We agree that more generation is not the hard problem. The argument here is narrower and more operational: the factory is not a manufacturing aesthetic. It is configurable autonomy — for engineering and product — encoded as policy, not as culture.

Three jobs: decide, bound, prove

If a factory cannot do these three things, it is a generator with a dashboard.

Those jobs sit above any one loop. Loop engineering designs how an agent steps. Harness engineering governs what a step is allowed to do. The factory is the org chart and the policy that say which loops exist, which harness they run in, and who still owns the result.

Autonomy is a budget, not a vibe

Teams talk about autonomy as if it were a personality trait of the model, or a cultural stance: we trust agents, or we don't. That binary is how you get the two failure modes that look opposite and are the same mistake. Everything unattended, and unread work piles up until the system is a stranger. Everything gated, and the queue dies in review. The skilled job is a dimmer per path, not a light switch for the company.

Treat unsupervised action as a budget you spend. A nightly lint cleanup can spend more of it than a change to auth, billing, or a public contract. The budget should move when the blast radius moves — a new engineer, a new vendor, a new model, a brownfield module nobody has touched in two years. Autonomy that cannot be turned down is not autonomy. It is hope.

In practice the dimmer is already a vocabulary we use in harnesses: allow, ask, or deny, on the tool path, before execute. Propose-only is a fourth setting for work that should never touch production without a person. The names matter less than the rule: two paths with different cost of being wrong must not share a setting.

Product is already on the factory floor

Most factory talk is written as if only engineers generate. That was never true, and agents made it obvious. Product already writes specs, tickets, copy, and "done." Support already drafts replies. Ops already files the change. If the dimmer only lives in the IDE, the rest of the company is still feeding agent output into the same production — without a named owner for refusal.

Configurable autonomy for product looks like the same three jobs with different tools. Decide: is this a problem we want an agent to scope, or a judgment we still owe a customer. Bound: may it open a ticket, may it change marketing copy, may it never touch pricing or a public API. Prove: can you show who approved the launch checklist that shipped. Engineering's factory and product's factory are one operating model. Split them and you get two queues that collide in production.

This is why we describe Applied by Exemplar as a software factory harness for engineering and product — not a coding copilot rollout. The strategy has to survive the first team, and it has to cover the people who never open a terminal.

How factories quietly fail

The loud failure is a broken deploy. The quiet one is a green week nobody can narrate. Tests passed. PRs merged. Token spend looks like progress. A new hire asks why the module looks like this, and the honest answer is that an agent wrote it and no one still holds the plot. That is not a model problem. It is an unread-work problem. Throughput without a dimmer is a queue of work the org no longer understands.

Four patterns show up again and again:

• Autonomy as culture. "We let agents run" is not a policy. It is an absence of one. Culture cannot distinguish lint from ledger.
• Review as theater. A human clicks approve on a two-thousand-line diff they did not read. The gate existed. Judgment did not.
• No owner of refusal. Inner work — investigate, implement, check — can move to an agent. Outer accountability — was this the right problem, is the evidence sound, who carries being wrong — cannot be defaulted to the model. If nobody names that job, it disappears.
• Product left out. Engineering puts a harness on Cursor. Marketing ships agent copy. Both hit customers. Only one had a dimmer.

We have already seen what ungoverned agent paths look like when they reach production: sandboxes that were not sandboxes, harnesses that failed without the company noticing, migrations pointed at the wrong database.[2] The factory is how you stop treating those as freak accidents and start treating them as paths that never earned their autonomy budget.

What has to sit outside the model

Models will keep getting better at fluent inner work. They will not volunteer a long-term owner, a blast-radius map, or an interrupt that actually stops the tool. Those have to live outside the weights: types and tests that are hard to fake, policy on the tool path, identity, evals, and an audit trail a person can read under time pressure.

Two surfaces, one factory. Relay is the IDE path — the inner loop where engineers already work. Marshal is the production path — standing agents that call tools, change infra, touch data. The operating question is the same on both: allow, ask, or deny before execute, with evidence after. If only one surface is harnessed, work routes around it.

Architecture does a second job now. Short seams, explicit boundaries, and checks that run without a person in the room are how you buy back autonomy you can actually spend. That is not new advice. Agents made it expensive to keep ignoring.

How to start without building a cathedral

Do not stand up "the factory" as a program. Pick paths. Set the dimmer. Name the owner of refusal. Repeat until the next team can copy it.

1. Inventory the paths that already exist. IDE agents, CI bots, support drafts, ticket filers, Day 2 runbooks. You cannot budget autonomy you have not named.

2. Split by cost of being wrong, not by team. Cheap, frequent, hard-to-fake checks can run with more unsupervised action. Auth, money, customer data, and public contracts stay on ask or deny until a person can still explain the change.

3. Put policy before execute. A freeze in chat is not a harness. If the tool can still run, the dimmer is decoration. See why this is an operating problem, not a model choice.

4. Require evidence that a human can use. Diff, tests, logs, and a short account of why this was the right problem. If the packet is too large to read, the path asked for more autonomy than you can verify. Shrink the path. Do not skip the read.

5. Include product in the first working session. One engineering path and one product path. Same language for allow, ask, deny. Same owner of refusal. That is the factory, small enough to ship.

You know it is working when saying no is cheaper than it was last month, and last week's changes can still be told as a story. Volume is a side effect. Understanding is the product.

Frequently asked questions