Disposable Code Needs a Hard Boundary

A one-off command exists to change a known file, inspect a narrow state, or answer a question before the next step. It may be terse. It may assume the exact environment already in front of it. If it fails, the agent can throw it away and try something clearer. That is reasonable because the command is scaffolding, not part of the building.

Product code has a different obligation. It has to survive new inputs, future changes, unfamiliar operators, and the next agent arriving without the original conversation. Names, structure, error handling, interfaces, and tests matter because the code will keep making decisions after the context that produced it is gone.

Confusing those jobs creates a quiet failure mode. A shortcut that was acceptable inside a disposable tool call gets copied into a test, a migration, or a production module. The code still runs, so the change looks complete. The factory has promoted scaffolding into architecture without holding a promotion review.

Agents optimize the objective the route makes visible. If fewer tokens, fewer tool calls, and rapid completion receive the strongest feedback, compressed execution is a rational response. Dense commands and clever transformations can be efficient ways to manipulate a workspace when no one needs to maintain the command itself.

That local win becomes a system loss when durability is not measured separately. A compact implementation may hide state in arbitrary positions, combine unrelated behavior, or make a future change depend on reconstructing a trick. The agent saved a small amount during generation and handed every later run a larger interpretation bill.

Telling the model to write clean code is not a control. The instruction competes with every other signal in the task, and clean is too vague to reject anything. The factory needs a mechanical distinction between code used to perform the change and code delivered by the change, because only one of those should become a maintained asset.

Treat durable code as a promotion. Before an artifact enters the repository, the route should identify its language, destination, ownership, and expected lifetime. Then apply the standards that follow from those facts: formatting, types, complexity limits, repository conventions, focused tests, and a review of whether the change uses the interfaces the codebase already provides.

The source of the bytes does not matter. An agent may generate a file directly, patch it with a purpose-built editor, or produce it through a temporary script. What matters is the final boundary. Every added line should face the same checks, and temporary helpers should remain outside the staged artifact unless they independently satisfy the product contract.

Diff boundaries are especially valuable here. A task that intends to change two files should not quietly add a helper, rewrite a notes directory, or leave behind a generated scratch program. Define the allowed paths before execution, compare them with the final change, and stop when the artifact set expands without an explicit decision.

Passing tests prove behavior under the cases those tests exercise. They do not prove that another worker can understand the design, locate the state, or change one rule without breaking three others. A factory that only checks runtime behavior can ship code that works today while making tomorrow's work steadily less reliable.

Some maintenance qualities can be enforced directly. Formatters remove accidental compression. Type systems expose hidden assumptions. Complexity budgets flag branches that are becoming hard to reason about. Architecture checks can prevent production modules from reaching into unstable internals. Focused mutation or negative tests can show whether the suite objects when the implementation is deliberately damaged.

The rest requires accountable judgment, but that judgment should create machinery. When a reviewer rejects an opaque pattern, capture the reason as a rule, a lint check, a repository example, or a test. The goal is not to preserve manual code review forever. It is to make each useful review less necessary the next time the same shortcut appears.

Agents will absorb more implementation work because they can execute it continuously, retain rules, and apply checks without waiting for a person. That shift will remove roles built around routine coding and routine review. It will not remove the need to decide what the system is allowed to optimize away.

Human judgment belongs at that level. People choose the qualities that must survive, the maintenance cost the business will accept, and the exceptions worth making. The factory turns those choices into separate execution and delivery policies, then refuses to promote an artifact that only met the cheaper standard.

Our position is simple: disposable code is useful, and durable code is valuable. A serious software factory knows which one it is producing at every step. Let agents take shortcuts inside a bounded workspace when the consequence is temporary. At the repository boundary, make every shortcut prove it belongs there—or leave it on the factory floor.