Algogens

1. Introduction

When I first published this paper in January 2024, large language models could already write code, explain proofs and draft plans. They have improved a great deal since. They are still unreliable in the sense an engineer means: a model that is right most of the time still needs something that tells you which times.

Over the same period a pattern spread through research labs. Systems that discover new mathematics, solve olympiad geometry or design new algorithms rarely trust the model's own judgment. A language model proposes, and a program, a proof checker, a solver or a simulator decides. FunSearch keeps the programs that a sandboxed evaluator scores best [2]. AlphaGeometry pairs a language model with a symbolic deduction engine that checks every step [3]. AlphaEvolve evolves code for algorithmic and scientific problems under automatic evaluators [4].

I call systems of this broad kind AlgoGens. The name and the definition come from my monograph, Introduction to Algogens [1]. This page is the short version. I revised it in November 2026 to take in my newer work on how these systems decide what counts.

2. What an AlgoGen Is

2.1 The definition

The monograph defines Algogens as "a cutting-edge framework integrating the precision of algorithmic processes with the creativity and adaptability of generative artificial intelligence" [1]. Put plainly, an AlgoGen is a blend of generative AI and traditional algorithms in which the algorithms are the backbone and the guide rails, and the generative AI explores inside them.

The definition is broad, and many shapes fit it. A loop in which a model proposes and a validator accepts, repairs or rejects is one kind of AlgoGen. A solver that receives a problem a model has translated into formal terms is another. So is a search tree whose branches a proof checker prunes, and a population of programs that an evaluator ranks. An agent harness also counts: when tests, type checks, permissions and retry rules carry the system and the model works inside them, the harness is an AlgoGen.

2.2 What each side brings

Algorithms are precise and repeatable, and you can check them. They are also narrow. Someone has to write one for each problem, and they struggle where the problem is stated loosely or the search space is huge. Generative models have the opposite profile. They handle loose statements, they suggest moves nobody wrote down, and they produce candidates at almost no cost. Their output is unreliable, and a model asked to grade its own work tends to share the blind spots that caused the error in the first place [5].

3. Who Decides What Counts

Every AlgoGen has a part that decides which of the model's candidates count: which program is kept, which proof is accepted, which answer is returned, which sample is used for training. I call this part the authority. It can accept or reject a candidate, give it a score, or rank it against others.

3.1 A ladder of authorities

Authorities differ in what they can tell you, and it helps to place them on a ladder.

1. No check. Whatever the model produces is used.
2. Self-grading. The same model, or a copy of it, judges its own candidates.
3. An independent but noisy proxy, such as a learned reward model, a heuristic score or a test suite that covers part of the specification.
4. An exact checker, such as a proof checker, a type checker, a constraint check or an evaluator that computes the true objective.
5. A full decider, which can answer claims about the whole space of candidates, including candidates the model never proposed. "No better solution exists" is a claim of this kind.

A sharper signal can usually be blurred into a weaker one, so moving up the ladder rarely loses anything. What makes a higher rung worth its cost is information. Self-grading adds little, since the judge sees only what the generator saw. A rung earns its place when it knows something about the target that the model cannot work out from its own view within its own budget. A proof checker is the clearest case. The model can see the statement and its own proof, but checking the proof is cheap for the checker and hard for the model.

The top rung is different in kind. An authority that only answers questions about proposed candidates can confirm that a candidate is good. It cannot confirm that nothing better exists unless it sees every candidate. Claims of optimality need a decider that reasons about the whole space, such as a solver that returns a bound.

3.2 Two ways to be wrong

When an AlgoGen returns only candidates its authority accepted, a wrong output has two sources, possibly both. Either the authority accepted something that breaks the specification, which is a failure of soundness, or the specification itself missed what was wanted, which is a failure of fidelity. The two need different fixes. A better checker cures the first and does nothing for the second, so the specification deserves as much review as the code that checks against it.

4. Five Design Families

The systems I have studied fall into five families. They differ in how candidates travel between the model and the authority.

1. Formalize, then solve. The model translates a problem stated in words into a formal model, and a classical solver or planner does the rest. LLM+P, which hands a planning problem to an optimal planner, is an example [6].
2. Check and repair. The model proposes, the authority runs tests or checks, and its feedback drives a revision until the candidate passes or the budget runs out. LLM-Modulo frameworks, which surround a planning model with external critics, belong here [7].
3. Search over proof states. The model suggests the next step, and a proof checker or a deduction engine decides which branches stay alive. AlphaGeometry [3] and AlphaProof [8] work this way.
4. Evolve programs. The model mutates a population of programs, an evaluator ranks them, and the best survive into the next round. FunSearch [2] and AlphaEvolve [4] are the best-known members.
5. Learn from an oracle. A simulator, a docking score, a solver or a verifier scores the model's samples, and the scores train the model. Some systems in this family discover an algorithm that later runs without the model at all.

The fraud loop in the preface, where a model proposes and a validator checks, repairs or rejects, belongs to the second family. Older examples from the first version of this paper, such as language models that choose among algorithms [10] or act as optimizers under a scoring function [11], fit the same frame.

5. Three Moments of Authority

The authority can act at three different times.

• At test time, inside the loop that answers one request: search, repair, or selection among many samples. Coding agents that run the test suite are the familiar case.
• At train time, on the data or rewards that update the model's weights. Reinforcement learning on verifiable rewards and training on checked synthetic data are the familiar cases.
• At design time, on artifacts that outlive the model, such as a new algorithm, a heuristic, a material or a proof that is kept after the model is gone.

Seen this way, reasoning models trained on verifiable rewards, agents that run tests and discovery engines such as AlphaEvolve share one structure, with the authority acting at a different moment in each. The moment changes what the authority must be good at. A checker that is good enough to filter answers at test time can be too weak to train against, because training pushes the model toward exactly the gaps the checker does not cover.

6. Scaling Under an Authority

Drawing more samples raises the chance that one of them passes. It does not raise the reliability of what passes beyond what the authority allows. If a proxy accepts some wrong candidates, more samples find more of those as well, and past some point extra compute buys confidence without accuracy. Cobbe et al. saw an early form of this: when a learned verifier picked among more and more sampled solutions to math word problems, accuracy stopped improving and then fell, because some wrong solutions fooled the verifier [9].

The authority sets the ceiling. A stronger generator reaches it with fewer samples. A fixed authority caps what more samples can buy. Raising the cap takes a stronger authority, or a generator that makes fewer of the errors the authority misses. For that reason I treat the choice of authority as the first design decision in an AlgoGen and the choice of model as the second.

7. Reporting Who Decided

Results produced by AlgoGens are often reported as if the model alone produced them. A reader needs to know who decided what counted. For each headline result I now keep a short card that names the authority and its rung on the ladder, the moment at which it acted, what the specification covers, and what the authority cannot see. Readers tend to skip the last line, yet it says what the result does not prove.

8. Applications

Mathematics, algorithm design and planning appear in the examples above. Two further domains are close to my own work.

In fraud detection the generative side proposes features, rules and mappings for new data feeds, and deterministic checks decide which of them may run. The preface at the top of this page describes that reading. In security operations the same split lets a model suggest an investigation or a response while policy, telemetry and blast-radius checks decide what executes. In both domains the authority is the part a regulator or an incident review will ask about, so it has to be written down, tested and owned by people.

9. Open Problems

Several questions remain open. How much a noisy proxy knows beyond the model is hard to measure; we can tell when a checker is exact, and much less about everything below that. Specifications need their own review, since a sound checker of the wrong specification passes the wrong things with full confidence. Exact checkers can be expensive, and systems need principled ways to spend a cheap check first and an expensive one later. Finally, the first version of this paper hoped that language models would improve the algorithms and models that made them. That hope still stands, with one condition: a system that improves itself needs an authority it cannot fool, which means an authority that is independent of the model being improved.

10. Conclusion

An AlgoGen puts a generative model to work inside algorithmic guide rails. Its reliability is set by the part that decides what counts, and that part can be placed on a ladder, sorted into families and assigned a moment in the system's life. Building one well starts with choosing and documenting the authority, and only then the model.

References

[1]	Shachar, A. (2024). Introduction to Algogens. arXiv preprint arXiv:2403.01426.
[2]	Romera-Paredes, B., Barekatain, M., Novikov, A., Balog, M., Kumar, M. P., Dupont, E., Ruiz, F. J. R., Ellenberg, J. S., Wang, P., Fawzi, O., Kohli, P., & Fawzi, A. (2024). Mathematical discoveries from program search with large language models. Nature, 625, 468 to 475.
[3]	Trinh, T. H., Wu, Y., Le, Q. V., He, H., & Luong, T. (2024). Solving olympiad geometry without human demonstrations. Nature, 625, 476 to 482.
[4]	Novikov, A., Vũ, N., Eisenberger, M., Dupont, E., Huang, P.-S., Wagner, A. Z., et al. (2025). AlphaEvolve: A coding agent for scientific and algorithmic discovery. arXiv preprint arXiv:2506.13131.
[5]	Stechly, K., Valmeekam, K., & Kambhampati, S. (2025). On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks. International Conference on Learning Representations (ICLR 2025).
[6]	Liu, B., Jiang, Y., Zhang, X., Liu, Q., Zhang, S., Biswas, J., et al. (2023). LLM+P: Empowering Large Language Models with Optimal Planning Proficiency. arXiv preprint arXiv:2304.11477.
[7]	Kambhampati, S., Valmeekam, K., Guan, L., Verma, M., Stechly, K., Bhambri, S., et al. (2024). LLMs Can't Plan, But Can Help Planning in LLM-Modulo Frameworks. Proceedings of the 41st International Conference on Machine Learning, PMLR 235.
[8]	Hubert, T., Mehta, R., Sartran, L., Horváth, M. Z., Žužić, G., Wieser, E., et al. Olympiad-level formal mathematical reasoning with reinforcement learning. Nature, 651, 607-613 (2026).
[9]	Cobbe, K., Kosaraju, V., Bavarian, M., Chen, M., Jun, H., Kaiser, L., Plappert, M., Tworek, J., Hilton, J., Nakano, R., Hesse, C., & Schulman, J. (2021). Training Verifiers to Solve Math Word Problems. arXiv preprint arXiv:2110.14168.
[10]	Wu, X., Zhong, Y., Wu, J., & Tan, K. C. (2023). AS-LLM: When Algorithm Selection Meets Large Language Model. arXiv preprint arXiv:2311.13184.
[11]	Yang, C., Wang, X., Lu, Y., Liu, H., Le, Q. V., Zhou, D., & Chen, X. (2023). Large Language Models as Optimizers. arXiv preprint arXiv:2309.03409.