Compile by Training Turns Natural-Language Specs into Local Neural Functions

Introduction

Many text functions are easy to explain but awkward to implement with deterministic rules. A developer can repeatedly call a large remote model, but that brings recurring latency, usage cost, and dependence on an external provider. The alternative is to build and maintain a separate implementation for every task. Compile by Training explores a middle ground: turn a natural-language specification into a reusable neural function that can run locally.

How the compilation process works

The method builds on Program-as-Weights, or PAW. PAW compiles a description of a function into a small neural program that runs on a shared 0.6B local interpreter. Its original fast compiler performs the conversion in a single forward pass and can finish in seconds.

Compile by Training adds a higher-accuracy path with three main stages:

• Read the user’s natural-language specification;
• Ask teacher models to synthesize task-specific input-output examples at compile time;
• Use those examples to fine-tune a lightweight adapter for the compact interpreter.

After compilation, the teacher models are no longer required for each request. The resulting PAW program can run locally and can be stored, versioned, and composed in a way that resembles ordinary software functions. Demonstrations include an English-to-“Claudish” translator, a natural-language controller for a live 3D avatar, and a local tool for detecting and masking personal information.

Trading compilation time for accuracy

On a hard subset of FuzzyBench, the fast PAW compiler did not produce exact matches, while Compile by Training reached 83.6% semantic accuracy. The result suggests that task-specific synthetic examples and adapter training can help when a one-pass transformation struggles with ambiguous or complex specifications.

The improvement comes with a clear trade-off. The fast compiler completes in seconds, whereas the training-based mode takes roughly a minute. The extra expense is paid during compilation rather than on every inference call. Once the function has been produced, it can operate without the teacher models, potentially reducing repeated remote-model latency and cost. That makes the approach more relevant for functions that will be called frequently, need local execution, or should avoid a permanent dependency on a model provider.

The coverage problem

Teacher-generated data is also the method’s main boundary. A compiled function can only learn from the cases represented in its compilation examples. Rare inputs, edge cases, and out-of-distribution behavior may therefore remain weakly covered. A system intended for production would need regression tests and evaluation sets beyond the synthesized examples.

Versioning introduces a related question. When a natural-language specification changes, recompilation should produce behavior aligned with the new requirement, but that alignment needs to be checked rather than assumed. Comparing old and new compiled functions could become an important part of deployment workflows.

The broader significance of Compile by Training is not that a small model universally replaces a large one. Instead, it proposes a way to manufacture small, local tools on demand: pay a one-time compilation cost, then reuse the resulting function. This shifts attention from per-request model calls toward compilation quality, example coverage, testing, and version control.

Source: Hugging Face Daily Papers