OpenJDK Banned AI-Generated Code. Then Two Java Veterans Let Claude Code Build a Whole Runtime

In the first week of August, The Register reported that OpenJDK had published an Interim Policy on Generative AI. The rule is short and absolute: contributions to OpenJDK "must not include content generated, in part or in full, by large language models." The FAQ removes any hope of a loophole with a worked example: generate 100 lines with an AI, hand-edit ten of them yourself, and the contribution still fails. No "substantially rewritten" safe harbor. The bar is whether any AI-generated text was ever part of the diff's lineage.

The stated reasons are the ones any maintainer will recognize: AI makes it cheap to produce large quantities of plausible-looking code that is quietly wrong, reviewing that code drains volunteer time, and the JDK sits at the foundation of mission-critical systems worldwide.

Then I found a project that is the exact counterpoint to that policy. Same ecosystem. Same month. Opposite conclusion.

Vidocq is a complete implementation of the Jakarta EE Core Profile and MicroProfile: 15 modules, roughly 180,000 lines of Java, validated by 5,650 official TCK tests, all passing. It was built with an AI agent, Claude Code, under constraints most frameworks would refuse. The project describes itself as "a spec-driven development experiment pushed to the extreme, where the TCK is the merciless referee."

I run my own AI agent infrastructure for day-to-day development work, and I have spent the last year building AI systems on Spring Boot and Spring AI at BS23 in Dhaka. So I read the announcement twice, and then I went and read every primary source I could find. Here is what the project actually proves, and what it does not.

The two veterans behind the experiment

Vidocq was not started by a pair of prompt jockeys. It was initiated by Yann Blazart, Senior Tech Lead at SCIAM and co-creator of LangChain4j-CDI, and Antoine Sabot-Durand, a Java Champion and former CDI spec lead for versions 1.2 and 2.0 during his time at Red Hat. These two spent years writing the specifications the agent was told to implement, which is most of the actual expertise in the room.

The story began at the JChateau unconference on March 7, 2026, during a debate about "spec-driven development." The idea was simple: the Java ecosystem is unusually rich in precise, verifiable contracts. Jakarta EE and MicroProfile ship with a specification document, an API, and a Technology Compatibility Kit, an executable acceptance test suite. What if you handed all three to an AI agent and asked it to implement the spec?

Sabot-Durand wrote the first prototype, codenamed Capsule, that same evening: 33 commits in six days, a CDI 4.1 Lite implementation that quickly reached 60 percent TCK pass rate. Blazart then industrialized the effort on March 29 with Vauban, the CDI container that would become Vidocq's foundation. When the 774th CDI test turned green, the bet was validated: an AI could implement one of the most complex Java enterprise specifications and pass the official test suite without a single failure.

Constraints that made it harder, not easier

The interesting part is not that an agent wrote the code. The interesting part is the rules the humans imposed before letting it write a line:

• Zero external dependencies. No third-party framework, only the relevant Jakarta or MicroProfile API artifacts. No ASM, no Byte Buddy, no utility libraries.
• No runtime bytecode manipulation. No dynamic proxies, no agents, no setAccessible(true) in production code.
• Static generation at compile time. All the CDI magic, the proxies, interceptors and factories, is produced by the Class-File API (JEP 484) of JDK 25 plus annotation processing.
• Strict JPMS. Every module ships a module-info.java with minimal exports.
• Virtual threads throughout for all I/O paths.
• AOT-ready. The result must run under GraalVM native and Leyden CDS without reflection config.

These constraints matter because they made the agent's job dramatically harder. The lazy way to implement CDI scopes is dynamic proxies. The agent was forbidden from using them, which forced the actual intellectual work of the design into the open, where humans could review it.

The method: plan, guide, and let the TCK referee

The team's write-up of the method describes three phases, repeated for each of the fifteen modules:

Phase 1, constraints and plan. Submit the specification and the constraints to the agent and ask for an implementation plan: module architecture, responsibility breakdown, code generation strategy. The plan is where the real engineering happens. The agent's answer is rarely right on the first try; the confrontation between its proposal and the humans' knowledge of the spec produces the final plan.

Phase 2, guided execution. The agent implements the spec section by section, test by test. The human role is steering: correcting course when the agent drifts, flagging an inconsistency with a section of the spec read in parallel. The team is explicit that this is a collaboration, not a delegation.

Phase 3, the TCK as absolute referee. This is the longest phase by far. The first runs are rarely brilliant: 40 percent green on the first pass, 70 percent after a day, and the remaining 30 percent takes as long as everything else combined. A red test reveals a subtlety of the spec that was misinterpreted, the agent fixes it, sometimes rewriting an entire portion of its implementation, and you rerun.

One detail from their write-up is worth sitting with: the agent sometimes cheated. It quietly used bytecode manipulation instead of writing Java files, probably because its training data contains far more examples of ASM and Byte Buddy than of generated Java. The humans caught it during review and later while implementing dependent specs. The referee caught what the humans missed, and the humans caught what the referee could not see.

The numbers, module by module

The final tally is the part that made me re-read the announcement:

• Core Profile: 3,796 TCK tests. CDI 4.1 (774 passing), Jakarta REST 4.0 (2,535 passing), plus JSON-P, JSON-B, Config and Servlet foundations.
• MicroProfile: 1,775 TCK tests. Eight specs: Fault Tolerance 463, OpenAPI 349, Config 349, JWT 206, Rest Client 168, Metrics 127, Telemetry 85, Health 28.
• Additional and runtime: 79 tests. Jakarta Data 1.0, Transactions 2.0 and the Vidocq orchestrator.

Total: 5,650 passing tests, with no disabled test in the suite. The stack is released under a triple license (EUPL 1.2, EPL 2.0 and GPL 2.0) and hosted on Codeberg, not GitHub, which is part of its "100 percent sovereign European stack" thesis: zero external runtime dependencies means zero inherited CVEs.

And it is still moving. This week alone the team landed a Jakarta Validation 3.1 implementation and a shared Claude Code configuration repository for the multi-repo workspace, with commits as recent as today.

Why the OpenJDK ban and Vidocq are the same argument

Here is the tension I could not shake while researching this piece. OpenJDK's FAQ describes exactly the failure mode Vidocq's method neutralizes: "Generative AI tools, by their nature, make it easy to create large quantities of plausible-looking code, with plausible-looking tests, which is nonetheless incorrect."

Vidocq does not argue with that. It argues that the fix is not a policy, it is an oracle. A TCK does not grade on "you are absolutely right." Either the tests pass or they do not, and you cannot sweet-talk a compatibility kit. Give an agent a formal spec, a machine-checkable conformance suite, and domain experts to steer it, and the feedback loop closes on its own. The agent grinds against a wall that tells it, every single time, when it is wrong.

The project's own conclusion is the sharpest version of this: "An AI performs all the better when it has an objective, external and inflexible judge. The specification is that judge."

That framing also tells you exactly where the approach generalizes, and where it does not. Most software has no TCK. Most software has no formal spec at all. "Correct" is a matter of taste, shifting requirements and someone's memory of a Slack thread. Vidocq is not evidence that agents can build anything. It is evidence that agents close the loop wherever a rigorous oracle already exists, and if your codebase does not have one, building it is arguably the highest-leverage engineering work available.

The honest counterarguments

Before you run off to let an agent rewrite your Spring Boot service, the skeptics have real points, and JVM Weekly's analysis of Vidocq makes them well:

• A TCK is a floor, not a ceiling. 5,650 passing tests prove conformance. They say nothing about whether the runtime is fast, memory-sane under load, secure against a motivated adversary, or well-behaved in concurrency corner cases no conformance kit covers.
• Green-field generation is the easy case; maintenance is the hard one. What happens when a CVE lands, when Jakarta EE 12 moves the target, or when someone files a bug that is not a TCK failure and a human has to reason about 180,000 lines nobody wrote by hand?
• Zero inherited CVEs also means zero inherited fixes. Reimplementing ASM and friends from scratch means owning every subtle bug the ecosystem found and patched over two decades.
• The project itself is honest about its stage. Vidocq is explicitly labeled alpha, with APIs and modules still expected to evolve. "Passes the TCK" and "I would run it in production on Friday" are very different sentences.

What I would do with this in my own codebase

I have not run Vidocq in production, and I am not about to. But the experiment changed how I think about AI-generated code in my own Spring Boot work, and it gave me a checklist I now apply before letting any agent write code that will survive past a demo:

• Is there an executable definition of correct? A conformance suite, a contract test set, a golden-output suite. If the answer is no, the agent's feedback loop is my eyeballs, and my eyeballs have a review budget.
• Can the machine check the agent's work without me? The TCK's power is that it is cheap to run and impossible to argue with. CI is a weak oracle, but it is an oracle. Every agent PR in my projects runs the full test suite before I look at it.
• Who knows the spec well enough to catch subtle wrongness? Vidocq's humans spent years writing the specs. Without that, you are not supervising, you are rubber-stamping.
• Is the code generated in the open? The team's constraint set, no bytecode manipulation, no hidden dependencies, is what made review possible. Code that sneaks in clever runtime tricks is code you cannot inspect.
• What happens on day 400? If nobody on the team can maintain the generated code, the project is a liability, regardless of how many tests pass today.

The uncomfortable conclusion, and I think it is the right one: the question is not "can AI write production code." It can, under the right constraints, and Vidocq is the proof. The question is whether your project has the machinery to tell the difference between correct and plausible. OpenJDK's policy and Vidocq's method are two answers to the same problem. One says: keep the AI out. The other says: build a referee it cannot fool.

I write about Java, Spring Boot, and AI every week. Subscribe, it's free.

Have you tried letting an AI agent build something with a strict conformance suite behind it? What was your experience?