EvoGit: Decentralized Code Evolution via Git-Based Multi-Agent Collaboration

Beichen Huang; Kay Chen Tan; Ran Cheng

REVIEW 4 major objections 5 minor 1 cited by

EvoGit: Decentralized Code Evolution via Git-Based Multi-Agent Collaboration

T0 review · 4 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read EvoGit claims that independent LLM coding agents, coordinating only through a Git-based version graph, can evolve working software without scalar rewards or centralized control.

desk verdict Clever and clearly written framework paper whose main empirical claim rests on an unvalidated LLM judge; the formalism is sound, the validation is not. read the letter →

arxiv 2506.02049 v1 pith:6H4N2DCA submitted 2025-06-01 cs.DC cs.AIcs.MAcs.NE

Beichen Huang , Ran Cheng , Kay Chen Tan This is my paper

classification cs.DCcs.AIcs.MAcs.NE

keywords decentralizedmulti-agentsoftwaredevelopmentcodeevolutionphylogeneticversiongraphGit-basedcoordinationLLMcodingagentsreward-freeoptimizationtraceabilityevolutionarycomputation

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

EvoGit sets out to prove that a population of independent large-language-model agents can write real software without a central orchestrator, a shared memory, or a scalar reward function. The coordinating structure is a Git-based phylogenetic graph: every code version is a node, every accepted change is an edge, and the graph's partial order replaces fitness scores. A human only seeds the project, reviews the branch graph at intervals, and prunes or promotes directions. The paper presents two demonstrations: a promotional web application evolved from a scaffold, and a meta-level Python system that itself evolves an LLM-guided solver for bin packing. If the demonstrations hold, the framework turns software development into an asynchronous, traceable evolutionary search with sparse human guidance.

What carries the argument

The load-bearing object is the phylogenetic graph, a rooted directed acyclic graph whose nodes are complete snapshots of the codebase and whose directed edges mean validated evolutionary successor; it induces a partial order over versions, and the maximal nodes, those with no descendants, form the current frontier. Mutation adds one-parent, one-child edges after an LLM pairwise comparison; three-way crossover adds two-parent, one-child edges by diffing each parent against the lowest common ancestor and merging, with random conflict resolution. The graph is implemented on Git commits, references, and notes, which gives the partial order a concrete storage format and makes every agent decision inspectable and replayable.

What would settle it

For accepted edges in the released Git repositories, rerun the same pairwise judge on the reversed edge with identities hidden; if the judge frequently prefers the parent over the accepted child, or if v0-v2 chains contradict v0-v1-v2 transitivity, the no-worse-than-parent invariant fails.

Watch

Extended reading notes

Core claim

The paper's central claim is that code evolution can be driven entirely by structural lineage rather than by measured quality: an agent proposes a small localized mutation to a current best version, a pairwise language-model judge decides whether the candidate is no worse than its parent, and accepted candidates are committed to a directed acyclic graph where an edge means validated successor. Crossovers merge two branches using their lowest common ancestor, preserving inherited context. Multiple maximal, undominated versions form the frontier that agents build on. The authors argue that transitivity of the partial order, if v1 improves v0 and v2 improves v1, then v2 is inferred better than v0, makes long chains of small steps reliable, and that statelessness keeps failures localized. Their demonstrations aim to show that this produces functional, modular software from near-empty seeds, with every step auditable in Git.

Load-bearing premise

The whole monotonic-improvement story rests on an LLM-based pairwise judge correctly deciding, for each small change, whether the candidate is genuinely no worse than its parent; if that judgment is unreliable, transitive chains can quietly accumulate regressions while remaining on the best frontier.

Editorial extensions

If this is right

If correct, a stateless population of LLM agents can develop real software with no scalar reward function, only graph structure and sparse human reviews.
The version graph gives end-to-end traceability, reproducibility, and rollback for every agent decision, turning each edit into an inspectable commit.
Crossover via the lowest common ancestor lets divergent agent branches recombine without shared memory or explicit message passing.
The meta-level task shows that the same mechanism can evolve tools that themselves generate code, suggesting recursive, self-improving automation.
With reward-free partial ordering, the human becomes a product manager who prunes and promotes branches rather than writing code.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Beyond the paper: if the pairwise judge is reliable, the same structural-dominance scheme could evolve any versioned artifact, such as documentation, datasets, or configuration files, not just source code.
Beyond the paper: the small-step constraint is probably what keeps the judge reliable, so scaling EvoGit to large multi-file refactors may require explicit safeguards or periodic re-evaluation.
Beyond the paper: because transitivity propagates errors forward, occasional re-checking of long chains with build tools or human review would be a natural robustness extension the paper does not test.
Beyond the paper: the released Git histories could be mined to measure how much of the final quality came from autonomous mutations versus the sparse human branch selections.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

You should know two things about EvoGit. First, the core idea is genuinely new: using a Git-based phylogenetic graph as the sole coordination substrate for stateless, asynchronous LLM coding agents, with structural dominance (maximal elements) replacing a scalar fitness function. That is a clean and appealing generalization of NEAT's historical markings to software, and the paper works out the mapping to Git primitives carefully. Second, the experimental section is nowhere near strong enough to support the claim that EvoGit "autonomously produces functional and modular software artifacts." The two tasks are described qualitatively, with screenshots and one code listing; there are no baselines, no quantitative metrics, no error bars, and no ablation of the human feedback frequency. The open-sourced repos are a real asset, but the paper does not give a reader the tools to judge whether the final artifacts are better than what a single agent with the same budget would produce.

The formal part of the paper is solid. The partial-order semantics, the definition of maximal elements, and the three-way crossover via lowest common ancestor are all coherent. I also appreciate the honest discussion of stochasticity and the explicit statement in Section C.3 that transitive inferences are sound only if direct comparisons are correct. That last point is precisely where the paper's load-bearing assumption sits. Acceptance of every new version is decided by an LLM pairwise judge whose reliability is asserted, not measured. There is no human-agreement study, no calibration, no comparison against a trivial baseline, and no reporting of whether accepted lineages in Task 2 are monotone in the objective bin-packing score. If that judge is noisy, the whole "monotonic improvement" semantics collapses: branches accumulate regressions while still being accepted, and the maximal elements are just the tips of whatever paths happened to be tolerated. The paper cannot have it both ways: either the judge is trustworthy, in which case it is doing the real work and should be validated, or it is not, in which case the evolutionary story is decoration. This is a fixable problem, but it is not a minor one.

One smaller quibble: calling the framework "reward-free" is a stretch, since the binary accept/reject from the LLM judge is a local reward signal. It is scalar-free in the sense of having no global fitness, but the distinction should be made explicit. The human feedback every 10 or 20 iterations is also more than "minimal" as a control mechanism, though the authors do restrict it to high-level observations.

Who is this for? Researchers working on multi-agent code generation or LLM-based evolutionary computation will find the framework worth discussing and possibly worth building on. It is not yet a validated system, but it is a serious proposal with a clean formal skeleton and open code. I would send it to peer review, and I would ask the authors to add a proper validation of the judge, at least one baseline (e.g., a single-agent or random-edit control), and quantitative evidence from Task 2 that accepted branches actually improve the objective over time. Without that, the central claim remains an anecdote.

Recommendation: engage with it, but condition any acceptance on a serious empirical revision.

Referee Report

4 major / 5 minor

Summary. The paper introduces EvoGit, a decentralized multi-agent framework for software development in which a population of stateless LLM-based agents proposes mutations and crossovers to a shared codebase, with all coordination mediated by a Git-based phylogenetic graph. The graph records every version as a node and every accepted change as an edge, inducing a partial order that the authors use to identify the current evolutionary frontier (maximal nodes) as the best versions. Human oversight is limited to initialization and periodic high-level feedback. To accept or reject a proposed change, each agent uses an LLM-based pairwise judge that compares the new version to its parent(s); the paper argues that because mutations are localized, these comparisons are reliable, and transitive comparisons are logically sound. Experiments are reported on two tasks: building a Next.js promotional website and constructing a meta-level LLM-guided solver for the bin-packing problem. The paper claims these experiments demonstrate autonomous production of functional and modular software, with full traceability via public Git repositories.

Significance. The core idea--using a Git DAG as a coordination substrate and as an external memory for asynchronous, reward-free multi-agent evolution--is an attractive and potentially impactful contribution. The paper provides a clean formalization of the version graph (Section B.1), a clear mapping onto Git primitives (Section C.1), and an open-source implementation with publicly available Git histories for both experiments. If the framework works as claimed, it could offer a new way to organize LLM-based collaborative coding without centralized orchestration or message passing. However, the current evaluation is anecdotal: no quantitative metrics, no baselines, no error bars, and no validation of the LLM judge that is the lynchpin of the entire improvement semantics. The claims in the abstract and conclusion substantially exceed what the evidence supports.

major comments (4)

[§3.2 and Appendix D] The experimental evaluation is entirely qualitative. The paper claims to 'demonstrate EvoGit's ability to autonomously produce functional and modular software artifacts', but the evidence consists of screenshots (Figure 3), a network graph (Figure 10), and a single code listing (Listing 1). No quantitative metric is reported for either task. For Task 2, an objective score exists--the quality of the bin-packing solver--yet the paper does not report the number of bins achieved on standard instances, nor a comparison with classical heuristics such as First-Fit Decreasing or Best-Fit Decreasing. I request concrete metrics for both tasks (e.g., page-load and interaction tests for the web app; solver performance on a benchmark suite; code modularity measures), along with multiple stochastic runs to provide error bars, given the acknowledged non-determinism of LLMs and randomized mutation/crossover (Appendix E).
[§C.3 and §B.1.3] The entire monotonic-improvement semantics rests on the reliability of the LLM-based pairwise judge, but this reliability is asserted rather than measured. The paper states, 'Assuming correctness of direct comparisons, all transitive inferences are logically sound' (Appendix C.3), which explicitly flags the assumption. If the judge is noisy or biased, accepted edges do not correspond to genuine improvements, the partial order no longer reflects quality, and the maximal nodes defined in Section B.1.3 cannot be called 'best' versions. The paper provides no human-agreement study, no calibration data, and no analysis of the judge's error rate on the actual mutation and crossover outputs. In Task 2, where an objective quality signal exists, the paper does not report whether accepted lineages are monotone in that score. I request a validation of the judge (e.g., agreement with human labels on a sample) and, for Task 2, a plot or table showing the objective score along accepted branches.
[§2.1 and §C.3] The claim that EvoGit is 'reward-free' is not substantiated and is potentially misleading. The pairwise LLM comparison in Section C.3 is a binary preference signal that directly gates survival of a version, and the periodic human feedback described in Section 2.4 is a steering signal. If 'reward-free' means 'no scalar numeric fitness', the paper should say so explicitly and should acknowledge that the LLM judge and human feedback constitute forms of ordinal or sparse reward. As written, the contrast with 'scalar reward signals' in the introduction overstates the novelty and could confuse readers about the actual supervision mechanisms.
[Appendix E and §D.1] The experiments are not statistically reproducible: only a single run of each task is reported, despite the acknowledged sources of stochasticity (LLM sampling, randomized target file and editable region selection, randomized conflict resolution). A single run cannot support the strong empirical claims in the abstract. I request multiple independent runs (or at least a sensitivity analysis of the key hyperparameters, including population size and feedback interval) and reporting of variance. Without this, the possibility that the observed successes are fortuitous cannot be excluded.

minor comments (5)

[§3.2] The heading 'Web Applicaiton Development' contains a typo; it should be 'Web Application Development'.
[§B.2.3] In the crossover description, 'replies on structural integrity' should be 'relies on structural integrity'.
[§C.1] The statement that EvoGit 'encodes' the SHA hash 'into a binary vector to index the version' is unclear; a Git hash is already a binary string, and the practical purpose of this encoding for indexing is not explained. Please clarify or remove.
[§D.2] The claim that the number of actively developing agents always upper-bounds the number of frontier solutions is not proven and is not obvious, especially with crossover operations that create a descendant of two parents. A short proof or a more precise statement of the conditions under which this holds would be helpful.
[§3.1] To isolate the contribution of the graph-based coordination, it would be informative to include a baseline with a single agent performing the same number of total iterations, or a synchronous multi-agent system with message passing. The current evaluation does not show that the decentralized graph mechanism itself, rather than the power of the underlying LLM or the number of agents, is responsible for the results.

Circularity Check

2 steps flagged · score 5.0 of 10

EvoGit's 'best version' semantics are self-definitional: maximal nodes in the phylogenetic graph are exactly the survivors of the LLM judge's binary 'improvement' verdict, and the same verdict is then presented as evidence that EvoGit autonomously produces functional software; the judge's correctness is asserted, not validated.

self definitional [Section B.1.3, with Section 2.2 (Step 3–4) and Section C.3]
"Within the phylogenetic graph, the “best” code versions at a given point are characterized as maximal elements, i.e., those that have no descendants under the partial order ⪯. [B.1.3] … Graph Update: If accepted, the candidate is added to the phylogenetic graph as a new node with appropriate parent edges. [2.2] … These signals are passed to an LLM-based judge, which returns a binary decision on whether the new version constitutes an improvement. [C.3]"

Section C.3 gates every new edge on the LLM judge's binary 'improvement' verdict, and Section 2.2 Step 4 adds a node as a descendant only if accepted. Therefore 'maximal element' (B.1.3) means exactly 'has no judge-accepted successor' — the 'best' versions are, by construction, the versions the judge happened to approve. Section 3.2 then cites these maximal/final nodes as demonstrating that EvoGit 'autonomously produce[s] functional and modular software artifacts', and Section 2.2 claims the system 'steadily converges toward increasingly sophisticated and coherent software artifacts'.
other [Section C.3 and Appendix F, with Section 2.3]
"Since EvoGit restricts mutations to be small and localized, judgments remain simple and reliable. Assuming correctness of direct comparisons, all transitive inferences are logically sound. [C.3] … Each descendant version must be no worse than its parent(s), thereby inducing a partial order over the set of versions. This ensures monotonic non-degradation and reflects an evolutionary trajectory of improvement or stability. [Appendix F]"

The transitivity claim converts individual judge verdicts into a global partial order, and Section 2.3 presents that order as letting agents 'infer relative quality' (v1 ⪯ v2 and v2 ⪯ v3 implies v1 ⪯ v3). But ⪯ is constituted entirely by the judge's verdicts, so the quality content of the order is assumed, not established. Appendix F's 'monotonic non-degradation' guarantee holds only under the unvalidated correctness assumption; the paper itself couches the premise as 'Assuming correctness of direct comparisons.' If the judge errs, transitivity propagates the error while the graph remains internally consistent.

full rationale

EvoGit's central quality semantics is injected into the graph by its own acceptance gate. In C.3, every proposed version is passed to an LLM-based judge that returns a binary 'improvement' verdict; only accepted candidates become descendants (2.2 Step 4). In B.1.3, the 'best' code versions are then defined as maximal elements of the resulting partial order. Maximal nodes are therefore, by construction, exactly the versions that survived judge approval — the selection oracle and the success criterion are the same. Section 3.2 presents these survivors as evidence that EvoGit 'autonomously produce[s] functional and modular software artifacts', and Section 2.2 claims the system 'steadily converges toward increasingly sophisticated and coherent software artifacts'. No external calibration of the judge is reported: no accuracy on known regressions, no human-agreement study, and although Task 2 has an objective bin-packing score, the paper never reports whether accepted lineages are monotone in that score. The second load-bearing move is the transitivity argument (C.3) and the 'monotonic non-degradation' guarantee (Appendix F), which hold only under the stated assumption 'Assuming correctness of direct comparisons'; that assumption is asserted, not validated, yet every downstream inference of 'relative quality' (2.3) and every 'Advantageous' claim (2.2) depends on it. If the judge errs, transitivity propagates the error while the graph stays internally consistent. Mitigating factors: the final artifacts are partially externally anchored (screenshots in Fig. 3, public GitHub repositories, runnable Listing 1, sparse human feedback that could veto broken branches), and no load-bearing self-citations appear (all references are external prior work, none co-authored by Huang/Cheng/Tan). These prevent an extreme score, but the framework's improvement semantics and its headline empirical claim rest on the judge as its own justification, supporting a mid-range circularity score of 5.

Assumptions & free parameters 5 free parameters · 4 assumptions · 0 invented entities

The central claim depends on the reliability of the LLM judge and on the assumption that ancestry equals improvement. The experimental hyperparameters are hand-picked. No new physical entities are introduced.

free parameters (5)

population_size = 16
Number of parallel agents in both tasks, hand-chosen; affects exploration breadth and the growth of the frontier.
max_iterations = 120
Total iterations for each task, hand-chosen; systems stopped at this bound regardless of convergence.
feedback_interval = 10 (Task 1), 20 (Task 2)
Frequency of human feedback, hand-chosen; more frequent for the web task to reflect subjectivity.
mutation_region_limit = 128 lines
Maximum size of the randomly selected editable code region, hand-chosen; constrains how 'small' a mutation must be.
acceptance_threshold = binary LLM judge decision
The pairwise comparison judge is a pre-trained LLM with a binary accept/reject threshold; no calibration or ground-truth validation is reported.

assumptions (4)

domain assumption A descendant version is no worse than its ancestor, so ancestry induces a monotone quality partial order.
Used throughout Sections B.1-B.2 to define 'best' versions as maximal elements. The property is enforced by the system's own acceptance rule, not by external validation.
domain assumption The LLM-based pairwise comparison judge reliably classifies proposed code changes as improvements or regressions.
Core to the whole framework (Section C.3); the paper states 'Assuming correctness of direct comparisons...' and provides no empirical check of judge accuracy.
domain assumption Small, localized mutations accumulate into complex, functional software within the iteration budget.
Design principle in Section 2.2 ('small-step evolution'); it is the mechanism that converts local edits into global functionality, but is never tested in isolation.
standard math Transitivity of the partial order: if v1 better than v0 and v2 better than v1, then v2 better than v0.
Used in Section C.3 for transitive comparison. Logically sound but only as sound as the direct-comparison premise.

how reviews work

0 comments

Cite this review

Pith. "Pith review of EvoGit: Decentralized Code Evolution via Git-Based Multi-Agent Collaboration." pith.science (2026). https://pith.science/paper/6H4N2DCA

@misc{pith2026250602049,
  author       = {Pith},
  title        = {Pith review of: EvoGit: Decentralized Code Evolution via Git-Based Multi-Agent Collaboration},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6H4N2DCA}},
  note         = {Machine review of arXiv:2506.02049}
}

read the original abstract

We introduce EvoGit, a decentralized multi-agent framework for collaborative software development driven by autonomous code evolution. EvoGit deploys a population of independent coding agents, each proposing edits to a shared codebase without centralized coordination, explicit message passing, or shared memory. Instead, all coordination emerges through a Git-based phylogenetic graph that tracks the full version lineage and enables agents to asynchronously read from and write to the evolving code repository. This graph-based structure supports fine-grained branching, implicit concurrency, and scalable agent interaction while preserving a consistent historical record. Human involvement is minimal but strategic: users define high-level goals, periodically review the graph, and provide lightweight feedback to promote promising directions or prune unproductive ones. Experiments demonstrate EvoGit's ability to autonomously produce functional and modular software artifacts across two real-world tasks: (1) building a web application from scratch using modern frameworks, and (2) constructing a meta-level system that evolves its own language-model-guided solver for the bin-packing optimization problem. Our results underscore EvoGit's potential to establish a new paradigm for decentralized, automated, and continual software development. EvoGit is open-sourced at https://github.com/BillHuang2001/evogit.

Figures

Figures reproduced from arXiv: 2506.02049 by the authors.

**Figure 2.** Overview of the EvoGit methodology. (a) EvoGit comprises two types of participants: a [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** Snapshots from the web development process by EvoGit (Task 1). (a) Early stage: broken [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗

Figures from the paper (7 more)

**Figure 4.** Figure 4: Schematic of meta-level code synthesis (Task 2). EvoGit is used to develop a program that [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]

**Figure 5.** Figure 5: Partial order ⪯ over code versions. Each node denotes a version, and edges represent ancestry. (a) Branching: v1 and v2 are incomparable, thus both are considered current best versions. (b) Three-way merge: vo is created by recombining v1 and v2 with respect to their l…

**Figure 6.** Figure 6: Illustration of the mutation and three-way crossover operations in EvoGit. (a) Mutation: [PITH_FULL_IMAGE:figures/full_fig_p013_6.png]

**Figure 7.** Figure 7: Distributed code evolution in EvoGit. Traditional workflows rely on linear, sequential [PITH_FULL_IMAGE:figures/full_fig_p015_7.png]

**Figure 8.** Figure 8: Screenshot of the GitHub commit history, showing a sequence of commits generated au [PITH_FULL_IMAGE:figures/full_fig_p020_8.png]

**Figure 9.** Figure 9: Screenshot of GitHub’s diff view, illustrating a specific code modification made by an [PITH_FULL_IMAGE:figures/full_fig_p020_9.png]

**Figure 10.** Figure 10: Screenshot of the GitHub network graph, visualizing the entire version history as a di [PITH_FULL_IMAGE:figures/full_fig_p020_10.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Code Is the Body: Agent-Owned Software Bodies for Recursive Evolution and Descent
cs.SE 2026-07 accept novelty 5.0 of 10

OurArk makes a personal agent's code, prompts, and policies into a versioned body under user control, enabling governed self-evolution and recursive descent into new agent instances.

Reference graph

Works this paper leans on

22 extracted references · 6 canonical work pages · cited by 1 Pith paper

[1]

write newline

" write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 global.max substring 't := if while FUNCTION format.date year duplicate empty "emp...
[2]

Meta GPT : Meta programming for a multi-agent collaborative framework

Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and J \"u rgen Schmidhuber. Meta GPT : Meta programming for a multi-agent collaborative framework. In The Twelfth International Conference on Learning Representatio...

2024
[3]

Mapcoder: Multi-agent code generation for competitive problem solving

Md Ashraful Islam, Mohammed Eunus Ali, and Md Rizwan Parvez. Mapcoder: Multi-agent code generation for competitive problem solving. arXiv preprint arXiv:2405.11403, 2024

arXiv 2024
[4]

Evolution through large models

Joel Lehman, Jonathan Gordon, Shawn Jain, Kamal Ndousse, Cathy Yeh, and Kenneth O Stanley. Evolution through large models. In Handbook of Evolutionary Machine Learning, pp.\ 331--366. Springer, 2023

work page 2023
[5]

Evolution of heuristics: Towards efficient automatic algorithm design using large language model

Fei Liu, Xialiang Tong, Mingxuan Yuan, Xin Lin, Fu Luo, Zhenkun Wang, Zhichao Lu, and Qingfu Zhang. Evolution of heuristics: Towards efficient automatic algorithm design using large language model. In Proceedings of the 41st International Conference on Machine Learning, pp.\ 1--9, 2024

work page 2024
[6]

Large Language Models : A Survey , February 2024

Shervin Minaee, Tomas Mikolov, Narjes Nikzad, Meysam Chenaghlu, Richard Socher, Xavier Amatriain, and Jianfeng Gao. Large Language Models : A Survey , February 2024. URL http://arxiv.org/abs/2402.06196. arXiv:2402.06196 [cs]

arXiv 2024
[7]

GPT -4 Technical Report , March 2024

OpenAI, Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, Red Avila, et al. GPT -4 Technical Report , March 2024. URL http://arxiv.org/abs/2303.08774. arXiv:2303.08774 [cs]

arXiv 2024
[8]

Chatdev: Communicative agents for software development

Chen Qian, Wei Liu, Hongzhang Liu, Nuo Chen, Yufan Dang, Jiahao Li, Cheng Yang, Weize Chen, Yusheng Su, Xin Cong, Juyuan Xu, Dahai Li, Zhiyuan Liu, and Maosong Sun. Chatdev: Communicative agents for software development. arXiv preprint arXiv:2307.07924, 2023. URL https://arxiv.org/abs/2307.07924

arXiv 2023

Show all 22 references

[9]

Mathematical discoveries from program search with large language models

Bernardino Romera-Paredes, Mohammadamin Barekatain, Alexander Novikov, Matej Balog, M Pawan Kumar, Emilien Dupont, Francisco JR Ruiz, Jordan S Ellenberg, Pengming Wang, Omar Fawzi, et al. Mathematical discoveries from program search with large language models. Nature, pp.\ 1--3, 2023

2023
[10]

Evolving neural networks through augmenting topologies

Kenneth O Stanley and Risto Miikkulainen. Evolving neural networks through augmenting topologies. Evolutionary computation, 10 0 (2): 0 99--127, 2002

2002
[11]

Stanley, Jeff Clune, Joel Lehman, and Risto Miikkulainen

Kenneth O. Stanley, Jeff Clune, Joel Lehman, and Risto Miikkulainen. Designing neural networks through neuroevolution. Nature Machine Intelligence, 1 0 (1): 0 24--35, 2019

2019
[12]

Dai, Anja Hauth, Katie Millican, David Silver, Slav Petrov, Melvin Johnson, Ioannis Antonoglou, Julian Schrittwieser, Amelia Glaese, Jilin Chen, et al

Gemini Team, Rohan Anil, Sebastian Borgeaud, Yonghui Wu, Jean-Baptiste Alayrac, Jiahui Yu, Radu Soricut, Johan Schalkwyk, Andrew M. Dai, Anja Hauth, Katie Millican, David Silver, Slav Petrov, Melvin Johnson, Ioannis Antonoglou, Julian Schrittwieser, Amelia Glaese, Jilin Chen, ...

2023 arXiv
[13]

A Survey on Large Language Model based Autonomous Agents

Lei Wang, Chen Ma, Xueyang Feng, Zeyu Zhang, Hao Yang, Jingsen Zhang, Zhiyuan Chen, Jiakai Tang, Xu Chen, Yankai Lin, Wayne Xin Zhao, Zhewei Wei, and Ji-Rong Wen. A Survey on Large Language Model based Autonomous Agents . Frontiers of Computer Science, 18 0 (6): 0 186345, Dece...

2024 arXiv
[14]

The rise and potential of large language model based agents: A survey, 2023

Zhiheng Xi, Wenxiang Chen, Xin Guo, Wei He, Yiwen Ding, Boyang Hong, Ming Zhang, Junzhe Wang, Senjie Jin, Enyu Zhou, Rui Zheng, Xiaoran Fan, Xiao Wang, Limao Xiong, Yuhao Zhou, Weiran Wang, Changhao Jiang, Yicheng Zou, Xiangyang Liu, Zhangyue Yin, Shihan Dou, Rongxiang Weng, W...

2023
[15]

Qwen2 Technical Report , July 2024 a

An Yang, Baosong Yang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Zhou, Chengpeng Li, Chengyuan Li, Dayiheng Liu, Fei Huang, Guanting Dong, Haoran Wei, Huan Lin, Jialong Tang, Jialin Wang, Jian Yang, Jianhong Tu, Jianwei Zhang, Jianxin Ma, Jianxin Yang, Jin Xu, Jingren Zhou, Jinze...

2024 arXiv
[16]

Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press

John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. SWE -agent: Agent - Computer Interfaces Enable Automated Software Engineering , November 2024 b . URL http://arxiv.org/abs/2405.15793. arXiv:2405.15793 [cs]

2024 arXiv
[17]

ReAct : Synergizing reasoning and acting in language models

Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. ReAct : Synergizing reasoning and acting in language models. In International Conference on Learning Representations (ICLR), 2023

2023
[18]

Reevo: Large language models as hyper-heuristics with reflective evolution

Haoran Ye, Jiarui Wang, Zhiguang Cao, and Guojie Song. Reevo: Large language models as hyper-heuristics with reflective evolution. arXiv preprint arXiv:2402.01145, 2024

2024 arXiv
[19]

A Survey of Large Language Models , November 2023

Wayne Xin Zhao, Kun Zhou, Junyi Li, Tianyi Tang, Xiaolei Wang, Yupeng Hou, Yingqian Min, Beichen Zhang, Junjie Zhang, Zican Dong, Yifan Du, Chen Yang, Yushuo Chen, Zhipeng Chen, Jinhao Jiang, Ruiyang Ren, Yifan Li, Xinyu Tang, Zikang Liu, Peiyu Liu, Jian-Yun Nie, and Ji-Rong W...

2023 arXiv
[20]

@esa (Ref

\@ifxundefined[1] #1\@undefined \@firstoftwo \@secondoftwo \@ifnum[1] #1 \@firstoftwo \@secondoftwo \@ifx[1] #1 \@firstoftwo \@secondoftwo [2] @ #1 \@temptokena #2 #1 @ \@temptokena \@ifclassloaded agu2001 natbib The agu2001 class already includes natbib coding, so you should ...
[21]

\@lbibitem[] @bibitem@first@sw\@secondoftwo \@lbibitem[#1]#2 \@extra@b@citeb \@ifundefined br@#2\@extra@b@citeb \@namedef br@#2 \@nameuse br@#2\@extra@b@citeb \@ifundefined b@#2\@extra@b@citeb @num @parse #2 @tmp #1 NAT@b@open@#2 NAT@b@shut@#2 \@ifnum @merge>\@ne @bibitem@firs...
[22]

@open @close @open @close and [1] URL: #1 \@ifundefined chapter * \@mkboth \@ifxundefined @sectionbib * \@mkboth * \@mkboth\@gobbletwo \@ifclassloaded amsart * \@ifclassloaded amsbook * \@ifxundefined @heading @heading NAT@ctr thebibliography [1] @ \@biblabel @NAT@ctr \@bibset...

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

write newline

" write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 global.max substring 't := if while FUNCTION format.date year duplicate empty "emp...

[2] [2]

Meta GPT : Meta programming for a multi-agent collaborative framework

Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and J \"u rgen Schmidhuber. Meta GPT : Meta programming for a multi-agent collaborative framework. In The Twelfth International Conference on Learning Representatio...

2024

[3] [3]

Mapcoder: Multi-agent code generation for competitive problem solving

Md Ashraful Islam, Mohammed Eunus Ali, and Md Rizwan Parvez. Mapcoder: Multi-agent code generation for competitive problem solving. arXiv preprint arXiv:2405.11403, 2024

arXiv 2024

[4] [4]

Evolution through large models

Joel Lehman, Jonathan Gordon, Shawn Jain, Kamal Ndousse, Cathy Yeh, and Kenneth O Stanley. Evolution through large models. In Handbook of Evolutionary Machine Learning, pp.\ 331--366. Springer, 2023

work page 2023

[5] [5]

Evolution of heuristics: Towards efficient automatic algorithm design using large language model

Fei Liu, Xialiang Tong, Mingxuan Yuan, Xin Lin, Fu Luo, Zhenkun Wang, Zhichao Lu, and Qingfu Zhang. Evolution of heuristics: Towards efficient automatic algorithm design using large language model. In Proceedings of the 41st International Conference on Machine Learning, pp.\ 1--9, 2024

work page 2024

[6] [6]

Large Language Models : A Survey , February 2024

Shervin Minaee, Tomas Mikolov, Narjes Nikzad, Meysam Chenaghlu, Richard Socher, Xavier Amatriain, and Jianfeng Gao. Large Language Models : A Survey , February 2024. URL http://arxiv.org/abs/2402.06196. arXiv:2402.06196 [cs]

arXiv 2024

[7] [7]

GPT -4 Technical Report , March 2024

OpenAI, Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, Red Avila, et al. GPT -4 Technical Report , March 2024. URL http://arxiv.org/abs/2303.08774. arXiv:2303.08774 [cs]

arXiv 2024

[8] [8]

Chatdev: Communicative agents for software development

Chen Qian, Wei Liu, Hongzhang Liu, Nuo Chen, Yufan Dang, Jiahao Li, Cheng Yang, Weize Chen, Yusheng Su, Xin Cong, Juyuan Xu, Dahai Li, Zhiyuan Liu, and Maosong Sun. Chatdev: Communicative agents for software development. arXiv preprint arXiv:2307.07924, 2023. URL https://arxiv.org/abs/2307.07924

arXiv 2023