Security Has to Run at Generation Speed

Generated code often looks reassuring. It compiles. The names are tidy. The happy path is complete. Those signals matter, but they mostly prove that the code is legible to the machine and plausible to the reviewer. They do not prove that the operation belongs to the caller, that the input is safe, or that a dependency deserves the authority it received.

That difference gets expensive when generation scales. An agent can repeat a structurally wrong assumption across routes, services, and repositories faster than a review queue can notice the pattern. The defect is not that the agent forgot a semicolon. The defect is that the system never made authorization, validation, data movement, and privilege boundaries explicit enough to enforce.

This is the uncomfortable part: code can become cleaner while the product becomes less secure. Surface correctness is visible immediately. A broken trust boundary may stay quiet until somebody uses the system in a way the builder did not imagine. A factory that rewards accepted syntax and passing happy paths will optimize for the wrong kind of confidence.

Most teams answer this risk by asking security reviewers to look harder. That cannot be the operating model. Agents increase the number of changes and shorten the time between them. When one specialist has to read every change, reviews pile up in a queue, and that pressure makes it easy to give routine-looking work less attention.

The factory has to move repeatable security judgment ahead of generation. Before an agent writes the change, the route should already know which data it may touch, which identities may perform the action, which network paths are allowed, and which dependencies are acceptable. Those are inputs to the work, not questions to discover after the pull request arrives.

Human judgment still owns the boundary. People decide what consequences are acceptable and where a mistake would be irreversible. But once that decision is made, it should become policy the machinery applies every time. Paying a person to remember the same rule on every change is not control. It is a recurring opportunity to forget.

A passing test written by the builder proves only what the builder chose to ask. Security needs an independent route. Exercise the operation as the wrong user. Send malformed input. Remove a required permission. Replace a trusted response with a hostile one. Check the deployed configuration, not only the source that was supposed to create it.

The evidence should describe the boundary and the attempted violation in terms another system can judge. A screenshot of a successful request is not enough. Record which identity acted, which authority was absent, what the system refused, and where the result was reproduced. Make that proof a condition of acceptance, so neither the builder nor a rushed reviewer can wave it through.

Different changes deserve different depth. A copy edit should not buy the same security ceremony as a new authorization path. Route work by consequence, then make the chosen route mandatory. The point is not to slow every change equally. It is to spend proof where the blast radius lives and refuse work that cannot produce it.

Security tooling is useful, but a scanner that produces a report nobody feeds back into the line is just another inbox. When a check catches an unsafe pattern, the factory should learn a durable constraint. Tighten the template. Narrow the permission. Add the adversarial case. Block the dependency class. The next agent should meet the correction before it can repeat the mistake.

That feedback loop matters more than a heroic cleanup. Agent-written software will keep arriving faster, and some current roles built around producing routine code will disappear with it. The organizations that adapt will move judgment into standards, routes, and evidence. The ones that preserve security as a late human inspection will create more work than their experts can honestly absorb.

Our position is simple: faster generation requires faster refusal. Build the boundaries first. Test them somewhere the builder does not control. Turn every escaped assumption into a rule the next run cannot ignore. Security does not belong behind the factory, chasing its output. It belongs inside the line, setting the speed at which work is allowed to become real.