When Oracle banned AI-generated code from OpenJDK contributions, it was easy to read as another round of anti-AI panic. A giant tech company slamming the door on the tools everyone else is racing to adopt. I do not read it that way, and I am probably not who you expect to be defending the ban.
I built this entire site, desaputro.com, with AI doing most of the typing. Go backend, React frontend, AWS infrastructure, the lot. I am not an AI skeptic. I use these tools every day and they have changed how I work. And I still do not merge a single line of AI-generated code that I have not read and understood myself. Those two facts are not in tension. They are the whole point.
The reason is not that AI writes bad code. Most of the time it writes code that looks completely correct. The danger is the code that looks correct and is quietly wrong in a way no quick glance, and sometimes no unit test, will catch.
Here is a real one from this site. I asked an AI agent to add an advertising settings feature to the admin panel. It touched every layer you would expect: the frontend form, the API handler, the validation, the storage. The unit tests passed. The UI worked. I saved a change and got a clean 200 response back. Everything looked fine.
Nothing was being saved.
The bug was one missing field on the request the server binds incoming JSON into. Simplified, it looked like this:
type UpdateSiteSettingsRequest struct {
Pages PagesContent `json:"pages"`
Assets SiteAssets `json:"assets"`
// the new Ads field was never added here
}Because the Ads field was not on that struct, the server's JSON binding silently threw away the ads part of every request before the handler ever saw it. The save then merged the old data back over itself and reported success. The API returned 200 and dropped the change on the floor, with no error anywhere.
It got worse. The validation that was supposed to reject dangerous input, like a javascript: link in an ad URL, never ran on the ads data, because the data was gone before validation happened. So a malicious value would have sailed straight through, not because the validator was wrong, but because the thing it was meant to check had already been discarded upstream.
The unit tests were green the entire time. They tested the pieces the AI wrote, not the seam between them. I only found the bug by ignoring the tests and driving the live API by hand, watching a save succeed and then reloading to see my change gone.
That is the maintainer's nightmare, and I hit it on a personal project I own end to end. I caught it because I wrote nothing off. I read the diff, I did not trust the green checkmark, and I tested against reality instead of against the tests. On my own repo, with my own eyes on every layer, that is manageable.
Now multiply it. Imagine you maintain OpenJDK, and instead of one careful author reviewing one AI change, you get a flood of drive-by pull requests from contributors who generated code they do not fully understand, aimed at infrastructure that millions of applications depend on. Reviewing code you did not write takes far more energy than writing it, and AI has made writing it nearly free. The submitter feels productive. The entire cost lands on the maintainer, who never agreed to absorb it.
That is the line Oracle is actually drawing. Not AI versus no AI. It is about who reviewed the code and who is accountable for it. On a personal project, the author is the reviewer, and the buck stops in one place. On shared infrastructure, unreviewed AI code quietly transfers an unbounded review burden onto people who did not choose it, and attaches it to systems that cannot afford a quiet 200-that-saves-nothing bug.
There is also the provenance question underneath it. When a human writes a function, the chain of custody on that code is clear. When a model emits fifty lines, nobody can easily prove it was not memorized from a repository with a license that does not allow it. For a personal site that is a small risk. For the Java platform it is a legal liability spread across every company that ships on top of it.
So this is how I actually work, and I think it is the honest version of using AI well. Every AI-generated change goes through the same gate a human pull request would. I read it. I ask what it does at the boundaries, not just in the happy path. I check that the tests test the right thing rather than just passing. And I run it against something real before I believe it. The AI writes. I am still the one accountable for what ships.
Oracle did not draw a line against AI. It drew a line under a rule that never changed, even as the tools did: a human owns the code, not the tool that typed it.