The Factory Must Prove Who Wrote the Code

A major open-source project refusing AI-generated contributions sounds like a verdict on AI coding. It is not. It is a verdict on evidence. The project needs a contributor who can make a clean claim about authorship and rights. A model can produce plausible code, but plausibility cannot answer where the material came from, whether a license followed it, or whether the person submitting it can make the required promise.

That distinction matters. Code can compile, pass tests, and still be unacceptable inventory. Functional proof answers whether the change behaves as required. Provenance proof answers whether the organization has the right to accept, modify, and distribute it. A factory that checks only the first question can move faster while quietly accumulating obligations nobody can see.

So the uncomfortable rule is reasonable: when the evidence does not exist, stop the change. But stopping there mistakes a present limitation for a permanent operating model. The better response is to build the missing gate.

Most teams treat an AI coding session as disposable conversation. A developer asks for a change, copies the answer, edits it, and submits the result under the same identity used for handwritten work. By review time, the inputs are gone, the model is unnamed, retrieval is invisible, and nobody can separate generated material from human revision. The pull request preserves the code while discarding how the code came to exist.

An agent-run factory cannot work that way. It should record the task, bounded context, model and tool route, generated patch, transformations, reviewer decisions, and the evidence that allowed the artifact to advance. That does not mean publishing private prompts or flooding every code review with transcripts. It means retaining a machine-readable chain that policy can inspect and an authorized person can audit when the consequence requires it.

Provenance is not a comment saying an agent helped. It is a property of the route. If the route can be skipped, rewritten after the fact, or reduced to somebody checking a box, the system has produced ceremony instead of proof.

The agent that creates a change should not decide whether its own origin story is sufficient. Give generation narrow inputs and explicit authority. Then make an independent acceptance stage inspect the change, its dependencies, its declared origin, and the evidence retained by the factory. Route uncertain material to a human decision owner. Reject anything whose history cannot satisfy the destination's policy.

Different destinations will demand different proof. An internal experiment may accept generated code with a light record. A distributable library may require stronger contributor declarations, dependency inspection, and review. A regulated system may need retention and approvals beyond either one. The factory should encode those differences instead of expecting every developer to remember them at the moment of submission.

This is where human judgment belongs: choosing the policy, deciding which uncertainty is acceptable, and owning exceptions. It does not belong in manually reconstructing every coding session after the work is finished. Machines should preserve the record because machines are better at preserving repeatable process.

A human touching generated code is not a provenance system. Renaming variables, moving functions, or rewriting a few lines may improve the result, but it does not automatically establish where the underlying structure came from or make every required declaration true. The amount of editing is also a terrible boundary: it is subjective, easy to game, and almost impossible to verify consistently.

Judge the artifact through the policy that governs its use. If a project requires a contributor to attest that the contribution is their original work, the delivery route must either produce evidence supporting that attestation or keep generated material out. Do not ask a person to convert uncertainty into confidence by clicking submit.

This will eliminate some current workflows. Good. A workflow that depends on nobody asking how the code was made is not ready for machine-scale production.

Our position is that generated code will become normal production input, and blanket bans will not remain the competitive answer. The organizations that move safely will not be the ones with the most permissive policy. They will be the ones that can prove what happened without slowing every change to the speed of a forensic investigation.

Build provenance into the factory now. Capture the route automatically. Keep model and tool access bounded. Separate generation from acceptance. Make the destination's policy executable, fail closed when required evidence is missing, and preserve exceptions as named decisions instead of folklore.

Models will change. Coding interfaces will change. The obligation to stand behind what enters your codebase will not. If the factory can retain that chain, agents become governable productive assets. If it cannot, every generated patch arrives carrying invisible debt—and the fastest way to manage it will remain a ban.