A Language Model Designs Better Algorithms When It Is Fenced In

Ask a large language model to write an algorithm for a scheduling problem and you will usually get something that looks right. The code is confident, the comments are tidy, and then it crashes, or it hands back a landing order that puts two aircraft on the runway at once. The failure is not subtle reasoning; nothing in the loop knew what a legal answer looked like.

That is the gap a framework called LACE goes after, and it goes after it from the outside. Huatian Gong, Ran Yan and three colleagues, at universities in Singapore, Hong Kong, Liverpool and Taipei, reported it in Nature Machine Intelligence on Oct. 1, 2026. Almost all of their engineering went into the fence around the model, not the model inside it.

The fence is what the authors call a problem contract, and it has four parts. A loader turns raw instance files into data the code can use. A schema fixes what a solution has to look like. A feasibility test says whether a proposed solution breaks a rule. An objective function scores it. The last two are the interesting ones, because the language model writes those as well, from the problem's description in plain words. A module is accepted only after a real model-written heuristic has run end to end through it and produced a feasible, scored solution. The system tries to repair one that cannot, and discards the contract if the repair fails.

The paper's own name for the result is a "verified problem contract," and it is worth being exact about what that verifies. It verifies that the pieces fit: the schemas parse, the checks run, and at least one real heuristic has made it through the whole chain. It does not verify that the feasibility test encodes the actual rules of the problem, because that test is itself machine-written, and the only check on it is that it runs. The authors say as much in the guide they published with the code: semantic correctness for a brand-new problem "ultimately rests on the description and human review." What the contract buys is a filter that catches the garbage an unfenced model emits, which is a real engineering result and not a proof about the heuristics it lets through.

What the top score is measured against

The headline comparison runs on CO-Bench, a public suite of 36 real-world combinatorial problems (scheduling, routing, packing) assembled at Carnegie Mellon, which matters mainly because the authors did not build it. The team reports an average score of 0.945 there, against 0.870 for the strongest existing language-model method and 0.571 for prompting a model directly with no framework at all. That spread is the paper's own argument for the fence: most of the distance sits in the scaffolding, not in the model.

The number needs reading. It is a normalized gap-style score, where the top of the scale is the best published solution for an instance, so it is not a percentage of correct answers and not a share of optimal. And it is a portfolio figure: ten evolved heuristics are run on each instance and the best result counts, which is not one algorithm's score. Whether the competing systems received a comparable compute budget per instance is not settled by anything in the open material. Every system in that comparison is another language-model pipeline, not one of the operations-research solvers a practitioner reaches for first.

One comparison can be rechecked from the shipped files, and it is the most informative one. On 16 classic traveling-salesman instances from TSPLIB, a standard public test set, both sides got ten seconds per instance. LACE's routes came within 1.36% of the known optimum on average, against 3.91% for a rival language-model framework, and it was ahead on all but one, where the two tied. On the largest instance, it was 10.47% off, a margin a specialized solver such as LKH would close without effort. That pair is the honest picture: a competent automatically written local search, not a replacement for a tuned solver.

The portfolio idea is not the new part

Combining heuristics that fail in different places is older than this work, and the paper says so. Its own reference list credits EoH-S, presented at AAAI in 2026, which already used a language model to design a small complementary set, so that at least one member handles every instance well. What LACE adds is the contract and the sheer spread: 7,109 instances across 40 problems, against three problem families in that predecessor.

The complementarity is demonstrated rather than asserted. The authors plot average score against portfolio size from one heuristic up to ten, and it keeps climbing: the tenth member still covers instances the first nine handled worse. The selection step aims at exactly that, choosing the ten to minimize the average rank of whichever member covers each instance best.

Four problems with no answer key

The other half of the evaluation is four problems the team formulated itself, drawn from port and container-terminal logistics, which is also its home field. LACE scores 0.97 to 0.99 on them, and five existing language-model baselines produced no feasible algorithm at all. That second result is the one worth keeping: not a margin, but the difference between an answer and nothing usable. No published optimum exists for these four problems, so those scores are not a distance from a known best answer.

Those four are also where the framework's transfer claim lives, and it is narrower than it first sounds. What moves to a new problem untouched is the framework: no re-tuning, no per-problem human engineering. The heuristics do not move. For each new problem, they were evolved from scratch on 128 training instances and then scored on 100 held-out test instances. That is a genuine evaluation, and a different claim from solving a problem the system has never encountered.

The most checkable thing about this paper is not in the paper. The framework code, every instance and every heuristic program LACE evolved are open under the MIT license on GitHub and archived on Zenodo. So is every per-instance result, alongside an interactive supplementary page and a notebook that reruns a portfolio in a browser. The team reports that all 40 problems ran end to end from a clean checkout, with one falling short of a perfect feasibility rate on its test instances. That is the team's own run and not an outside group's, which is precisely why the files matter. The authors' own conclusion is scoped to fit: for problems of this kind, algorithm discovery can be automated to a substantial degree.