AI coding has found its first honest price.
It is not tokens. It is not seats. It is not the monthly bill for whatever assistant currently has the nicest landing page. It is the time of the human maintainer who has to decide whether a plausible-looking patch is safe, licensed, maintainable, and worth owning eighteen months from now.
That is why parts of open source are drawing sharper lines. Not because every contributor has suddenly become a Luddite with a Makefile. Because the industry has made production of code almost free while leaving verification stubbornly expensive.
OpenJDK’s interim policy is unusually clear about the distinction. It permits private use of generative AI for comprehension, debugging, review, and research, while prohibiting AI-generated material in contributions. The project is not pretending the tools have no value. It is refusing to turn a finite pool of reviewers into the cleanup crew for an infinite code generator.
The scarce resource is no longer code
The policy’s rationale is refreshingly unromantic: plausible code can still be wrong, poorly designed, or legally impossible to accept. For a project that sits under business and government systems, that is not an aesthetic complaint. It is an operating constraint.
Debian is now having the argument in public. Its current General Resolution ranges from an outright ban on LLM-assisted contributions to a permissive model that makes the submitter accountable. The Hacker News discussion captures the real divide better than the usual AI tribalism: some developers see agents as an indispensable way to find and fix defects; maintainers see drive-by pull requests whose author may never understand the code they want someone else to merge.
Both observations can be true. An agent may find a security issue in minutes that a human would miss for days. It may also produce two thousand lines around a ten-line fix and quietly transfer the future maintenance obligation to a volunteer who did not ask for a new hobby.
This is the asymmetry vendors keep skipping. Generation scales with compute. Responsibility does not. A model can emit a patch, a test suite, a cheerful explanation, and three follow-up replies before lunch. The person reviewing it still has one brain, an issue queue, and probably a job.
“Human in the loop” is too vague to be useful
The usual answer is that a human remains in the loop. Fine. Which human, doing what, with what evidence, and for how long?
OpenAI’s recent scientific-computing field report is more candid than most product announcements. The teams that got value from coding agents did not let them define correctness. They used output parity, known-answer tests, simulated data, and staged acceptance criteria. Researchers moved toward specification, validation, and stewardship; the agent accelerated implementation. The last mile, naturally, remained the expensive bit.
That is not a failure of AI coding. It is the job description of a mature workflow. But it does mean the market’s favorite metric—how much code an agent can generate—has become slightly ridiculous. Nobody buys a bridge because the concrete mixer had a productive afternoon.
The better question is whether the system makes confidence cheaper. Can it shrink the thing a human must inspect? Can it produce a replayable test, a narrow diff, a provenance trail, a proof, or a reliable rollback? If not, it may be accelerating output while slowing the institution that has to absorb it.
The escape hatch is not “more careful prompting”
There is a promising alternative to the false choice between banning AI and trusting a chatbot’s prose. Make the output carry evidence.
One recent Lean 4 project, a formally verified mesh-intersection implementation, makes the point with almost rude clarity. Its author says a reviewer can inspect 93 lines of specification and have the Lean checker verify more than a thousand lines of AI-written implementation and 60,000 lines of AI-generated proofs. The project is slower than state-of-the-art software, and it does not prove every property that matters. Those limits matter. So does the direction: replace “please review this mountain” with “review this contract and check the machine’s receipt.”
That model will not fit every patch. Formal methods are not a magic solvent, and maintainability is more than functional correctness. But the principle travels well. AI-generated work needs to be narrower, more testable, more attributable, and easier to reject than human work—not harder.
Open-source policies are therefore not the death rattle of AI coding. They are the first serious design review. The communities that matter are asking a brutally practical question: if machines can create unlimited work, what stops them from creating unlimited debt?
The answer cannot be a checkbox, a prompt file, or another assurance that the model was very confident. It has to be a control system that makes trust cheaper than review.
Until then, maintainers are right to send the bill back to the sender.