JetBrains Compiles Maven-Style Build Logic Into a Neural Network's Weights

Decision logic as weights, not a trained guess

The project, described by Denis Shiryaev on the JetBrains AI blog, does not train a model to predict what Maven usually does next. JetBrains argues that such a model is right most of the time, and "a build tool that is right most of the time is broken." Instead, the team wanted the decision logic itself in the weights, so the network either gives the exact answer or refuses to answer.

The approach comes from Handwired: write a program, then set a network's weights so the network is that program. The team wrote a small Maven-compatible build controller in a restricted subset of Python and compiled it into a table of 29,625 × 7 numbers, plus 7,382 cells of constants. This is the first version, called v1. There was no training and no gradient descent, with zero optimizer steps.

At run time the network looks up one row of its table per step using two matrix multiplications, does the arithmetic that row encodes on a small register file, and writes the result to memory. It cannot open files or start javac. For that, it writes a request into a fixed memory slot, and a thin bridge carries it out and returns the raw answer. According to JetBrains, the bridge never decides anything.

Byte-identical JARs on ZXing 3.5.3

The test subject was the ZXing 3.5.3 barcode library: its parent project plus the core and javase modules, built with clean package and tests enabled. JetBrains says the JARs match Apache Maven's byte for byte. The build ran in a sandbox where Maven cannot run, the network is off, and neither the Python version of the logic nor Maven's outputs can be read.

• All 549 upstream tests ran and passed.
• The built JARs encoded and decoded QR codes correctly in 27 of 27 checks.
• 519 hand-written build cases passed, each checked against real Maven.
• 10,000 generated project cases passed.
• 33 other small projects built correctly with the same weights.

One full ZXing build took 4,796,191 network steps. Two checks, according to the team, show the work happens in the weights: CPU and GPU versions made exactly the same 1,731 requests in the same order, and deleting or corrupting the weight file meant no build happened.

The cost: slower in every scenario

JetBrains is open that the network is slower in every scenario measured. Each tiny instruction costs a full round of matrix arithmetic. A clean build with tests took 1.49× as long as the Python version (95% interval 1.4× to 1.54×, 30 paired runs). Median times were 15.52 s for Python, 23.12 s for the network on CPU, 70.11 s on GPU (Metal) and 15.29 s for Apache Maven 3.9.11.

On decisions alone the gap is much larger: 146.54 ms for Python against 4.15 s for the CPU network, or 28.3×. In a whole build the gap shrinks because most time goes to javac and JUnit, which both versions share. Running on the GPU made things worse, since an instruction-by-instruction program gives a GPU nothing to parallelize.

A cheaper compiler, not a different network

The team counted where steps went. Of v1's 4,796,191 steps, 652,773 (14%) only copied a value between registers, and 553,333 more (12%) loaded a constant or jumped to the top of a loop. JetBrains calls this compiler glue and fixed the compiler rather than the network.

The resulting v2 model (nmvn-exact-v2) needs 3,676,728 steps for a full ZXing build, 23% fewer, and its weight table shrinks 10% to 26,626 rows. It makes the same 1,731 requests in the same order and passes the same correctness gates, including byte-identical JARs. The clean build with tests fell from 23.12 s to 21.09 s on CPU, a ratio of 1.42× to Python (95% CI 1.40× to 1.43×). Decisions alone dropped to 3.40 s. On GPU, decisions only fell from 27.97 s to 21.61 s, which is still the slowest engine.

A maze solver and what it means

To check the compiler is not tuned to one program, JetBrains compiled a breadth-first-search maze solver into 279 rows of weights. On three different 171×121 mazes, plain Python, a debug shim, and the neural CPU and GPU runs produced identical event sequences. The first maze took 2,572,288 network steps. The neural CPU run took 161× to 168× as long as plain Python, and the GPU 791× to 812×, though JetBrains calls these figures rough.

The company's conclusion is plain: for a faster build, keep using Maven, and a bigger GPU will not help because nothing in a build controller can be spread across thousands of cores. In its words, this is "not a faster build tool" but one "you can hold as a tensor." The demonstration shows that exact, rule-based software logic can run inside a network's weights, even if speed was not the point.