When outsourcing custom development, have you ever asked during deliverable acceptance, "Does this code contain any parts generated by AI?" Most companies have not asked. And among those that have, many stall at the exact same hurdle: they lacked criteria to evaluate the answer they received.
When told "yes, we use it," they do not know whether that constitutes a problem. On the other hand, declaring an outright ban after the fact undermines the assumptions of the estimate. In the end, nothing is decided on the spot, and the identical question is repeated on the next project.
Several projects answered this question in rapid succession during the summer of 2026. Moreover, while appearing distinct on the surface, their ways of drawing the line are remarkably consistent.
Policies issued by three projects
OpenJDK released its policy widely in early April 2026, banning contributions containing content partially or wholly generated by large language models, diffusion models, or similar deep learning systems. Two reasons were cited. The first is review burden: code that appears plausible but is actually erroneous or difficult to maintain consumes limited review time. The second is safety and stability, grounded in the fact that the JDK underpins mission-critical systems. However, developers using LLMs for their own debugging or code comprehension is not prohibited.
In the Linux kernel, Greg Kroah-Hartman stated on August 3, 2026, a policy of generally rejecting patches created by AI/LLMs within the drivers/staging/ subsystem he manages. The sole exception is fixes for actual security issues. His reasoning was distinct: staging serves as a place for newcomers to learn the submission process—in his words, a "gym"—and a flood of LLM-generated patches undermines that purpose. Rather than code quality itself, the issue is that the training ground gets overwhelmed.
On August 5, 2026, five teams managing the compiler and standard library for Rust adopted an LLM usage policy for contributions to rust-lang/rust. Rather than an outright ban, this policy takes the form of permitting use for analysis and verification while strictly limiting generation.
What they share: dividing by process phase
Looking across all three, not a single one drew the line as a binary choice between banning and permitting.
| Project | Restricted | Permitted |
|---|---|---|
| OpenJDK | Submitting generated output to repositories or PRs | Use by individual developers for debugging and reading |
Linux drivers/staging/ | Submitting AI-generated patches (actual security fixes excepted) | Use in other areas, including use by maintainers themselves |
| rust-lang/rust | "Creation" via LLMs | "Analysis" and "verification" via LLMs |
The lines are drawn by process phase: permitting use on the side of reading, investigating, and verifying, while restricting use on the side of generating and submitting deliverables. This structure is common to all three.
Their rationales also align. The review burden cited by OpenJDK and the flood cited by GKH are different ways of describing the same phenomenon. As generation costs dropped, submission volume exceeded the processing capacity of the receiving side. What is restricted is not the technology, but the unverified volume pouring in.
This asymmetry manifests in the same way in internal development. Even if generation accelerates, the speed of review and verification does not change. Structurally, it is identical to the bottleneck examined in Review Cannot Keep Up with the Volume of AI-Generated PRs.
Policies diverge even within the same company
There is another fact worth noting. While OpenJDK bans AI-generated contributions, GraalVM under the same Oracle umbrella permits them. Furthermore, Oracle co-founder Larry Ellison has publicly stated that AI models write code at the company.
While this can be seen as a contradiction, a different interpretation is far more useful in practice: even within the same organization, appropriate policies differ depending on the nature of the project. It is natural that acceptable risk levels differ between mission-critical infrastructure and experimental language runtimes.
The takeaway for commissioning clients is clear: attempting to formulate a uniform company-wide policy of "our company permits/bans AI-generated code" will inevitably strain somewhere. The unit of decision must be the system, and the evaluation criterion is what happens if that system fails.
Translating into acceptance criteria
Based on the above, here is a breakdown of what commissioning clients can realistically define:
- Define categories per system. Vary the depth of required verification between systems where downtime causes immediate business damage, such as mission-critical operations or billing, and internal support tools. Setting everything to the strictest benchmark directly inflates project costs.
- Define verification accountability rather than imposing bans. What works in practice is not interrogating generation methods, but clarifying that the contractor bears accountability for deliverable content. Whether written by humans or AI, code that fails to run is equally problematic.
- Do not allow review effort to be cut from estimates. When estimates are compressed on the grounds that generation has accelerated, what gets cut is almost always the verification phase. Deliverables with reduced verification manifest problems not immediately upon delivery, but several months later.
The third point is especially critical. Problems with AI-generated code are difficult to spot at delivery and surface six months later during maintenance. Passing acceptance inspection does not equate to confirmed quality.
Merely requiring disclosure does not work
Conversely, introducing an operational rule of "requiring declaration of AI-generated sections" in isolation rarely works. There are three reasons for this:
Declaration granularity cannot be defined. Does accepting several lines via autocomplete count as "AI-generated" alongside entire modules generated from prompts? Requesting declarations without clear boundaries yields answers devoid of useful information.
There are no verification methods. In practice, clients have virtually no way to verify whether declared details are accurate. Writing terms into contracts that depend on good faith fails when disputes arise.
Even when disclosed, evaluation criteria are lacking. Returning to our opening point, this is the biggest issue: if you have not decided what to look for when told "yes, we use it," asking serves no purpose.
What proves practical is requiring proof of verification rather than declarations of generation methods: whether records exist showing passage through static analysis and security reviews, and what scope tests cover. These are items that should naturally be expected for human-written code as well, and they can be evaluated regardless of AI generation. Methods for mechanically augmenting reviews are compiled in Automating Security Reviews for AI-Generated Code.
What to do next
Try categorizing the systems you currently outsource into two or three tiers based on the impact if they fail. Once categorized, the systems where you should require proof of verification will be determined automatically. Companies that stall trying to impose identical standards across all systems are skipping this step.
Then, when you receive your next estimate, check the breakdown of review and testing phases. With just that, meaningful discussions regarding the handling of AI-generated code can readily begin.
If you would like to consult on reviewing development structures or assessing existing system quality, we assist through GleamHub's Development, AI, and Automation Consultations. Because steps to take vary based on system architecture and your current team structure, please reach out for an individual consultation. Feel free to contact us via Contact Us.
Sources
- Oracle’s OpenJDK Bans Generative AI Contributions While Oracle’s GraalVM Allows Them — InfoQ
- Oracle bans AI-generated contributions to OpenJDK — Techzine Global
- The staging area is a "gym" for developer growth—don't make it a dumping ground for AI output! — gihyo.jp
- Linux’s Staging Area To Now Reject LLM-Generated Patches, Except For Real Security Fixes — Phoronix
- Five Rust project teams permit LLM analysis and verification for rust-lang/rust contributions, strictly restrict creation — gihyo.jp
