If you use an AI coding agent, you know the feeling: the agent writes a hundred lines in a minute, and you spend the next hour deciding whether any of it is good. Now imagine maintaining a project that has been alive for three decades, where one bad patch can break real software for real companies, and AI-generated pull requests keep arriving anyway. That is the situation OpenJDK found itself in this week. Its new policy on AI-generated code started one of the most argued Hacker News threads this month.
What happened
On August 3, OpenJDK published an interim policy on generative AI. Contributions must not include content generated, in part or in full, by large language models. The rules are deliberately broad. If you generate 100 lines and then hand-edit ten of them, the contribution still counts as AI-generated. AI-powered IDE autocomplete is also banned: the FAQ allows spell-checking, grammar-checking, and refactoring tools only when they do not use LLMs.
The Hacker News thread exploded because of who issued the policy. Oracle funds most OpenJDK work and is one of the largest AI infrastructure investors in the world. Larry Ellison has told investors that future Oracle software will not be written by its own engineers. Banning AI-generated code from your flagship open-source project while telling the world AI replaces programmers does not survive contact with the front page.
The story reached 471 points and roughly 470 comments in under a day. Here is what developers actually argued.
“Rules for thee, not for me”
The dominant reaction was not that the policy is wrong, but that Oracle has no standing to announce it. The running joke was “rules for thee, not for me.” One commenter called the ban “the end of the kayfabe era” — a wrestling term for pretending a performance is real. Another invoked the classic: never get high on your own supply. The pattern they pointed to: Oracle sells AI infrastructure and AI-era layoffs, then keeps AI out of its own most visible open-source work. To many developers, that tells you exactly what these companies think of their own AI code.
A smaller group defended the policy. OpenJDK is a mature, stable codebase. Accepting LLM contributions creates a non-zero liability, and maintainer time is limited. They read the FAQ and noted it gives clear reasons: legal risk from unclear provenance, and review burden on human reviewers. Their counterpoint to the “kayfabe” crowd: the reasoning is sound even if the messenger is a large company.
The licensing theory
Dig past the jokes and the thread’s real consensus is that licensing, not quality, drove the decision. Several commenters argued that pure LLM output cannot be cleanly copyrighted by the human who prompted it, and OpenJDK requires contributors to assign rights — so the company will not accept contributions it cannot own. The details are genuinely contested: the US Copyright Office says a plain prompt alone may not be copyrightable, but human-edited output can qualify case-by-case, and commenters debated the edge cases at length. The bottom line for open source is the same either way: maintainers do not want to be the legal test case, so the LLM gate closes first.
The manager reports
The most uncomfortable part of the thread came from engineering managers. One manages teams that use agents daily, and described the moment his group started asking to dial AI back: after months of aggressive agent usage, developers were reporting “rapid erosion of their ability to maintain codebases that had started to spill over with slop.” The money quote: developers said they no longer knew how their own code worked, that it was massively bloated and unreadable, and they could not say with a straight face that they could maintain or fix it if it broke.
Someone else raised the same concern at work and shared the reply he got: “you need to engineer a better harness, maybe your AGENTS.md — that’s probably your problem.” In other words, apparently we are holding it wrong. Another commenter distilled the whole thing: “AI-generated code” is becoming shorthand for “code that was not verified and organized by a competent human.”
The counterpoint also showed up: one developer insisted his 2026 code is better than his 2025 code thanks to AI — better algorithms, better tests, better documentation — and argued the people getting garbage are the ones who never steer or review. That debate is unresolved in the thread, but both sides actually agree on the failure mode: unreviewed agent output.
Can the ban even be enforced?
A big chunk of the thread asked how anyone detects AI code at merge time. The OpenJDK FAQ itself lists tells: overly structured comments with multiple headings, unnecessary comments, a suspiciously cheerful tone, emoji. The running joke: strip the formatting, leave in a grammar mistake, and nobody can tell.
Others opened the door to the honest middle. Projects like Linux use a social layer instead of a detector: if the maintainers do not know you, they do not merge you. Under that model, AI contributions can be welcomed as long as a known human owns and defends the change in their own words — the approach Ghostty takes, requiring contributors to explain their change themselves. Enforcement ceases to be a detection problem and becomes a review-culture problem, which is where maintainers likely end.
What it means for you
If you contribute to open source: expect more projects to add AI-contribution policies — GCC and Linux already tag or restrict LLM contributions, and others will follow. The safe posture is also the engineering-sound one: you are the engineer of record. You sign the commit, you can explain every line, and the agent is scaffolding, not author. That passes nearly every policy being debated this week.
If you run a team: the biggest AI infrastructure investor on earth decided that unverified AI code is a legal and maintenance liability at the gate of its flagship project. That is a strong argument for writing an explicit AI-contribution policy of your own — not “ban AI” (your developers will, and should, keep using agents), but “a human must own, explain, and review every check-in before it lands.” The enforcement discussion in this thread shows what happens without that policy: the review queue becomes the slop filter by default.
If you are new to AI coding agents: do not read this thread as proof that agents are doomed. Read it as the community defining what it takes to keep them: the review burden is now the bottleneck, and every reviewer quoted in this thread says unreviewed agent output is the thing that breaks projects. Make yourself the “competent human” that the whole thread keeps invoking — steer the plan, review the diff, own the explanation — and the arguments here are all on your side.
The line that best sums up 470 comments of developer opinion: accept AI code if and only if a human can stand behind it. That is the standard Oracle just wrote down, and every team adopting agents will eventually meet it.