Your Prompt Is a Manual Build Step

There are several familiar ways to ask a model for software. You can specify every detail up front. You can give it a broad goal and hope it fills the gaps correctly. Or you can explain the parts you expect to be difficult and repair the rest afterward. Each approach can produce useful work. Each also places a person directly in the production path.

The labor changes shape depending on where you put it. Detailed instructions charge you before the run. A loose request charges you after the run through review and correction. Examples can shorten the explanation, but someone still has to find the right example and decide whether its assumptions fit. None of this is a model failure. It is evidence that context assembly is production work.

A large codebase contains more information than one task needs and more noise than an agent should receive. The answer is not to stuff the entire repository, every specification, and years of discussion into a larger window. More context can bury the decision that matters. The factory has to select the smallest complete packet for this piece of work.

That packet should include the current objective, the relevant architecture, local conventions, authority boundaries, known failure modes, and the evidence required to finish. It should be assembled from maintained sources, not reconstructed from one engineer's memory. When the task changes, the packet changes. When production exposes a new edge case, the source material and retrieval rules change with it.

This is compression with consequences. A summary that drops a critical constraint is not concise; it is defective input. The context stage needs its own checks: required decisions are present, conflicting rules are surfaced, stale material is rejected, and every omission has an owner. A prompt can then become short because the system behind it did the hard work.

Different models will remain better at different classes of work, and those differences will keep changing. Asking every engineer to track that market and choose correctly on every task turns model selection into another manual queue. It also makes results depend on personal habit instead of an operating policy.

The factory should route work by measured behavior. A cheap model can handle a repeatable transformation with strong checks. A harder planning problem can earn a more capable model and a larger budget. A failed attempt can escalate to another route. The person requesting the outcome should not need to know which engine ran any more than a warehouse customer needs to choose the motor on the conveyor.

The model is a replaceable component. The routing rule, budget, fallback, and proof requirement are the durable system. When a new model wins under your conditions, you change the route. You do not retrain the organization in a new set of prompting rituals.

Tests and tools matter because fluent output is not evidence. But a test that merely sends the same failure back to a person creates a faster rework loop, not a factory. The useful loop identifies what failed, routes it to the stage that owns the mistake, and changes the next run.

If an agent missed a requirement, repair the specification or context rule. If it chose an unsafe implementation, strengthen the boundary or acceptance check. If the evidence was weak, change how proof is gathered under conditions the builder did not choose. The lesson has to survive the conversation and become machinery that every later run inherits.

That is where agents gain an advantage over human delivery teams. A person can remember a lesson, apply it inconsistently, and leave. A factory can retain the rule, enforce it continuously, and show when it fired. The feedback loop is not a chat transcript. It is the mechanism that makes the same class of failure less likely next time.

Implementation effort is falling. That does not mean the rest of software delivery vanished. Intent still has to become a specification. Relevant context still has to reach the builder. Models still need routes and budgets. Results still need independent proof. Production still has to teach the next cycle.

Our position is that people should own the judgments inside that chain, not perform its repeatable transfers. Decide what should exist, which tradeoffs are acceptable, and what consequences require a stop. Then encode those decisions so agents can carry them through planning, implementation, verification, release, and observation without asking a person to reload the machine every time.

Prompting skill is useful while the machinery is young. It is not a durable operating model. The organizations that scale agent-run delivery will turn their best explanations, examples, corrections, and checks into a context system the factory can run. Everyone else will keep calling manual preparation autonomy because the typing happens in a different box.