Solved Code Still Needs a Factory

The new coding systems are not toys. They can explore a repository, plan a change, write the implementation, run tests, answer review feedback, and prepare a release. Treating that capability as autocomplete with better marketing is denial. Repeatable implementation work is moving from payroll into machinery, and organizations that refuse to move with it will lose to organizations that do.

But calling coding solved collapses a chain of different problems into the one step that produces files. A plausible change is not necessarily the requested change. A passing test is not necessarily proof of the real consequence. A merged branch is not necessarily safe to operate. Faster construction amplifies every unresolved decision around construction.

The useful question is not whether a model can code. It can. The useful question is whether your operating system can turn that capability into changes you meant to make, evidence you can trust, and behavior you can support after the generating context disappears.

A request such as ‘make onboarding easier’ contains no buildable destination. Easier for whom, at which step, under what constraints, and measured by what observable behavior? A person can hide those missing decisions inside meetings and intuition. An agent will often hide them inside a confident implementation. Neither has solved the requirement.

A software factory forces the ambiguity into the open before production begins. It turns intent into a bounded specification, identifies the systems allowed to change, names invariants that must survive, and defines the evidence required at the exit. When two interpretations carry different consequences, the line stops and routes that decision to its owner.

That is where human judgment moves. People choose the destination, set the standards, and own the consequences. Agents perform the repeatable research, decomposition, implementation, checking, and coordination around those decisions. This is not a promise that every current role remains. It is a description of which work retains value when typing the implementation is no longer scarce.

The builder cannot be the only judge of the build. Asking the same agent to review its own work leaves the same assumptions in control. It may produce a cleaner explanation of the same mistake. It may select tests that demonstrate the path it implemented while missing the path the product actually needs.

Independent proof changes the system. Acceptance checks come from the specification, not from the completed patch. Architecture rules reject forbidden dependencies. Security boundaries fail closed. A separate verifier attacks the result under conditions the builder did not choose. Production observation feeds escaped failures back into the next plan.

A gate matters only when failure changes what happens next. If an agent can explain around it, skip it, or replace it with a screenshot, the gate is theater. The factory must retain the evidence, block the release, and route the unresolved consequence to the person authorized to accept it.

When implementation becomes abundant, requests multiply. Features that once died in a backlog can become code before anyone prices their operational drag. Experiments become permanent surfaces. Small conveniences acquire support obligations, security boundaries, migration paths, and future interactions nobody selected deliberately.

The factory therefore needs a value gate before it needs another model. What outcome justifies this change? What must remain true? How will the change be removed? Who owns the consequence if it behaves exactly as specified and still produces the wrong business result? Cheap construction makes those questions more important because cost no longer slows weak ideas down.

Our prediction is that the winning organizations will generate plenty and keep relatively little. Their advantage will come from fast selection, mechanical proof, and aggressive removal—not from treating every available implementation as inventory worth shipping.

A model demonstration ends when the code works once. A software factory begins there. It has to preserve context across runs, constrain authority, record why decisions were made, verify changes outside the builder's chosen conditions, release safely, watch production, and turn failure into a stronger control the next agent inherits.

That machinery is the differentiator. Models will improve, prices will move, and today's leader will be replaced. A factory built around one model's momentary advantage expires with it. A factory built around specifications, routing, evidence, permissions, and feedback can swap productive assets without surrendering its standards.

So take the claim seriously: coding may be approaching a solved capability. Then refuse the lazy conclusion. The work did not vanish. The bottleneck moved from producing code to governing an industrial supply of it. Build the factory that can decide, prove, and operate—or spend your new abundance manufacturing consequences you never chose.