Should LLMs handle abstraction only in optimization?

If LLMs cannot reliably execute iterative numerical procedures, the design question becomes what they can reliably do in optimization workflows. The constraint-optimization paper's answer: keep them at the abstraction layer. Have the LLM read the structured input (grid topology, financial statement, threat model), understand the physics or domain, deduce the correct constraints, and write the mathematical formulation into solver code. Then hand off to the solver for the actual numeric matrix arithmetic.

The division of labor exploits the comparative advantage on both sides. LLMs are strong at natural-language-to-formal-structure translation, at picking the right variables and constraint forms from context, and at producing code that calls established libraries. They are weak at the iterative arithmetic that follows. Deterministic solvers (interior-point methods, primal-dual, branch-and-bound) are strong at the iterative arithmetic and weak at parsing the messy real-world problem statement. The architecture is the bridge.

This pattern recurs across domains. The same logic argues for neuro-symbolic approaches in general: LLM as translator from human problem to formal representation, symbolic engine as solver of the formal representation. The paper situates the constraint-optimization case within this family but argues the LLM should be restricted more aggressively than typical neuro-symbolic systems — not just translating but explicitly forbidden from attempting the numeric work.

For builders, the operational rule is: any task where the bottleneck is iterative computation should route through abstraction-only LLM use plus a solver, not through more capable LLMs or longer reasoning. Wrapping the LLM in a thinking budget is the wrong knob; wrapping it in a solver call is the right one.