The Software Factory Is Here

For most of the history of software, an engineer was judged by what they shipped. Pull requests merged. Tickets closed. Features in production. Lines of code, then features, then story points — the metric kept changing, but the underlying assumption held: an engineer is a person who writes code, and the output of an engineer is code.

That assumption is wrong now. The engineer of 2026 is judged not by what they shipped but by what their factory ships. The output is no longer the code. The output is the system that produces code — the prompt, the scaffold, the eval harness, the replanning loop, the agent harness that the rest of the company invokes. The engineer's leverage is multiplicative. The factory runs while the engineer sleeps.

This is the most important career shift in software since the move from assembly to high-level languages. Most engineers have not noticed it yet.

The Three Levels of Leverage

Level 1 — the individual contributor

The engineer who writes code. One person, one output per unit time. The metric is features shipped per quarter. The ceiling is hours in the day.

This level still exists. It always will. There are bugs only a human can debug, edge cases only a human can find, architectural decisions only a human can defend. The mistake is to think every engineering hour is a Level 1 hour.

Level 2 — the scaffold-builder

The engineer who builds the scaffold that the model runs inside. The prompt templates. The eval suite. The test fixtures. The context-window management. The error-recovery loop. The replanner that detects when the model has gone off the rails and starts over.

A good scaffold turns a 60%-reliable model into a 99%-reliable product. A great scaffold does it across multiple models. A great scaffold is reusable across products, across teams, across verticals.

The Level 2 engineer ships a scaffold once and uses it fifty times. Their output is fifty products that work.

Level 3 — the factory-builder

The engineer who ships an agent harness that the rest of the company invokes. Not a tool. Not a scaffold. A factory. A factory takes inputs and produces outputs, with quality control, with retries, with logs, with cost tracking.

The factory has:

• An intake surface (where work arrives)
• A planner (what work means, what success looks like)
• An executor (the agent that does the work)
• A verifier (the human or model that signs off)
• A loop (what happens when the verifier says no)

The Level 3 engineer ships one factory. The factory ships a thousand features. The engineer's leverage is 1000×.

The Metric You Should Be Optimising

Not tokens. Not lines of code. Not story points. Not even features shipped.

Your time × final output.

The cost function is: how many hours of my time did it take to ship something the customer uses, and how many customers use it. Everything else is vanity. Tokens are a means. Models are a means. Frameworks are a means. The output is what matters.

The corollary — and this is the heretical bit — is that you should waste tokens. Throwaway pre-production code, throwaway prototypes, throwaway scaffolds you throw away the day after — all fine, if the final ship is good. Compute is cheap. Thinking time is expensive. Your most expensive resource is the hour you spend wondering whether to spend the dollar.

What the Factory Looks Like in Practice

A real factory, on a real product team in 2026, looks like this:

• A backlog of work in Linear or Jira, fed by customer requests, support tickets, and product strategy.
• A planner that reads the backlog, picks the next item, drafts a plan, and posts the plan to a PR.
• An executor (an agent, sometimes a fleet of agents) that opens the PR, runs the linter, runs the tests, fixes its own failures, and pushes.
• A verifier — sometimes a model, sometimes a human — that reviews the diff, runs an eval suite, and either approves or sends back.
• A loop — when verification fails, the planner revises, the executor re-runs, the verifier re-reviews. Three strikes, then a human.

The factory ships while the team is asleep. The team wakes up to a queue of merged PRs, a handful of items that need a human call, and a dashboard of cost per shipped feature. That dashboard is the new sprint review.

The Roles Change

In the factory model:

• Junior engineers don't write boilerplate. They don't write CRUD. They don't write tests. They learn by reading the diffs the factory produces and explaining why they are wrong.
• Senior engineers don't write features in isolation. They write the scaffolds. They write the eval harnesses. They write the prompts that produce the features.
• Architects don't draw diagrams. They design the factory. They pick the planner, the executor, the verifier. They choose which loops to automate and which to leave human.
• Principals don't review every PR. They review the factory. They ask: does this factory produce the right outputs, at the right cost, with the right risk profile? They tune. They upgrade.

The hierarchy does not disappear. The work does.

What This Means for You

If you are an engineer: stop optimising your output. Start optimising your factory. The engineer of 2026 is not the person who ships the most code. The engineer of 2026 is the person who ships the most useful system.

If you are a founder: stop hiring engineers who ship features. Hire engineers who ship factories. The first hire costs you a feature a week. The second hire costs you a factory that ships features every hour.

If you are an investor: stop pricing teams by headcount. Price teams by factory output. The five-person team with a working factory is the 50-person team without one.

The software factory is not a metaphor. It is the operating model of the next decade.