Compile by Training: Turning Natural-Language Specifications into Local Neural Functions

Compile by Training. Turning Natural-Language Specifications into Local Neural Functions. By Yuntian Deng and two others, from the University of Waterloo and Harvard University. Published on the third of September. No code repository is linked to it.

There is a class of text function that is easy to describe and hard to implement. You can say what you want in a sentence, but writing rules that do it reliably is painful or impossible. The usual answer is to call a large remote model every time the function runs, and that answer carries three costs that never go away: you pay again on every input, you wait again on every input, and you depend on a provider staying available and unchanged.

Compile by training treats the specification the way a compiler treats source code. You write what you want in natural language, and what comes back is a reusable neural function rather than a running conversation with a large model. The word compile is doing real work in that sentence. The cost moves to compile time and is paid once, and the artifact you get can be stored, versioned and composed like ordinary software.

At compile time, teacher models generate task-specific examples for the described task. Those examples train a small adapter for a compact interpreter. The resulting function then runs without the teachers involved at all, which is what removes the per-input cost, the latency and the dependency in one move.

The test is FuzzyBench-Hard, chosen as a subset where the Program-as-Weights fast compiler produced no exact matches at all. Compile by training reaches eighty-three point six percent semantic accuracy on it. That accuracy is bought with compile-time cost: roughly a minute, against seconds for the fast compiler. The compiler runs in a public interactive service, with compiled functions demonstrated in a multi-site website helper, a language-controlled 3D avatar, and a bidirectional English-Claudish translator.

The trade is the whole point. A minute of compilation, once, against a remote call on every single input for as long as the function exists.

Compile by Training. Turning Natural-Language Specifications into Local Neural Functions. By Yuntian Deng and two others, from the University of Waterloo and Harvard University. Published on the third of September. This is the long version: the whole paper rather than the abstract.

Start with the example the paper starts with, because the whole argument sits inside it. You want a function that triages email. Given the subject line "Signature needed by EOD" it should return immediate. Given a newsletter it should return wait. That behaviour is easy to describe in a sentence, obviously useful across thousands of messages, and genuinely tedious to encode as rules. A remote language model does it well. But calling one for every message means paying, waiting, and depending on an external service, every single time, forever. The paper's observation is that an enormous number of text functions live exactly there: too fuzzy for conventional code, too narrow and too frequent to justify a large-model call on every invocation.

The proposal is to use large models once rather than always, and the word chosen for it is doing real work. Compile. A developer writes a natural-language specification, teacher models generate examples of the desired behaviour, and gradient descent uses those examples to specialize a compact interpreter. What comes out is an artifact that can be stored, versioned, cached and composed like ordinary software. In this framing, adaptation becomes a build step, and large language models become tool builders rather than run-time dependencies. The work sits on top of an existing system called Program-as-Weights, which introduced an amortized compiler that predicts a program in a single forward pass. That is fast, seconds rather than a minute, but it spends the same fixed amount of computation on every function regardless of how hard the function is.

Concretely it runs in two stages. First, one or more teacher models synthesize a task-specific dataset from the specification, returning structured JSON so that generated examples can enter the training pipeline automatically. The compiler validates each response and rejects malformed or incomplete batches before the trainer sees them. Second, those examples specialize the interpreter. Training a separate full model per specification would be prohibitive, so every program shares one frozen Qwen3 0.6B interpreter, and an individual function is represented by a small LoRA adapter plus a run-time scaffold, which is a compiler-generated prompt template encoding the user's free-form specification as structured instructions with a placeholder for the eventual input. The public configuration uses a quantized interpreter, mixed teachers, a rank sixty-four adapter, a warm start from the amortized compiler, and a one hundred step cosine schedule. Adapter, scaffold, original specification and interpreter metadata get packaged into a single artifact. One detail to hold onto: compilation is hosted, so the specification goes to the service and to teacher APIs, but local execution does not send your future inputs anywhere.

The benchmark is FuzzyBench-Hard, defined as the specifications on which the fast compiler produced no exact matches, which makes it adversarial by construction. The metric is LLM Exact Match, the fraction of predictions a judge considers semantically correct, chosen because two JSON outputs can carry identical values and differ only in whitespace or key order. The judge was validated at zero point nine seven seven accuracy against one hundred and twenty-eight author labels. Here the full paper adds something the abstract hides. The fast compiler scores zero point two two four on this set, not zero, because some of its predictions were semantically right while failing exact match. Compile by training reaches zero point eight three six.

Two controlled sweeps say more than the headline does, and they point in opposite directions. Changing who teaches matters a great deal: moving from a single small teacher to a mixture of a small and a large one lifts the mean from zero point seven four six to zero point eight five one. Changing how much they teach barely registers. Going from two thousand four hundred unique training pairs to three thousand six hundred moves the score not at all, and it takes seven thousand two hundred to buy roughly three more points. The composition of the supervision is doing the work, not its volume. On latency, a cold compile took fifty point nine seconds on the fastest hardware tested and ninety-nine point two on a consumer card. Composition was shown in a deployed website assistant carrying thirty compiled programs, twenty-eight of them live.

The authors are direct about the main one. Synthetic supervision may inherit teacher errors, so anything requiring guaranteed correctness should validate outputs or keep a deterministic control path. Their application evidence is about composition and structured execution, and systematic user studies remain future work.

What makes this more than a fine-tuning recipe is the interface it commits to. Compile, then run. If a neural function is versioned, cached and composed like ordinary software, then it can be reasoned about like ordinary software, and the large model moves out of your run-time dependency list and into your build tools.