Can LLMs Design Operations Research Algorithms? A Paper Pushes Algorithm Design Past a Critical Point

An Uncomfortable Question

Imagine you are a warehouse manager. Every Monday you decide how much stock to order. Order too little and you pay stockout penalties; order too much and you pay holding costs. Demand is random, supply is delayed — you are always gambling.

Operations research (OR) has spent sixty years on such inventory control problems: from base-stock policies in the 1960s, to capped base-stock policies, to a 2022 A3C deep reinforcement learning approach. Every step required human researchers to write new algorithms, tune hyperparameters, and validate results. One A3C hyperparameter configuration takes 24 CPU hours; automatic tuning tries 250 configurations — roughly 6000 CPU hours — and yields a black-box neural network whose decisions you cannot explain.

Now someone asks: can an LLM do this directly?

Not "solve today's instance" — but write an algorithm: given a problem description and parameter ranges, the LLM returns Python code implementing a policy reusable across all instances.

A 2026 paper by Jackie Baek (NYU Stern, arXiv: 2608.27296) says yes — and the results beat the best human-designed methods.

Two Levels of Testing

• Level 1: Given a concrete instance (e.g., demand mean 20, lead time 8, stockout penalty 5), return the solution. Like solving one exam problem.
• Level 2: Given only the problem-class description and parameter ranges ("lost-sales inventory, Poisson demand, lead times 1–12"), return an algorithm — code that takes any parameters and outputs a solution. Like writing a program that solves the whole exam.

Human input is minimal: one untuned prompt, a Python sandbox, and a 3600-second compute budget. No few-shot examples, no chain-of-thought scaffolding, no per-problem prompt engineering.

Three Battlegrounds

1. Lost-sales inventory control — OR's "Hello World," with many human-designed baselines. 2. Queueing network control — multi-server, multi-class scheduling with finite buffers; core to cloud scheduling and ER triage. 3. Assortment optimization — which products to offer for maximum revenue; the backbone of e-commerce and retail shelf management.

Results in One Table

Using gpt-5.6-sol (released mid-2026), across all ten problem classes:

| Metric | Result | |--------|--------| | Level 1 (per-instance) | 23 of 26 lost-sales instances beat the best tuned benchmark; remaining 3 within 0.5% | | Level 2 (write an algorithm) | One algorithm across 26 instances: 21 beat the best benchmark, all within 0.5% | | MMNL assortment | Level 2 algorithm achieves exact optimality on all 628 instances | | Constrained MMNL | Matches the best method on all 1794 instances | | Queueing networks | Matches or beats the best heuristics on multiple network classes |

One LLM, one prompt, one call, one hour of sandbox compute — matching or exceeding sixty years of the best specialized human algorithms.

A3C vs. LLM: Black Box vs. Readable Code

A3C (Gijsbrechts et al., *Management Science*, 2022) is a state-of-the-art deep RL method for lost-sales inventory:

| Dimension | A3C | LLM Level 2 | |-----------|-----|-------------| | Compute | 24 CPU-hrs × 250 configs ≈ 6000 CPU hours | 1 hour sandbox | | Output | Black-box neural policy | Readable, inspectable Python code | | Generality | Per-instance training, no cross-instance transfer | One algorithm for the whole problem class | | Lost-sales performance | Mostly matches strong heuristics | Beats the best benchmark at all lead times |

A3C is a Level 1 method. The LLM's Level 2 does more, at far lower cost — and its output can be read, modified, and debugged.

What Do the LLM's Algorithms Look Like?

The most surprising finding: the LLM's algorithms have recognizable structure.

• Inventory control: gpt-5.6-sol's Level 2 algorithm is a "projected inventory policy" — it keeps the capped base-stock structure (order-up-to + order cap) but replaces the raw inventory position with a projected, risk-adjusted inventory statistic, approximating the distribution of pipeline inventory: exact Poisson moments for the first step, normal approximation thereafter, with parameters tuned via coarse-to-fine simulation search. Capped base-stock is a human idea from 2013; the LLM recombined it with projected inventory position concepts and added a key twist — substituting the risk-adjusted statistic.
• Queueing networks: dynamic programming on small state spaces, pressure-based scheduling rules on large networks — a classic queueing-theory idea the LLM chose itself.
• Assortment optimization: standard OR primitives — relaxation, rounding, repair, local improvement, occasional exact solves of small subproblems.

The paper's own words: the generated algorithms "are not mysterious black boxes. They are often variants and combinations of familiar OR ideas, including capped base-stock policies, small-state dynamic programming, pressure-based scheduling rules, and local search."

A Capability Gradient Within Eight Months

Four models, all released within eight months:

• gpt-5.1 (2025-11-13) — weak at Level 1, worse at Level 2
• gpt-5.4 (2026-03-05) — Level 1 near-benchmark, Level 2 never exceeds
• claude-fable-5 (Anthropic) — strong Level 1, reliable but weaker Level 2
• gpt-5.6-sol — exceeds benchmarks at both levels

The paper concludes: "LLM algorithm design capability is moving fast; frontier LLMs are becoming a natural empirical baseline for hard OR problems."

Two Key Objections, and the Paper's Answers

1. Data contamination? A holdout test ran the frozen Level 2 code (no new model calls) on newly constructed instances — different demand means, penalties, lead-time ranges. gpt-5.6-sol continued to beat the best benchmark on all holdout instances. Memorized answers would not transfer.

2. Did it rely on web search? With unrestricted web-search access, the model only did a brief literature check at the start, or none at all. The final algorithms and results were completely unchanged. "Retrieval is not the binding constraint for these runs."

How the LLM "Thinks" About Algorithm Design

Appendix G records a stable six-step pattern in Level 2 reasoning:

1. Formalize the problem, recall known structure ("considering the revenue-order theorem… globally optimal for MNL, but different for nested logit") 2. Enumerate candidate method families, weigh exactness vs. cost 3. Budget the 3600-second compute allocation 4. Build a testbed, validate against ground-truth benchmarks on small instances 5. Find failure modes, add guardrails ("don't order when the effective penalty is non-positive; order to capacity when holding is free and demand exceeds the cap") 6. Format output to the contract

This is the standard workflow of a human OR researcher. The LLM is not reciting answers — it is following the process.

What This Means

For OR researchers: the paper is measured — "these results do not mean LLMs replace algorithmic research." But: "once a problem class has a rich body of algorithmic knowledge, frontier LLMs may be able to recombine it into a working solver at minimal cost." The value center of OR research may shift from *designing* algorithms to defining problems, validating algorithms, and judging objectives.

For AI engineers: the Level 1 vs. Level 2 distinction is a valuable capability-probing methodology — many tasks LLMs "can't do" at Level 1 become feasible at Level 2 (write a program that handles the whole task class).

For everyone: A3C spent 6000 CPU hours to produce a black box; the LLM spent 1 hour to produce readable code that performs better. Before reaching for deep RL, ask: could an LLM just write the algorithm?

Knowledge Recombination vs. Knowledge Creation

The paper's key sentence — "the generated algorithms are often variants and combinations of familiar OR ideas" — admits two readings:

• Pessimistic: LLMs only recombine existing knowledge; no genuine originality.
• Optimistic: recombination is itself a form of creation. The "projected inventory statistic" policy was not a human-written algorithm. If the combination were obvious, humans would have done it already.

The deeper insight: the more knowledge a field has accumulated, the better LLMs can recombine it. Sixty years of OR literature is the LLM's raw material. A simple heuristic for LLM capability boundaries: *does this field have rich public literature?* If yes, LLMs may succeed; if no, they start from scratch, just as hard as humans. The truly "LLM-proof" domains are not the hardest ones, but the under-documented ones — a better predictor than "task difficulty."

Closing: An Uncomfortable Analogy

When Deep Blue beat Kasparov in 1997, chess said "that's just brute-force search, not real intelligence." Twenty years later, AlphaZero learned from scratch, and chess said "*that's* real intelligence."

A3C's black-box neural network was hailed as a milestone of AI solving OR. What will OR say when an LLM writes better-performing readable code in one hour?

If history rhymes: deny, accept, then redefine what counts as "real intelligence."

But this time is different: the LLM's output is not a black box — it is code you can read, modify, and understand. When AI's output becomes an inspectable engineering artifact, the "just brute-force search" comfort stops working — because you can see exactly how it thinks.

Paper: https://arxiv.org/abs/2608.27296 Code and full logs: https://anonymous.4open.science/r/llm-or-algorithms-F9F2