Programming Ends Where the Factory Begins

For most of software's history, source code was expensive because a person had to produce nearly every line. That made programming capacity the obvious constraint. Companies hired more programmers, divided systems into areas those people could understand, and made human review the main defense against bad changes.

Agents break that arrangement. They can produce changes in parallel, keep working after a person stops, and revise an implementation again and again against a target. The important change is not that an agent can complete a clever demo. It is that a governed group of agents can keep moving through a large body of work without waiting for a matching increase in human typing time.

Once output grows beyond what people can inspect line by line, code is no longer the scarce object. Clear destinations, trustworthy constraints, and convincing evidence are. The organization that keeps measuring engineering by lines reviewed or tickets touched will mistake the exhaust for the engine.

Human code review works when the volume fits inside human attention. It fails as the primary control when agents can create more changes in a day than a team can seriously read in a week. Adding reviewers does not fix the ratio. It recreates the old labor bottleneck downstream of a machine that was built to remove it.

The replacement is not blind trust. It is stronger proof. Define the behavior before the builder begins. Run deterministic checks where the answer can be mechanical. Reproduce the result outside the builder's chosen conditions. Compare a migration against the old system. Exercise failure paths, permissions, rollback, and production signals. Then preserve the evidence with the change.

People still judge consequences. They decide whether the requirement is right, whether the proof covers what matters, and whether the remaining risk is acceptable. They do not need to read every generated branch and helper to make those decisions. In fact, pretending they did is weaker governance than admitting what was actually verified.

A capable model with a large budget can attempt an enormous rewrite. That alone does not create dependable software. The durable mechanism is the harness around the attempt: how work is divided, which contracts remain fixed, what agents may change, how parallel results meet, and what causes a route to stop instead of guessing again.

This is where engineering craft moves. An expert's judgment cannot remain trapped in review comments and private intuition. The factory needs that judgment as executable specifications, repository rules, permission boundaries, acceptance tests, and recovery paths. Every rejection should sharpen the next run. Every production failure should become a case the system knows how to reproduce.

The model will change. The accumulated operating knowledge should not. If switching workers destroys your standards or forces the team to relearn every failure, you did not build a factory. You built a long conversation with a temporary employee.

When creating another feature gets cheap, deciding to own it gets expensive. Every new capability adds behavior that must remain secure, observable, compatible, and understandable after the agent that created it has moved on. A working prototype answers whether something can exist. A production decision answers whether the organization wants the obligation that comes with it.

That changes planning. The question is no longer only, “Can we build this?” Agents will make the answer yes more often. The useful questions are whether the feature deserves a permanent place in the product, which failures the company is willing to carry, what evidence earns release, and who has authority when the evidence is incomplete.

More software will be built because the cost of trying is falling. More bad software will be built for exactly the same reason. The difference will not be whether an organization has access to a powerful model. It will be whether its factory can refuse unsupported work, retire low-value behavior, and keep the promises that survive.

Our prediction is that manual coding and line-by-line review will become a minority path for producing software. They will persist where the economics, regulation, or preference support them. They will not remain the default simply because that is how today's teams learned to work.

Repeatable implementation, review preparation, testing, and maintenance will move into factories because agents can perform those loops continuously and retain the corrections. That will eliminate roles built around carrying work between human queues. Calling every displaced task “augmentation” does not protect the job. It only delays the operating decision.

The valuable human work moves higher: choose the destination, design the system, define the proof, set authority, and own the consequence. Programming as hand production is ending. Engineering as the design of machines that produce and prove software is just becoming the job.