Papers
Topics
Authors
Recent
Search
2000 character limit reached

LLM-Guided Program Evolution for Circle Packing: Breaking 10 Packomania Records for $28

Published 4 Sep 2026 in cs.AI | (2609.05093v1)

Abstract: We present Discovery Loop, a lightweight system that uses a LLM to iteratively evolve optimization algorithms. Starting from a simple seed solver, the LLM proposes algorithmic improvements guided by a scoreboard of results and a history of prior ideas. Each candidate is evaluated against an independent verifier; improvements are kept and failures discarded. Applied to the Packomania circle-packing benchmark (csqv: maximize the sum of radii of N variable-radius circles in the unit square), the system improved the best known solutions for 10 values of N in the range 101-114, with gains of 2.4%-5.4% over prior records, all within 15 iterations and at a total LLM cost of $27.72. These results have been independently accepted by Packomania. We describe the method, analyze cost-efficiency dynamics including an adaptive plateau-detection mechanism, and discuss implications for democratizing automated scientific discovery.

Authors (1)

Summary

  • The paper demonstrates Discovery Loop, an LLM-guided program evolution method that improved packing records at Packomania.
  • Discovery Loop operates with a single active champion and no explicit population.
  • For a consumer-grade setup and a budget of only $28, the method produced independently verified, substantial improvements in circle packing for 10 target values.

Problem setting and research objective

“LLM-Guided Program Evolution for Circle Packing: Breaking 10 Packomania Records for $28” presents Discovery Loop, a minimal framework for LLM-guided algorithm evolution applied to variable-radius circle packing (2609.05093). The paper investigates whether the central mechanism of systems such as AlphaEvolve and FunSearch can produce meaningful optimization advances without distributed infrastructure, population-based evolutionary control, or substantial computational expenditure.

The benchmark is the Packomania csqv problem: place $Ncircleswithvariableradiiinsidetheunitsquarewhilepreventingoverlapandmaximizingthesumofradii.Forcircle circles with variable radii inside the unit square while preventing overlap and maximizing the sum of radii. For circle i,withcenter, with center (x_i,y_i)andradius and radius r_i,feasibilityrequirescontainmentwithinthesquareandpairwiseseparationbyatleast, feasibility requires containment within the square and pairwise separation by at least r_i+r_j.Theobjectiveis. The objective is \sum_i r_i.Thisformulationishighlynonconvex,andeffectivesolversmustcombinecontinuousoptimizationofcoordinatesandradiiwithmechanismscapableofchangingthecombinatorialstructureofcontactsandlocalarrangements.</p><p>Theexperimentaltargetscomprisedtwelvevaluesof. This formulation is highly nonconvex, and effective solvers must combine continuous optimization of coordinates and radii with mechanisms capable of changing the combinatorial structure of contacts and local arrangements.</p> <p>The experimental targets comprised twelve values of N,includingteninstancesfrom, including ten instances from N=101to to 114andtwosmallerinstances, and two smaller instances, N=26and and i$0. The principal claim is that Discovery Loop improved the Packomania records for ten of these targets, with gains between $i$1 and $i$227.72. The resulting solutions were independently verified and accepted by Packomania.

Discovery Loop architecture

Discovery Loop contains a loop controller, a problem-specific plugin, and an initial seed solver. The controller maintains a current champion solver, per-target best results, a scoreboard, and a history of previously attempted ideas. At each iteration, the LLM receives the complete source code of the current champion, the problem formulation, target-wise scores, and the outcomes of recent attempts. It then produces a complete replacement solver together with an informal description of its proposed algorithmic change.

This full-replacement strategy is central to the design. Rather than requiring the model to produce a syntactically valid patch against an evolving codebase, the system asks for a self-contained solver that can alter the optimization architecture. The paper argues that this permits transitions between qualitatively different strategies, such as replacing random initialization with lattice-based initialization or introducing a specialized KKT polish stage.

Candidate solvers are evaluated independently on all targets, using six parallel workers and a timeout of 120 seconds per target. A candidate becomes the new champion only if its aggregate score exceeds that of the current champion. However, the system separately retains the best result observed for every target. This distinction prevents a solver that is globally inferior from eliminating a specialized result on a particular instance. It also acknowledges that a single solver may not dominate across all target sizes.

The initial solver combines multi-start penalty optimization using L-BFGS-B with linear-programming optimization of the radii. Subsequent proposals modify initialization, basin exploration, local polishing, and structural perturbation. The evolutionary state is therefore small: there is no explicit population, island archive, or multi-parent recombination at the meta-level. The system maintains one active champion and a textual history of attempts.

Independent verification and evaluation integrity

The verifier is deliberately separated from the solver. It checks square containment, pairwise non-overlap, and the independently recomputed objective value. It also applies a strict feasibility shrink intended to remove numerical artifacts arising from floating-point optimization. The paper describes the checker as operating with zero tolerance, which is important for a benchmark where small infeasibilities can otherwise produce apparently superior objective values.

This architecture addresses a central vulnerability of LLM-generated optimization code: the candidate program must not be able to exploit an evaluator that shares implementation assumptions or numerical shortcuts with the solver. Independent verification makes the reported records substantially more credible. It does not, however, establish global optimality. The results demonstrate feasible improvements over the Packomania records, which are best-known solutions rather than necessarily proven optima.

Record-breaking results

The strongest empirical result is the improvement on ten large instances. The gains are concentrated in the range ii3--ii4 and are consistently substantial relative to the prior records.

ii5 Prior record Discovery Loop Improvement
101 5.163845 5.289154 2.43%
102 5.055187 5.318238 5.20%
103 5.085509 5.345481 5.11%
105 5.125967 5.401298 5.37%
106 5.151736 5.429079 5.38%
107 5.180124 5.453952 5.29%
108 5.205806 5.481819 5.30%
109 5.231096 5.507926 5.29%
111 5.278427 5.554909 5.24%
114 5.336683 5.624188 5.39%

Aggregated over these ten targets, the prior-record sum increased from ii6 to ii7, a ii8 improvement. The two remaining targets, ii9 and (xi,yi)(x_i,y_i)0, matched or approached their prior records within (xi,yi)(x_i,y_i)1 but did not exceed them.

A significant qualification is that all ten record improvements were already obtained by the seed solver at iteration 0. The LLM-guided iterations therefore improved the aggregate objective after the system had already surpassed the listed records, but they were not responsible for initially breaking those ten records. This distinction matters for interpreting the headline claim: the experiment demonstrates the value of the complete pipeline, including the manually designed seed solver, while the incremental contribution of LLM evolution is reflected in later aggregate improvements rather than in the first record-breaking solutions.

Algorithmic proposals generated by the LLM

The candidate sequence contains several technically plausible modifications. The first accepted proposal introduced basin hopping around incumbent solutions, followed by SLSQP polishing on the resulting contact structure. This replaced purely cold-start exploration with exploitation of promising configurations.

A later candidate introduced hexagonal-lattice templates sized for the target number of circles. This proposal is particularly relevant to the geometry of dense packing because structured initial configurations can access regions of the search space unlikely to be reached by independent random initialization. The paper reports this as an architectural change rather than a parameter adjustment.

Other accepted proposals included island-model parallel basin hopping with elite migration, affine lattice template banks, a specialized KKT-Newton polish, lattice-aware slip moves, and defect-migration operators. Defect migration removes weak circles, allows the remaining configuration to re-equilibrate, and reinserts circles into newly available holes. Such an operator changes the contact graph and therefore addresses a limitation of local continuous optimization, which may be unable to cross structural barriers between distinct packing arrangements.

The paper characterizes these proposals as “genuine algorithmic innovations.” The claim is plausible in the narrow sense that the candidates introduce new search operators and solver components rather than merely changing scalar hyperparameters. Nevertheless, the experiment does not provide ablations isolating the causal contribution of each component. It is therefore not possible to determine from the reported results whether the improvements arise from individual innovations, interactions among them, longer computation, or stochastic variation in the underlying solver.

Iteration dynamics and cost efficiency

The system executed fifteen iterations before reaching the (xi,yi)(x_i,y_i)259.39(xi,yi)(x_i,y_i)359.98(xi,yi)(x_i,y_i)44.96(xi,yi)(x_i,y_i)50.57(xi,yi)(x_i,y_i)622.76(xi,yi)(x_i,y_i)70.02ofimprovement.</p><p>Thecorrespondingcostperunitofaggregateimprovementincreasedfromapproximately of improvement.</p> <p>The corresponding cost per unit of aggregate improvement increased from approximately (x_i,y_i)$8 in the early phase to approximately $(x_i,y_i)$9 in the later phase, a reported $r_i$0-fold deterioration. This result is one of the paper’s clearest operational findings. On a fixed set of targets, continuing LLM-guided search after the initial improvements can be economically irrational even when occasional candidates are accepted.

The paper implements a plateau detector using a four-iteration window. It stops when recent iterations contain no champion, no usable code, or less than $r_i$1 aggregate improvement. Backtesting against the observed run suggests that stopping after iteration 9 would have reduced expenditure from $r_i$213.95, a nominal saving of approximately $r_i$30.006$r_i40.01%40.01\% of the final value.

This result should be interpreted as retrospective rather than prospective evidence. The threshold and window were evaluated on the same trajectory used to motivate them, so the reported savings do not establish generalization to other problems, models, or random seeds. They nonetheless provide a concrete stopping heuristic for expensive program-search loops.

Comparison with larger program-evolution systems

Discovery Loop occupies a substantially smaller design point than AlphaEvolve and FunSearch. It uses one LLM call per iteration, local parallel evaluation, a single active champion, and full-program replacement. AlphaEvolve and FunSearch employ more elaborate evaluation and search infrastructure, including distributed execution and broader evolutionary control. The comparison therefore concerns accessibility rather than matched performance.

The reported cost of $27.72 and execution on a consumer machine are important engineering facts. They show that some forms of LLM-guided algorithm search can be conducted by an individual researcher without access to a cluster. However, the comparison does not establish that Discovery Loop achieves comparable algorithmic quality to those larger systems. The experiment uses one benchmark family, one model, one seed solver, and one trajectory. Cost and infrastructure requirements are therefore better supported than general claims about relative discovery capability.

The full-program replacement interface also creates a trade-off. It makes major architectural changes easy to express, but it discards potentially useful modularity and inheritance between candidates. A population-based system could preserve diverse solvers, recombine successful components, and reduce dependence on a single champion trajectory. Discovery Loop does not test whether its simplicity is advantageous beyond this specific setting.

Limitations and open questions

The evidence is limited to a single optimization domain whose formulation, evaluation procedure, and computational cost are unusually favorable to LLM-guided search. Circle packing has a compact mathematical description, candidate evaluation is parallelizable, and the solver can use standard numerical optimization libraries. The paper does not demonstrate comparable performance on problems with expensive evaluation, complex interfaces, discrete constraints, or difficult code-generation requirements.

Model dependence is also substantial. The experiment uses Claude Fable 5.1 through the Claude CLI, and the paper reports a separate MIPLIB experiment with a 75% code-generation failure rate. This observation directly qualifies the accessibility claim: low monetary cost does not imply reliable algorithm discovery when the target problem requires more complex or precise generated programs.

The experimental design lacks repeated runs, alternative LLMs, random-seed analysis, and controlled ablations. Consequently, the robustness of the improvements and the contribution of individual operators remain unresolved. The fact that the seed solver produced all ten record-breaking results further complicates attribution. A stronger evaluation would compare the seed and evolved solvers over repeated stochastic trials, report per-target distributions rather than only best outcomes, and evaluate candidates under matched computational budgets.

The plateau analysis also leaves an open methodological question. Its retrospective backtest suggests large savings, but the stopping rule was not validated online across independent runs. It remains unknown whether the same threshold would prematurely terminate searches whose improvements arrive intermittently or whose useful innovations require several consecutive unsuccessful proposals.

Finally, the system’s per-target best tracking produces a collection of specialized solutions rather than necessarily one universally superior solver. This is appropriate for reporting benchmark records, but it raises a distinction between benchmark improvement and general algorithm discovery. The paper leaves open whether the evolved components transfer to unseen values of rir_i5, different container geometries, or related packing objectives.

Conclusion

Discovery Loop demonstrates that a compact LLM-driven replacement loop can generate useful optimization algorithms on a consumer machine at low monetary cost. In the reported circle-packing experiment, the pipeline produced independently verified improvements on ten Packomania instances, while later iterations yielded only marginal gains at sharply increasing cost. The results support the practical value of structured feedback, independent verification, and adaptive stopping, but they do not yet establish broad transferability or isolate the causal contribution of LLM evolution from the seed solver and stochastic numerical search.

Whiteboard

Explain it Like I'm 14

1. What is the paper about?

This paper describes a computer system called Discovery Loop. It uses a LLM, or LLM—the kind of AI that can understand and write computer code—to improve programs that solve difficult problems.

The researchers tested Discovery Loop on a circle-packing problem:

Put many circles inside a square so that they do not overlap, while making the total size of the circles as large as possible.

The system created and tested improved programs again and again. According to the paper, it found better solutions than the previous records for 10 different circle-packing challenges, spending only $27.72 on the AI model.

The main idea is that advanced algorithm research might not always require a large company or expensive computer cluster. A single person with a powerful AI tool and an ordinary computer might also make useful discoveries.

2. What questions did the researchers ask?

The paper focused on several main questions:

  • Can an LLM improve a computer program for solving a difficult mathematical problem?
  • Can this be done with only one computer instead of a large research facility?
  • Can the system find genuinely new strategies, rather than simply changing numbers in an existing program?
  • How much does this process cost?
  • When should the system stop trying because further attempts are unlikely to help?

In simpler terms, the researchers wanted to know:

Can an AI act like a creative computer scientist, suggesting new ways to solve a problem, and can it do this cheaply?

3. What problem did they study?

Imagine a square box with sides of length 1. The researchers want to place $N$ circles inside it.

The circles may have different sizes, but they must follow two rules:

  1. Every circle must stay completely inside the square.
  2. No two circles may overlap.

The goal is to make the sum of all the circle radii as large as possible. A circle’s radius is the distance from its center to its edge. So, the larger the total radius, the more “circle material” has been fitted into the square.

This is difficult because moving one circle can affect many others. There are also many possible arrangements, and most arrangements are not the best ones.

4. How did Discovery Loop work?

Discovery Loop started with a basic circle-packing program called the seed solver. The system then repeated the following process:

  1. The LLM was shown the current best program.
  2. It was shown a scoreboard describing how well the program performed.
  3. It was shown a history of ideas that had already been tried.
  4. The LLM suggested a completely new version of the program.
  5. The new program was tested on several circle-packing tasks.
  6. An independent checker made sure the answer was legal.
  7. If the new program performed better, it became the new “champion.” Otherwise, it was discarded.

This is similar to training for a sports competition. A team keeps its best player, tries a new player, and replaces the old one only if the new player performs better.

What does “program evolution” mean?

In this paper, program evolution means repeatedly creating new versions of a program and keeping the versions that work best.

The LLM was not just asked to adjust settings. It could redesign major parts of the solver. For example, it could decide to:

  • Start with circles arranged in a honeycomb-like pattern.
  • Search around a promising arrangement instead of starting randomly each time.
  • Move circles in groups.
  • Remove poorly placed circles and try putting them back in new spaces.
  • Use several searches running at the same time.

What were some technical methods?

The original paper uses several technical terms:

  • Penalty method: The program temporarily gives a bad score to arrangements where circles overlap. This encourages the computer to move toward legal arrangements.
  • Local search: The program makes small changes to an arrangement to see whether it improves.
  • Basin hopping: The program makes a larger jump to escape a poor arrangement, then searches locally again. This is like climbing a hill, jumping to another hill, and climbing again.
  • Linear programming: A mathematical method for finding the best values under a set of rules. In this case, it helped choose circle sizes.
  • L-BFGS-B and SLSQP: Names of mathematical optimization tools used to improve the positions and sizes of the circles.
  • Hexagonal lattice: A honeycomb-like arrangement. Circles placed this way can often fit together efficiently.
  • Parallel search: Several searches run at once on different computer processor cores, like several people looking for the best answer independently.

The LLM produced a complete replacement program each time rather than changing only a few lines. This made each new attempt independent and easier to test.

5. How did the researchers check the results?

The researchers used a separate verifier, which is a checking program that did not share code with the solver.

The verifier checked that:

  • Every circle stayed inside the square.
  • No circles overlapped.
  • The total radius was calculated correctly.
  • Tiny numerical errors did not make an illegal arrangement appear legal.

This independent checking was important. Without it, a program might accidentally—or deliberately—report an answer that looked good but did not really follow the rules.

6. What did the researchers find?

The system was tested on 12 different target problems involving between 26 and 114 circles.

It:

  • Beat the previous records for 10 of the 12 main targets.
  • Improved the previous records by about 2.4% to 5.4%.
  • Matched or nearly matched the old records for the other two targets.
  • Used an LLM budget of $27.72.
  • Ran for about eight hours on a consumer desktop computer.
  • Used a maximum of 15 LLM iterations before reaching the budget limit.

The results were reportedly checked independently and accepted by the Packomania circle-packing database.

Some of the strongest improvements came from ideas such as:

  • Using hexagonal starting patterns.
  • Running multiple searches at the same time.
  • Carefully polishing the places where circles touch.
  • Removing weakly placed circles and reinserting them into better positions.

These ideas were more than simple changes to numbers. They changed how the search worked.

7. What did the cost analysis show?

The system made its biggest progress early.

During the first few attempts, it spent about $4.96 and improved the results noticeably. Later, it spent much more money but made only tiny additional improvements.

This is called diminishing returns. It is like studying for a test: the first hour may greatly improve your score, but the tenth extra hour may help only a little.

The researchers created a feature called plateau detection. A plateau is a period when results stop improving much. The system watches for this and stops early when continued searching is unlikely to be worthwhile.

Based on testing, the researchers believe this would have reduced the cost by about half, from $27.72 to roughly$13.95, while losing only a very small amount of solution quality.

8. Why are these results important?

The results matter for two main reasons.

First, the system found better solutions to a long-standing mathematical challenge. This shows that an LLM can sometimes suggest useful algorithmic ideas, not just write ordinary code.

Second, the experiment suggests that automated algorithm discovery may be available to individuals and small research groups. Earlier systems such as AlphaEvolve and FunSearch were designed for organizations with large computing resources. Discovery Loop used:

  • One LLM call per attempt.
  • One ordinary computer.
  • Local parallel processing.
  • Open-source code.
  • Less than $30 in LLM costs.

This does not mean every difficult problem can be solved so cheaply. However, it shows that the basic idea can work on at least one problem where testing solutions is relatively fast.

9. What are the limitations?

The paper also points out several weaknesses.

The system was tested mainly on one type of problem: circle packing. It is not clear whether it would work as well for other problems, especially those that require much more computing time.

The system also kept only one main champion program at a time. A larger system could keep many different programs and explore more ideas.

Its success depended on the LLM producing correct, working Python programs. The paper says that tests on a different problem involving mixed-integer programming had many code-generation failures.

Finally, improvement slowed down quickly when the system continued working on the same fixed set of targets. The system may be more useful if it moves on to new problems instead of endlessly improving one small group of examples.

10. What could this mean for the future?

The research suggests that LLMs could become assistants for discovering new algorithms in areas such as:

  • Delivery and transportation planning.
  • School or employee scheduling.
  • Factory and supply-chain management.
  • Engineering design.
  • Mathematics and computer science education.

A student could think of Discovery Loop as a tireless teammate. The student explains the problem, the AI suggests new strategies, the computer tests them, and a trusted checker decides whether they are correct.

However, human supervision would still be important. An AI may produce code that does not work, misunderstand the goal, or find an answer that seems good but fails under careful checking. Independent verification remains essential.

Conclusion

The paper presents a small, inexpensive system that uses an LLM to repeatedly invent and test new optimization programs. On the circle-packing problem, it reportedly broke 10 existing records for less than $30.

The biggest lesson is not only that the circles were packed more efficiently. It is that AI-assisted algorithm discovery may be becoming accessible beyond large technology companies and research laboratories. With a good problem, careful testing, and independent verification, an individual researcher may be able to use an ordinary computer and an LLM to explore new ideas in mathematics and engineering.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

  • The contribution of LLM-guided evolution is not isolated. All 10 record improvements are reported as occurring at iteration 0 with the seed solver, so the paper does not establish how much additional performance came from the LLM-generated candidates rather than from the initial solver.
  • There is no ablation study of system components. The effects of the LLM, scoreboard, idea history, full-program replacement, per-target best tracking, independent verification, and plateau detection are not measured separately.
  • The seed solver is insufficiently specified for reproduction. Important details such as initialization distributions, penalty coefficients, stopping criteria, LP formulation, numerical tolerances, random seeds, and the number of restarts are omitted.
  • The experimental results are based on a single run. No repeated runs, confidence intervals, variance estimates, or sensitivity analyses are provided for the stochastic solver, LLM outputs, or evaluation process.
  • The selected target set is not justified. The study evaluates 12 manually selected values of NN, omitting nearby instances such as N=104N=104, N=110N=110, N=112N=112, and N=113N=113; this leaves open whether the method generalizes across the full Packomania range.
  • The reported records are not compared with a consistent set of contemporary baselines. The paper does not benchmark the seed solver, standard state-of-the-art packing algorithms, or non-LLM program-search methods under matched computational budgets.
  • The quality of the LLM-generated improvements is not independently attributed. The claim that the discovered methods are “genuine algorithmic innovations” is not supported by controlled experiments showing that each named innovation improves performance relative to an otherwise identical solver.
  • The evaluation budget is not normalized across candidates. Candidate solvers may use different amounts of CPU time, random restarts, memory, and internal computation, making score comparisons difficult to interpret as algorithmic improvements.
  • The scoring and selection rule may obscure per-instance performance. The aggregate score σ\sigma' can favor improvements on some targets while sacrificing others, but the paper does not analyze trade-offs, fairness across targets, or whether candidates were rejected despite producing meaningful specialized improvements.
  • The per-target best results are not necessarily produced by one deployable solver. Because best results are retained across different candidate solvers, the reported collection of records may require multiple specialized solvers rather than a single algorithm that achieves all listed values.
  • The independent verifier is not described in sufficient technical detail. The paper does not specify its floating-point arithmetic, feasibility-shrink magnitude, treatment of near-contact configurations, reproducibility across platforms, or how “zero tolerance” is implemented numerically.
  • The relationship between verifier shrinkage and the reported objective is unclear. It is not reported whether the tabled sums are pre-shrink or post-shrink values, nor how much objective value is lost during strict feasibility correction.
  • The Packomania acceptance process is not independently documented. Submission identifiers, archived records, verifier outputs, and exact solution files are not included in the paper, limiting external confirmation of the claimed improvements.
  • The plateau detector is validated only retrospectively on one trajectory. Its reported savings depend on a single run and cannot establish that the chosen window W=4W=4 and threshold θ=0.01\theta=0.01 work reliably on other problems, models, target sets, or random seeds.
  • The plateau criterion is not compared with alternative stopping policies. There is no analysis against fixed iteration limits, sequential statistical tests, marginal-cost rules, or model-based stopping methods.
  • The reported counterfactual cost saving may be optimistic. Stopping at iteration 9 could alter later solver-selection dynamics, and the paper does not perform prospective runs to verify that the claimed quality-cost trade-off is reproducible.
  • The cost accounting is underspecified. The paper does not state token counts, input/output pricing, retries, failed calls, cached context costs, or whether CLI and infrastructure costs were excluded.
  • The runtime comparison is incomplete. Wall-clock time is reported, but total CPU time, parallelization overhead, solver time by target, and the computational cost of competing methods are not provided.
  • Model dependence is acknowledged but not systematically evaluated. Results from Claude Fable 5.1 are not compared with other LLMs, model temperatures, prompting strategies, context lengths, or model versions.
  • The claimed reproducibility is vulnerable to model and benchmark drift. The use of a live Packomania endpoint and a proprietary model may produce different records, prompts, or outputs over time; no frozen benchmark snapshot or model configuration is supplied.
  • The MIPLIB failure-rate claim is not substantiated. The paper mentions a 75% code-generation failure rate but gives no instance list, sample size, failure taxonomy, prompts, baseline, or results, preventing meaningful interpretation.
  • Generalization beyond circle packing remains untested. The paper provides no successful experiments on scheduling, routing, combinatorial optimization, continuous optimization, expensive simulations, or problems with non-geometric constraints.
  • Scalability is unknown. The study does not evaluate larger NN, substantially more targets, higher-dimensional packing, alternative container geometries, or instances whose evaluations exceed the 120-second timeout.
  • The search strategy may be vulnerable to premature convergence. Maintaining a single champion and replacing it with complete solver rewrites can discard complementary ideas, but the paper does not compare this design with populations, archives, branching search, or ensemble solvers.
  • The history mechanism is not analyzed. It is unknown whether the last 12 ideas are sufficient, whether longer histories improve or degrade search, and how duplicate or contradictory proposals are handled.
  • Candidate failures are not systematically characterized. The paper reports no breakdown of compilation errors, timeouts, infeasible outputs, verifier failures, numerical failures, or low-quality but valid candidates.
  • The effect of randomness is not controlled. Random seeds for candidate solvers and evaluations are not reported, and it is unclear whether a candidate’s apparent improvement reflects algorithmic quality or favorable stochastic variation.
  • The prior-record comparison may conflate benchmark improvements with methodological progress. Since the seed solver already exceeds many prior records substantially, the paper does not explain whether the Packomania records were outdated, generated under different conventions, or directly comparable.
  • No optimality or near-optimality bounds are provided. The improvements establish new best-known solutions but do not indicate how close the solutions are to theoretical upper bounds or global optima.
  • The geometric structure of the resulting packings is not analyzed. The paper does not report contact graphs, symmetry, lattice defects, radius distributions, or structural differences from prior records that could explain why the solver succeeds.
  • The claimed democratization benefits are not empirically evaluated. Assertions about accessibility for individual researchers, education, and engineering applications are not supported by user studies, deployment experiments, or cost comparisons across domains.
  • The paper does not assess security and reliability risks of executing LLM-generated code. Sandboxing, resource isolation, malicious or unintended code behavior, dependency control, and protection of the evaluation environment are not discussed.
  • The long-term value of discovered code is unclear. It is not shown whether the evolved solvers remain effective when rerun independently, transferred to unseen instances, or maintained without continued LLM interaction.

Practical Applications

Immediate Applications

The paper’s main immediately deployable contribution is a lightweight workflow for using an LLM to propose complete optimization programs, evaluate them automatically, and retain only independently verified improvements.

  • Local optimization-solver improvement for engineering teams
    • Sector: Engineering, manufacturing, logistics, operations research.
    • Organizations can adapt the open-source Discovery Loop architecture to improve existing solvers for scheduling, routing, facility layout, resource allocation, and packing.
    • A practical workflow would provide the LLM with:
    • the current solver source code,
    • objective and constraint definitions,
    • benchmark results,
    • previously attempted ideas, and
    • an independent feasibility checker.
    • Candidate programs could be evaluated in parallel on a workstation or small server, with only verified improvements promoted.
    • Dependencies: The target problem must have a relatively cheap automated evaluator; generated code must run in a sandbox; and an independent verifier must be available. The paper’s poor results on mixed-integer programming indicate that performance may degrade for more complex problem representations.
  • Automated improvement of geometric and layout optimization
    • Sector: Robotics, warehouse design, computer-aided design, manufacturing, telecommunications.
    • The discovered techniques—structured initialization, basin hopping, contact-graph polishing, defect removal and reinsertion, and parallel “island” searches—can be incorporated into tools for:
    • warehouse and shelf layout,
    • component placement,
    • sensor positioning,
    • geometric nesting,
    • antenna or wireless-cell placement, and
    • robot workspace allocation.
    • The circle-packing implementation can serve as a starting problem plugin, with domain-specific objectives and constraints substituted for the packing equations.
    • Dependencies: Real-world layouts often include obstacles, nonuniform shapes, discrete placement rules, and multiple objectives. These additions may require specialized representations and stronger validation than the demonstrated unit-square problem.
  • Cost-controlled algorithm experimentation
    • Sector: Software engineering and research computing.
    • The plateau detector can be integrated into automated code-generation and optimization pipelines to stop LLM experimentation when recent iterations produce negligible gains.
    • A practical implementation would monitor:
    • whether recent candidates are accepted,
    • improvement over a rolling window,
    • evaluation cost per candidate, and
    • the marginal value of further searches.
    • This could reduce API expenditure and compute waste. In the reported backtest, stopping earlier would have reduced LLM cost by approximately 50% with only a very small loss in the aggregate benchmark score.
    • Dependencies: The stopping threshold must be calibrated to the application. A small improvement may be commercially important in one setting and irrelevant in another.
  • Benchmark-solving and reproducible mathematical experimentation
    • Sector: Academia and computational mathematics.
    • Individual researchers can use the open-source system to explore established optimization benchmarks without access to a large computing cluster.
    • The workflow supports reproducible experimentation by preserving:
    • the solver version,
    • the generated idea description,
    • benchmark scores,
    • rejection or acceptance status,
    • verification outputs, and
    • submission records.
    • This is particularly suitable for combinatorial geometry, metaheuristics, and numerical optimization courses or research projects.
    • Dependencies: Results should not be treated as reliable solely because an LLM generated them. Independent verification, fixed evaluation protocols, random-seed documentation, and comparisons with accepted benchmark records remain necessary.
  • Teaching tool for optimization and AI-assisted programming
    • Sector: Education and academic training.
    • Instructors can use the system to demonstrate:
    • local search and basin hopping,
    • initialization strategies,
    • constraint verification,
    • algorithmic ablation,
    • cost–quality trade-offs,
    • reproducibility, and
    • the difference between parameter tuning and architectural algorithm changes.
    • Students could compare LLM-generated proposals such as lattice initialization or defect migration against random-restart baselines.
    • Dependencies: Educational deployments require code sandboxing, transparent grading criteria, and instruction on validating AI-generated code rather than accepting it uncritically.
  • Independent verification services for AI-generated optimization code
    • Sector: Software assurance, scientific computing, industrial AI.
    • The paper’s verifier design can be used as a general pattern for evaluating generated solvers:
    • keep solver and verifier implementations independent,
    • recompute objectives from raw outputs,
    • enforce strict feasibility checks, and
    • reject numerical artifacts.
    • This could become a reusable testing component in internal optimization platforms or continuous-integration pipelines.
    • Dependencies: “Zero tolerance” is practical for the paper’s geometric constraints but may be inappropriate for noisy, stochastic, or floating-point-heavy applications. Domain-specific tolerances must be justified and tested.
  • Personal and small-business planning tools
    • Sector: Daily life, small business, scheduling.
    • The same loop could improve programs for limited-scale tasks such as:
    • assigning employees to shifts,
    • arranging events within rooms,
    • planning deliveries,
    • allocating household or office storage, or
    • balancing budgets under stated constraints.
    • The result would not necessarily be a consumer-facing autonomous optimizer immediately, but rather a locally run assistant that proposes and tests alternative planning algorithms.
    • Dependencies: Users must provide accurate constraints and objective priorities. Poorly specified objectives could produce solutions that are mathematically efficient but impractical or unfair.

Long-Term Applications

The longer-term opportunities require broader validation, larger evaluation infrastructures, domain-specific safety controls, or research into how well the approach transfers beyond circle packing.

  • General-purpose optimization-agent platforms
    • Sector: Software, enterprise operations, logistics, finance, energy.
    • A future platform could accept a formal optimization problem and automatically:
    • 1. generate a seed solver,
    • 2. propose alternative algorithms,
    • 3. execute candidates in isolated environments,
    • 4. maintain a population of competing solvers,
    • 5. detect plateaus, and
    • 6. produce a validated production candidate.
    • Potential applications include fleet routing, supply-chain planning, portfolio construction, production scheduling, and energy dispatch.
    • Dependencies: The system would need robust problem modeling, reliable code execution, population-based search, reproducible evaluations, explainability, and safeguards against optimizing an incomplete or misleading objective.
  • Large-scale logistics and supply-chain optimization
    • Sector: Transportation, warehousing, retail, manufacturing.
    • LLM-guided evolution could discover problem-specific heuristics for vehicle routing, container loading, inventory placement, and multi-stage scheduling.
    • The paper’s full-program replacement strategy may be useful when improvements require changing the solver architecture—for example, combining neighborhood search with a learned repair heuristic rather than merely adjusting parameters.
    • Dependencies: Industrial instances are larger, dynamic, and often expensive to evaluate. Candidate solutions also need to satisfy labor rules, delivery commitments, uncertainty constraints, and operational explainability requirements.
  • Robotics motion planning and physical-space allocation
    • Sector: Robotics and autonomous systems.
    • Evolved solvers could optimize robot motion, multi-robot coordination, grasp selection, sensor placement, or packing of objects in constrained workspaces.
    • Geometric verification principles from circle packing could be extended to collision checking and workspace safety.
    • Dependencies: Real robots require guarantees under perception error, actuator uncertainty, timing constraints, and changing environments. Simulation-based improvements would need extensive hardware validation before deployment.
  • Energy-system scheduling and infrastructure design
    • Sector: Energy and utilities.
    • The approach could generate heuristics for battery dispatch, renewable-energy integration, microgrid scheduling, charging-station placement, and transmission or facility layout.
    • Plateau detection could help control expensive experimentation when candidate evaluations involve detailed power-flow or physical simulations.
    • Dependencies: Energy applications require security, reliability, regulatory compliance, and robust optimization under uncertain demand and generation. A solver that performs well on historical benchmarks may fail under rare but critical conditions.
  • Financial optimization and risk management
    • Sector: Finance and insurance.
    • Potential uses include portfolio rebalancing, collateral allocation, execution scheduling, and stress-test scenario selection.
    • Independent verification could recompute risk measures, exposure limits, and regulatory constraints outside the generated solver.
    • Dependencies: Financial objectives are nonstationary and sensitive to model assumptions. Generated algorithms would require extensive backtesting, out-of-sample evaluation, audit trails, human approval, and controls against unintended risk-taking.
  • Healthcare scheduling and facility planning
    • Sector: Healthcare operations.
    • Candidate algorithms could improve operating-room scheduling, staff rostering, appointment allocation, ambulance positioning, and medical-device placement.
    • The verifier pattern could enforce hard constraints such as staffing levels, capacity, and appointment compatibility.
    • Dependencies: Healthcare applications involve patient safety, privacy, fairness, and legally or ethically significant trade-offs. Deployment would require human oversight and validation on representative operational data; the paper does not demonstrate clinical or healthcare performance.
  • Population-based and multi-agent discovery systems
    • Sector: AI research and automated science.
    • The paper maintains one champion solver, but future systems could maintain multiple solver “islands,” preserve specialized candidates for different targets, and periodically exchange ideas.
    • This could reduce premature convergence and support simultaneous optimization across heterogeneous instances.
    • Dependencies: Population systems increase compute and evaluation costs and require selection mechanisms that prevent low-quality or redundant candidates from dominating. They also need provenance tracking so that successful innovations can be attributed and reproduced.
  • Transfer of evolved algorithmic components across related problems
    • Sector: Scientific computing and industrial software.
    • Techniques such as structured initialization, defect migration, contact-graph refinement, and plateau detection could be stored as reusable algorithmic modules and transferred among related optimization tasks.
    • A future library might automatically identify which components generalize from circle packing to sphere packing, layout, scheduling, or network design.
    • Dependencies: Transferability is unproven. A heuristic that works for dense geometric packing may be ineffective or harmful in discrete or stochastic problems. Component reuse would require systematic ablation studies and problem-class benchmarks.
  • Policy and public-sector resource allocation
    • Sector: Government, urban planning, public infrastructure.
    • Public agencies could use similar systems to explore bus scheduling, emergency-resource placement, school-capacity planning, land-use allocation, and infrastructure maintenance.
    • Independent verification and archived iteration histories could support transparency and auditability.
    • Dependencies: Public-sector objectives involve equity, legal constraints, stakeholder participation, and political accountability—not merely numerical optimization. Any deployment would require interpretable objectives, fairness analysis, public review, and human decision authority.
  • Automated scientific discovery beyond optimization benchmarks
    • Sector: Academia, materials science, computational biology, and physics.
    • The architecture could eventually generate programs for simulation control, experimental design, symbolic construction, or hypothesis testing, provided each candidate has a reliable automated evaluation.
    • The paper’s main methodological lesson is that inexpensive iterative search can expose useful algorithmic ideas when the problem description, feedback signal, and verifier are well designed.
    • Dependencies: Scientific applications require stronger controls for false discoveries, data leakage, simulator mismatch, and irreproducible results. The demonstrated evidence supports algorithm discovery on a constrained benchmark, not yet autonomous scientific inference across open-ended domains.

Glossary

  • Adaptive operator: A search operation whose behavior changes in response to observed performance or search conditions. “Sparse penalty + adaptive operators + elite pool”
  • Affine lattice: A lattice transformed by linear operations and translation, used here to generate structured geometric configurations. “Affine lattice template bank”
  • Basin hopping: A metaheuristic that alternates perturbations of a candidate solution with local optimization to explore multiple attraction basins. “The best solvers use combinations of penalty methods, basin-hopping metaheuristics, and linear programming for radii optimization.”
  • Champion solver: The currently best-performing solver retained by an iterative optimization process. “The LLM proposes a complete replacement solver.”
  • Combinatorial geometry: The study of geometric structures involving discrete objects and their arrangements. “The problem of packing circles in a container is a classical topic in combinatorial geometry”
  • Combinatorial optimization: Optimization over configurations involving discrete or structurally distinct choices. “AlphaEvolve~\citep{alphaevolve2025} demonstrated that LLM-guided program evolution could discover state-of-the-art algorithms for combinatorial optimization”
  • Contact graph: A graph representing which geometric objects touch or constrain one another. “Basin hopping with contact-graph polish (iter 1)”
  • Constructive mathematics: Mathematics focused on explicitly building objects or solutions rather than merely proving their existence. “FunSearch~\citep{funsearch2024} similarly uses LLMs for program search but focuses on discovering mathematical constructions”
  • Crossover: An evolutionary computation operation that combines characteristics of multiple candidate solutions. “Hexagonal lattice init + crossover”
  • Defect migration: A packing heuristic that relocates problematic or weakly placed objects to alter and improve the configuration. “Defect migration (iter 12): removing weak circles, letting the packing re-equilibrate, then reinserting into new holes”
  • Diminishing returns: A pattern in which additional computational effort produces progressively smaller improvements. “We implemented an early-stopping mechanism based on diminishing returns”
  • Elite pool: A collection of the best candidate solutions retained to guide subsequent search. “Sparse penalty + adaptive operators + elite pool”
  • Evolutionary controller: A mechanism that manages the generation, evaluation, selection, and modification of candidate programs. “A distributed evaluation pool, a carefully tuned evolutionary controller, and significant compute resources.”
  • Feasibility shrink: A deliberate reduction of a numerical solution to ensure that it satisfies constraints despite floating-point errors. “Applies a strict feasibility shrink to eliminate numerical-precision artifacts”
  • Formulation-space search: Exploration that changes the mathematical or computational representation of a problem, rather than only adjusting parameters. “Formulation-space search”
  • Hexagonal lattice: A regular two-dimensional arrangement in which points or circles are organized in a hexagonal pattern. “Hexagonal lattice initialization (iter 4)”
  • Independent verifier: A separate checking procedure that validates candidate outputs without sharing implementation code with the solver. “This is essential for credibility: the verifier shares no code with the solver”
  • Island model: An evolutionary strategy that runs multiple semi-independent search populations and occasionally exchanges high-quality solutions. “Island-model parallelism (iter 5): independent basin-hopping chains on separate CPU cores with periodic migration of elite solutions.”
  • KKT conditions: Necessary mathematical conditions for constrained optimization, named after Karush, Kuhn, and Tucker. “KKT-Newton exact polish”
  • Local optimum: A solution better than nearby alternatives but not necessarily better than all feasible solutions. “For large NN, the landscape is highly non-convex with many local optima.”
  • Local search: An optimization method that improves a solution by examining nearby candidate solutions. “new move operators, initialization strategies, local search enhancements”
  • LLM: A neural LLM trained on large text collections that can generate and transform natural language and code. “We present Discovery Loop, a lightweight system that uses a LLM to iteratively evolve optimization algorithms.”
  • Linear programming (LP): Optimization of a linear objective subject to linear equality or inequality constraints. “The best solvers use combinations of penalty methods, basin-hopping metaheuristics, and linear programming for radii optimization.”
  • L-BFGS-B: A limited-memory quasi-Newton optimization algorithm that supports bound constraints. “a simple multi-start penalty L-BFGS-B solver with LP-optimal radii”
  • Metaheuristic: A high-level search strategy designed to find good solutions to difficult optimization problems without guaranteeing global optimality. “a metaheuristic move that changes the combinatorial structure of the packing.”
  • Mixed-integer programming (MIP): Optimization involving both continuous variables and integer or binary variables. “Our MIPLIB experiment (mixed-integer programming) had a 75\% failure rate in code generation”
  • Non-convex: Describing an optimization landscape in which local optima may exist and standard convexity guarantees do not apply. “For large NN, the landscape is highly non-convex with many local optima.”
  • Penalty method: An optimization technique that incorporates constraint violations into the objective through penalty terms. “The best solvers use combinations of penalty methods, basin-hopping metaheuristics, and linear programming for radii optimization.”
  • Plateau detection: Identification of a period in which iterative optimization produces little or no improvement. “We implemented an early-stopping mechanism based on diminishing returns”
  • Population: A set of candidate solutions maintained simultaneously in an evolutionary or population-based search method. “A population of solvers might enable more diverse exploration.”
  • Ruin-and-recreate: A large-neighborhood search operation that removes part of a solution and reconstructs it, potentially producing an improved configuration. “Ruin-and-recreate LNS”
  • Scoreboard: A structured record of candidate performance used to guide subsequent algorithm generation. “An LLM (Claude Fable 5.1) receives the current best solver, a scoreboard of results, and a history of ideas tried.”
  • SLSQP: Sequential Least Squares Programming, a constrained nonlinear optimization algorithm based on sequential quadratic programming. “Basin hopping + SLSQP contact polish”
  • Surrogate screening: Using an approximate predictive model to filter candidate solutions before applying more expensive evaluation. “Surrogate-screened basin hopping”
  • Target instance: A specific parameterized version of an optimization problem used for evaluation. “Targets: N{26,32,101,102,103,105,106,107,108,109,111,114}N \in \{26, 32, 101, 102, 103, 105, 106, 107, 108, 109, 111, 114\}
  • Variable-radius circle packing: A geometric optimization problem in which circles may have different radii and must be arranged without overlap. “the csqv variant---packing NN circles with variable radii in the unit square [0,1]2[0,1]^2 to maximize the sum of radii”
  • Zero-tolerance verification: Validation requiring exact constraint satisfaction within the adopted numerical checking procedure. “All results independently verified with zero tolerance and accepted by Packomania.”

Open Problems

We found no open problems mentioned in this paper.

Tweets

Sign up for free to view the 7 tweets with 93345 likes about this paper.