AI4AI: Toward AI-Discovered Superintelligence

1. Introduction

The development of artificial intelligence (AI) has traditionally been guided by human researchers. They decide what kinds of solutions to explore, which experiments to conduct, and how to evaluate the results. As AI systems and design spaces grew more complex, this fully human-directed process became a scalability bottleneck: too many consequential research decisions still depended on limited human attention and manual experimentation.

Early automation began to relieve this bottleneck by automating candidate search, but it did not fundamentally change who controlled the research process. Hyperparameter optimization, AutoML, and neural architecture search replaced manual trial-and-error with systematic exploration of model configurations, development pipelines, and architectures [1,2,3,4,5,6]. Subsequent advances extended automation beyond model selection to the learning process itself, enabling systems to adapt training schedules, learn optimization rules, and even discover complete learning algorithms from primitive operations [7,8,9]. More recently, systems such as FunSearch and AlphaEvolve have demonstrated the discovery and improvement of executable algorithms and programs [10,11], while language-model-based approaches have made prompts and agent architectures objects of automated optimization [12,13,14]. Across these developments, the scope of automation has expanded from selecting numerical configurations to modifying increasingly complex artifacts. Yet this growing flexibility does not necessarily imply greater research autonomy: humans may still determine the problems to solve, the boundaries of allowable modifications, and the criteria for success.

Automation is now extending beyond individual AI artifacts to the research process itself. Systems such as The AI Scientist and The AI Scientist-v2 integrate idea generation, experimentation, and reporting into increasingly automated research workflows [15,16]. In parallel, AI is taking a more active role in evaluation, generating feedback that guides subsequent improvements. Constitutional AI and RLAIF use model-generated critiques or preferences to guide training [17,18]; Eureka synthesizes executable reward functions [19]; and self-rewarding language models use their own judgments to guide further training [20]. Although these approaches often operate under human-defined objectives, AI-generated feedback can influence which candidates are selected and how models are improved. This growing role creates opportunities for more adaptive discovery, while underscoring the importance of independent validation, as model-generated judgments can be biased and improvements under imperfect reward signals may not translate into genuine progress [21,22,23]. Together, these developments show that automating a research workflow and controlling its key decisions are fundamentally different. An AI system may execute an entire research workflow while humans still determine which problems to pursue, what can be modified, and what counts as success. Conversely, AI may construct or substantively revise the evaluation signal that governs candidate selection, even when humans carry out the experiments and implement the changes. Research autonomy should therefore be characterized by which decisions AI makes or revises, rather than by how many research tasks it executes.

Figure 1. The progressive transfer of control over the AI4AI discovery loop.

Figure 1. The progressive transfer of control over the AI4AI discovery loop.

These developments reflect the growing field of AI for AI (AI4AI), in which AI contributes to the development and improvement of AI systems themselves. Yet despite its rapid expansion, how control over the discovery process is distributed between humans and AI remains insufficiently characterized. To address this gap, we view AI development as a discovery loop in which candidate improvements are proposed, evaluated, and selected or revised based on feedback. We distinguish three key decisions in this loop: search direction (D), which determines which avenues to pursue; search space (S), which defines what can be changed; and evaluation signal (E), which determines what counts as progress.

Existing taxonomies typically organize AI4AI research by technique or target artifact. While useful for mapping the field, they do not fully capture how responsibility for these decisions is divided between humans and AI. Indeed, systems that improve similar AI artifacts may differ fundamentally in which decisions they control. This motivates the central perspective of our survey:

Identifying these three decisions is only the first step; understanding research autonomy also requires determining who actually controls them. Generating candidate solutions does not mean deciding where to explore, just as running an evaluation does not mean defining what counts as success. We therefore attribute control to AI only when it originates or substantively revises a decision that shapes the subsequent discovery process.

To characterize how these responsibilities are distributed between humans ($\mathrm{H}$) and AI ($\mathrm{A}$), we assign each system a responsibility profile:

$$\mathbf{a}=\langle a_D,a_S,a_E\rangle ,a_i\in \{\mathrm{H},\mathrm{A}\},$$

(1)

where the coordinates indicate whether each decision is human-specified or externally fixed, or substantively AI-provided. Based on the responsibility profile, we distinguish four control-source levels, where $*\in \{\mathrm{H},\mathrm{A}\}$ denotes either source:

• L0 ($\langle \mathrm{H},\mathrm{H},\mathrm{H}\rangle$): Humans provide all three decisions, serving as the reference case.
• L1 ($\langle \mathrm{A},\mathrm{H},\mathrm{H}\rangle$): AI provides the search direction, while the search space and evaluation remain human-defined.
• L2 ($\langle *,\mathrm{A},\mathrm{H}\rangle$): AI constructs or substantively revises the search space, while evaluation remains human-defined.
• L3 ($\langle *,*,\mathrm{A}\rangle$): AI provides or substantively revises the evaluation signal, regardless of who determines direction or space.

Levels are assigned by the precedence $E>S>D$, which determines the classification label rather than implying cumulative autonomy or greater capability. The level label provides a concise classification, while the full responsibility profile preserves how control over direction, space, and evaluation is distributed between humans and AI.

The ladder captures the source of research control rather than the extent of automation or a system’s overall capability. For example, FunSearch and AlphaEvolve guide program search using evaluation histories while operating within human-defined edit boundaries and evaluators [10,11]. Similarly, The AI Scientist and the Darwin Gödel Machine automate research or self-revision processes without necessarily controlling the underlying search space or success criteria [15,24]. These distinctions matter because greater control does not guarantee better outcomes: AI may pursue ineffective directions, construct unproductive search spaces, or generate evaluation signals that reward misleading improvements. Independent validation is therefore essential, especially when AI helps determine what counts as progress.

Our main contributions are threefold. First, we synthesize AI4AI research through the lens of control over discovery decisions, offering a unified perspective on techniques and applications that are otherwise fragmented. Second, we formalize this perspective in a Direction–Space–Evaluation framework that pairs L0–L3 control-source levels with full responsibility profiles, distinguishing the different forms of human–AI research responsibility without conflating them with end-to-end autonomy. Third, we identify key open questions and outline promising directions for future research.

2. Key Concepts and Related Surveys

2.1. Key Concepts

AI4AI.

Artificial intelligence for artificial intelligence (AI4AI) refers to the use of AI models or feedback-driven search to discover and improve AI systems and their development processes. Within the broader landscape of AI for Science, AI4AI specifically targets the advancement of AI itself. A defining requirement is that AI substantively contributes to discovery rather than merely executing a predetermined workflow.

Automated Machine Learning.

Automated machine learning (AutoML) automates the optimization of model configurations, architectures, learning algorithms, and training pipelines, typically within human-defined search spaces and evaluation criteria [4,25,26]. It provides an important foundation for AI4AI by replacing manual design choices with systematic search.

AI Scientists.

AI scientists extend automation from individual optimization tasks to broader research processes, including hypothesis generation, experiment design, implementation, analysis, and reporting [27,28,29]. Such systems fall within AI4AI when their research aims to improve AI systems or the processes used to develop them.

Self-Evolving AI.

Self-evolving AI systems improve their own parameters, instructions, memories, tools, or behaviors through feedback and accumulated experience [30,31,32,33]. However, self-modification does not necessarily imply control over the improvement process, as humans may still define the objectives, allowable changes, and evaluation criteria.

Recursive Self-Improvement.

Recursive self-improvement (RSI) refers to a process in which improvements to an AI system enhance its ability to produce further improvements [34]. Unlike repeated optimization of a fixed target, RSI requires improvements to the discovery mechanism itself. Demonstrating RSI therefore requires sustained gains in subsequent improvement cycles under independent evaluation. Such gains may provide a path toward superintelligence, although sustained recursive improvement remains an open challenge.

Search Direction.

The search direction (D) determines which possibilities to pursue within a search space, such as which bottleneck to address, hypothesis to test, or candidate region to explore. It guides the allocation of exploration effort based on research objectives and previous results.

Search Space.

The search space (S) defines the set of admissible solutions through editable components, candidate representations, available operations, and constraints. It determines what can be explored, while generating candidates within a predefined space does not itself constitute control over that space.

Evaluation Signal.

The evaluation signal (E) determines what counts as progress through metrics, tests, rewards, or acceptance criteria that guide candidate selection. Applying a predefined evaluation rule does not imply control over the criteria themselves. Together, D, S, and E provide three distinct dimensions for characterizing how control over AI discovery is distributed between humans and AI.

Figure 2 brings together these three control variables and shows how evidence connects candidate generation, evaluation, updating, and iterative improvement.

2.2. Related Surveys

Existing surveys offer detailed accounts of automated optimization, evolving agents, autonomous research, and the artifacts produced by these systems. However, these research traditions focus on different aspects of AI-driven progress. Table 1 groups existing surveys into five lenses accordingly. We summarize how each lens understands the field, identify the limitation they share, and explain the different starting point of this survey.

Perspectives in existing surveys.

Search-centric surveys, spanning AutoML, neural architecture search, meta-learning, and LLM-based algorithm design, organize methods around the representations being searched, the optimization strategy, and the procedure for estimating candidate quality [25,36,40]. This decomposition is valuable for explaining how search works, but does not necessarily track whether those components are specified by humans or constructed by AI. Self-evolution surveys instead ask what can be updated, when adaptation occurs, and which feedback mechanisms support it [31,32,33]. Research-lifecycle surveys emphasize the integration of ideation, experimentation, review, and reporting into increasingly automated workflows [28,29,47]. Component-oriented reviews examine particular technologies, such as model judges, data selection, and electronic design automation [50,53,56]. Finally, work on recursive improvement and levels of intelligence or agent autonomy offers broader conceptual accounts of independence and capability [34,58,59]. These perspectives address distinct, legitimate questions; their limitation for our purpose is the absence of a common unit for attributing consequential research decisions across all four AI4AI artifact families. The perspectives differ in axis but share one limitation: they describe what AI does rather than what it decides. As Table 1 shows, each lens brings at most one of the three decisions in the AI4AI discovery loop into focus.

Positioning of this survey.

We begin from a different premise on who holds the authority to decide. A discovery process depends on three decisions: which directions to explore, what solutions can be considered, and how progress is evaluated. Existing surveys typically organize AI4AI systems by their techniques, outputs, or workflows. While useful, these approaches often overlook changes in who controls the research process. We therefore view the development of AI4AI through the transfer of three key decisions from humans to AI: search direction, search space, and evaluation signal. These transfers represent a progression in research control: from choosing what to explore, to defining what can be explored, and ultimately to determining what counts as progress. This perspective also provides a common way to compare different AI4AI systems. A hyperparameter optimizer, a kernel-search agent, and an AI scientist can all be assessed by the decisions they control, regardless of their underlying techniques. Claims of research autonomy should therefore be supported by evidence of who makes each decision, rather than by how much of the research workflow is automated.

3. Preliminaries

This section establishes the formal framework for analyzing and classifying AI4AI systems. We first formalize the discovery process, then examine the provenance of its three control decisions: search direction (D), search space (S), and evaluation signal (E). Based on these decisions, we introduce responsibility profiles and a protocol for assigning L0–L3 levels. The levels follow a classification precedence of $E>S>D$, rather than representing an ordinal scale of intelligence, capability, or autonomy. Table 2 summarizes the notation.

3.1. The AI4AI Discovery Process

We assess control provenance at the level of individual system configurations, rather than assigning fixed control responsibilities to models or methods. Each configuration is characterized by its target AI artifact, search procedure, editable boundaries, available tools, evaluator, and human-intervention policy. This scope encompasses classical AutoML and neural architecture search [4,25], as well as more recent AI4AI applications such as visual-token pruning and test-time capability transfer [60,61].

Under our operational criterion, a system qualifies as AI4AI when an AI model or feedback-adaptive search procedure originates or substantively revises at least one control decision (D, S, or E), and that decision causally influences candidate generation, selection, updating, or acceptance. Merely executing a predefined workflow or applying a fixed evaluation rule does not, by itself, establish such control. Consequently, the same model or method may assume different control responsibilities depending on its specific configuration.

Three boundary conditions follow. Generic AI-assisted coding is included only when the generated code changes the target AI artifact or discovery procedure; code that merely implements a human-fixed design is excluded. AI for science is adjacent but not automatically AI4AI: a mathematical or scientific discovery enters scope only when the resulting artifact or discovery mechanism materially contributes to AI development. Automated experimentation is likewise insufficient when the experiment plan, editable objects, and acceptance criteria remain human-authored. Benchmarks for algorithmic design are especially informative because they test whether an agent can alter learning procedures rather than only tune familiar parameters [62]. The unit of analysis is a demonstrated configuration: the model and software versions, prompts, tools, data, search budget, evaluator, orchestration, random seeds, and human-intervention policy used in a particular result. The same model can therefore receive different profiles in different configurations. A language model may construct an evaluator in one loop but merely execute a human rubric in another. We consequently do not assign an intrinsic level to a foundation model, method name, or paper title.

Let $x_t$ denote the target AI system at discovery cycle t, $h_t$ the accumulated research history, and $B_t$ the available resource budget. A discovery cycle is written as

$$\begin{array}{cc}\hfill S_t& =P_S(x_t,h_t),\hfill \end{array}$$

(2)

$$\begin{array}{cc}\hfill D_t& =P_D(x_t,h_t,S_t),\hfill \end{array}$$

(3)

$$\begin{array}{cc}\hfill {\mathcal{C}}_t& =G_t(S_t,D_t;B_t)={\left\{c_{t,i}\right\}}_{i=1}^{n_t},\hfill \end{array}$$

(4)

$$\begin{array}{cc}\hfill q_{t,i}& =E_t(c_{t,i},x_t,S_t,D_t),i=1,\dots ,n_t,\hfill \end{array}$$

(5)

$$\begin{array}{cc}\hfill {\mathbf{q}}_t& =(q_{t,1},\dots ,q_{t,n_t}),\hfill \end{array}$$

(6)

$$\begin{array}{cc}\hfill x_{t+1}& =U_t(x_t,{\mathcal{C}}_t,{\mathbf{q}}_t),\hfill \end{array}$$

(7)

$$\begin{array}{cc}\hfill h_{t+1}& =H_t(h_t,{\mathcal{C}}_t,{\mathbf{q}}_t).\hfill \end{array}$$

(8)

The procedure $P_S$ first specifies the editable objects, admissible candidates, constraints, and operators. Conditioned on $S_t$, $P_D$ determines how the system should search inside that space. The generator $G_t$ realizes a candidate set ${\mathcal{C}}_t$, the evaluator $E_t$ produces candidate-level evidence ${\mathbf{q}}_t$, the updater $U_t$ executes the selection or update implied by that evidence, and $H_t$ records the history used by later cycles. Selection, aggregation, thresholds, and stopping rules that determine acceptance belong to the evaluation signal; $U_t$ only executes those decisions. Resource allocation within a fixed evaluation protocol may be part of $D_t$, whereas a learned or revised pruning, acceptance, or stopping criterion is part of $E_t$. If an approval or update rule in $U_t$ changes operative acceptance, that change is recorded as part of E or as residual human control. Each procedure may be implemented by people, algorithms, learned models, or hybrids.

For the schematic batch cycle used here, the main dependency is

$$S⟶D⟶\mathcal{C}⟶E.$$

(9)

This arrow is a batch-processing abstraction that separates the space, direction, candidate, and evaluation roles; it is not a strict temporal law for every system. Online systems may instead revise $S_t$ and $D_t$ alternately as new evidence arrives. Each procedure may be human-provided, AI-provided, or jointly specified, and the source of one procedure does not determine the sources of the others. Hyperparameter optimization can generate thousands of configurations under a human-defined task, domain, and metric [1,2,3]; program search can produce novel solutions while retaining a human-provided problem and executable evaluator [10,11]. Operational scale therefore does not by itself establish responsibility for the discovery loop.

3.2. Search-Space Provision

The search space $S_t$ defines where to explore and what the candidates can be. It contains the editable objects, their representation, admissible primitives, constraints, and operators that transform one candidate into another. It is distinct from the realized set ${\mathcal{C}}_t$: sampling or generating candidates from a fixed human-provided space does not amount to constructing that space. L2 control requires AI to substantively construct or revise at least one defining component of $S_t$, such as the representation, primitive library, legal operators, or validity constraints.

Neural architecture search illustrates this distinction. Reinforcement learning, regularized evolution, and differentiable relaxation search architectures effectively, but their results remain conditioned on human-designed operator spaces and validation objectives [5,6,63]. Population-based training adapts schedules within a chosen setup [7]; learned optimization and meta-learning broaden the editable learning process while retaining human-selected task distributions and meta-objectives [8,64].

Later work increases the expressive depth of $S_t$. AutoML-Zero composes learning algorithms from primitive mathematical operations [9], while evolved reinforcement-learning losses treat computational graphs as candidate learning rules [65]. AlphaTensor and AlphaDev search algorithmic and assembly-level representations [66,67]. Language models make instructions, critiques, and programs editable: APE, ProTeGi, OPRO, and Promptbreeder search or evolve prompts [12,13,68,69]; Eureka generates reward programs, which belong to $E_t$ rather than $S_t$ [19]; Automated Design of Agentic Systems searches agent scaffolds [14]; and STOP and the Darwin Gödel Machine modify improver or agent code over repeated cycles [24,70]. These examples are not automatically L2: a method receives L2 only when the demonstrated configuration makes the search space substantively AI-provided while $E_t$ remains human- or externally provided. If $E_t$ is AI-controlled, the precedence rule assigns L3 and the AI-provided space remains in the full profile. In the cited configurations, prompt- and agent-code systems remain L1 direction-selection systems when $E_t$ is fixed; a variant becomes L2 if AI also changes the representation, primitive library, legal operators, or validity constraints that define $S_t$. Reward-program systems such as Eureka are classified by their control of $E_t$ and may be L3.

3.3. Direction Selection Within a Search Space

The search direction $D_t$ defines how to explore within $S_t$. It may specify a capability gap to address, failure to diagnose, bottleneck to remove, research question to pose, or hypothesis to test. Direction is not merely a textual idea: it must causally change which interventions are generated, prioritized, or tested within the available space. A direction is AI-provided only when the configuration gives AI substantive responsibility for selecting or revising that direction in response to the target and its accumulated evidence.

Literature-grounded ideation systems begin to operationalize this responsibility by proposing and revising research questions [71]. Experimentation benchmarks test whether agents can convert observations into subsequent plans [72]. The AI Scientist and AI Scientist-v2 combine ideation with implementation and reporting, whereas Agent Laboratory organizes literature review, experimentation, and reporting from a human-provided idea [15,16,73]. A generated proposal counts as AI-provided direction only when it is more than a restatement of the human prompt and when changing that proposal would materially change the ensuing search.

The dependence $D_t=P_D(x_t,h_t,S_t)$ is important. A direction is meaningful only relative to the interventions that the current space permits. A human may specify the direction while AI constructs a new search space for pursuing it, producing an L2 profile such as $\langle \mathrm{H},\mathrm{A},\mathrm{H}\rangle$. Conversely, AI may identify a direction while people retain the editable space and evaluator, producing the L1 profile $\langle \mathrm{A},\mathrm{H},\mathrm{H}\rangle$.

3.4. Evaluation as the Feedback Signal

The evaluation signal $E_t$ defines what counts as progress. It may include metrics, tests, verifiers, reward models, critics, statistical protocols, cost models, aggregation rules, and stopping conditions. A fixed human-authored rubric or benchmark remains externally fixed even when a model executes it; producing a score under that fixed criterion is not by itself AI control of $E_t$. L3 requires AI to generate or substantively revise an operative component of $({\mathcal{T}}_t,J_t,A_t,{\tau }_t)$—for example, a test distribution, judgment mapping, aggregation rule, or stopping condition—and that component must govern candidate selection, training, resource allocation, or acceptance in the discovery loop.

Human-preference learning converts judgments into trainable rewards [74], while process supervision assigns credit to intermediate reasoning steps [75]. Constitutional AI and RLAIF transfer parts of critique and preference production to models while retaining human-authored principles, prompts, or targets [17,18]. LLM-as-a-judge systems make open-ended evaluation scalable but introduce position and verbosity biases [21], as well as self-preference bias when a model favors its own outputs or identity [22]; self-rewarding models further couple improvement and reward production [20].

Evaluation control is identified by provenance; independence is a quality check on the resulting signal rather than a prerequisite for the L3 label. Self-feedback methods such as Self-Refine and Reflexion can provide useful feedback while leaving the criterion externally specified in the cited configurations [76,77]. L3 requires AI to construct or substantively revise the operative criterion, but it does not require AI-provided direction or search space. Such signals should be tested under optimization pressure because maximizing an imperfect proxy can eventually reduce performance under an independent reference metric [23].

3.5. Responsibility Profiles and Control Strength

For each control variable $i\in \{D,S,E\}$, let $a_i\in \{\mathrm{H},\mathrm{A}\}$ denote whether the demonstrated configuration treats the operative decision as human- or AI-provided. The binary responsibility profile is

$$\mathbf{a}=\langle a_D,a_S,a_E\rangle .$$

(10)

Here $\mathrm{H}$ denotes human-authored or externally fixed, non-AI-originated control, while $\mathrm{A}$ denotes AI-originated substantive control. A fixed model that only executes a human-authored rubric or benchmark remains an external implementation; a learned or generated mapping is AI-provided only when it has operative authority and passes the counterfactual test. A shared or partial component is recorded separately in the provenance audit and control-strength vector; it receives $a_i=\mathrm{A}$ when the AI component originates or revises the operative decision and changes the downstream loop, even if a human anchor remains. The profile records information that a single level label suppresses. A program-search system with a human problem, AI-provided program space, and human executable evaluator has profile $\langle \mathrm{H},\mathrm{A},\mathrm{H}\rangle$ and is L2. A system whose AI constructs the operative evaluation signal for human-selected candidates may have profile $\langle \mathrm{H},\mathrm{H},\mathrm{A}\rangle$ and is L3. A shared decision should not be rounded up to full AI control without evidence; its mixed provenance must be recorded in the accompanying audit and, where useful, in the control-strength vector. Neither representation should be read as end-to-end AI control.

Binary labels conceal shared control. We therefore also recommend a descriptive control-strength vector

$$\mathbf{r}=\langle r_D,r_S,r_E\rangle ,r_i\in [0,1],$$

(11)

where $r_i$ summarizes the degree of AI responsibility. This vector is a reporting aid rather than a validated scalar metric or a threshold for assigning L0–L3. Evidence for a high value should cover four properties:

• Origination: AI produces substantive content not explicitly supplied by a human specification;
• Task specificity: the decision adapts to evidence from the present target rather than replaying a generic template;
• Causal efficacy: changing the AI-produced decision changes candidate generation, selection, or the resulting artifact; and
• Revisability: the system can update the decision when feedback reveals that it is ineffective or invalid.

These conditions distinguish substantive control from transcription, execution, or superficial linguistic variation. They also prevent a system from receiving credit for a nominally AI-generated component that the actual search trajectory ignores.

3.6. The Control-Source Ladder, Assignment, and Reporting

The three variables connect through the operational source of control. The resulting labels identify the focal AI-provided variable; they do not assign provenance to every other component. Because a configuration can combine human and AI sources across the three variables, the label is assigned by a fixed precedence rule rather than by an assumption that later labels are more autonomous.

L0. 

Human-authored or externally fixed discovery loop. Humans or external fixed procedures provide the search space, select the direction within it, and define the evaluation signal. Computation may execute training or measurement, but none of the three control variables is originated or substantively revised by AI. L0 is the human-controlled reference profile.

L1. 

AI-provided search direction. AI determines how to explore, while people or external fixed procedures still provide the search space and evaluation signal. Typical evidence includes target-specific bottleneck diagnosis, hypothesis generation, or direction prioritization that causally changes the ensuing research plan. This label applies only when S and E remain human-authored or externally fixed.

L2. 

AI-provided search space. AI determines where exploration occurs and which candidate interventions become available, while evaluation remains human-authored or externally fixed. The direction may be human- or AI-provided, so both $\langle \mathrm{H},\mathrm{A},\mathrm{H}\rangle$ and $\langle \mathrm{A},\mathrm{A},\mathrm{H}\rangle$ are L2.

L3. 

AI-provided evaluation signal. AI constructs or substantively revises what counts as progress. Direction and space may be human- or AI-provided; equivalently, L3 includes every profile with $a_E=\mathrm{A}$. Only $\langle \mathrm{A},\mathrm{A},\mathrm{A}\rangle$ places all three control variables under AI control.

A label identifies a different source of operational control, not a greater degree of intelligence, usefulness, reliability, or alignment. We assign one label using the precedence $E>S>D$: if $a_E=\mathrm{A}$, assign L3; otherwise, if $a_S=\mathrm{A}$, assign L2; otherwise, if $a_D=\mathrm{A}$, assign L1; assign L0 only when all three coordinates are human-authored or externally fixed. The full profile must accompany the label whenever the remaining allocation of control matters.

Level assignment and reporting.

We use the following protocol when coding a paper or system:

• Fix the unit of analysis. Record the exact model and software versions, prompts, tools, orchestration, dataset, budget, evaluator version, random seeds, and human-intervention policy.
• Trace provenance. For D, S, and E, identify the source of the operative decision in the reported configuration. Separate human-authored constraints from AI-originated choices within those constraints, and distinguish a human seed from an AI revision that changes the decision used by the loop. If an AI component changes the operative accept/reject decision while a human anchor remains, code the coordinate as AI-provided and record the anchor separately.
• Apply the counterfactual test. Ask whether removing or changing the AI-produced component would materially alter the downstream search trajectory. If not, the component does not establish control.
• Test adaptation and revision. Record whether the system changes the decision in response to target-specific evidence and whether it can recover when that decision proves misleading. The absence of adaptation does not erase one-shot substantive control.
• Assign the full profile first. Code $\mathbf{a}=\langle a_D,a_S,a_E\rangle$. If $a_E=\mathrm{A}$, assign L3; otherwise, if $a_S=\mathrm{A}$, assign L2; otherwise, if $a_D=\mathrm{A}$, assign L1; assign L0 only when all coordinates are human-authored or externally fixed.
• Report residual human control. List human seeds, templates, primitive libraries, task distributions, rubrics, hidden tests, approval gates, rescue interventions, and stopping rules.

Candidate generation shows that the system acts within a space; by itself it establishes neither AI-provided direction nor AI-provided space. The system is L2 only when AI substantively constructs or revises the representation, primitives, operators, or constraints that define which candidates are expressible, even if a person chose the direction. A generated score establishes L3 only when AI constructs or revises the operative criterion that governs selection, rather than merely executing a fixed prompt or benchmark. Self-modification likewise does not establish L2 by itself: it qualifies only when the modification changes the space-defining objects or operators. Recursive self-improvement additionally requires evidence that the modification improves the process producing later improvements.

Every AI4AI result should report both an outcome and a responsibility audit. The outcome report includes target capability, transfer, resource use, variance, failed trials, and comparisons with human-designed and automated baselines. The responsibility audit records $\mathbf{a}$, optional control strengths $\mathbf{r}$, human inputs, evaluator visibility, candidate/evaluator model overlap, contamination controls, intervention frequency, and the number of completed discovery generations. When provenance changes across cycles, report the profile for each cycle and state the reporting window rather than collapsing the trajectory into one unqualified label.

Evidence should match the claimed control variable. Direction quality should be assessed with independent judgments of importance, novelty, feasibility, actionability, and whether the proposed trajectory changes the next interventions. Search-space quality requires validity, coverage, diversity, expressivity, and matched-compute comparisons. Evaluation-signal quality requires calibration, adversarial robustness, resistance to reward hacking, and agreement with hidden external criteria. Claims of recursive benefit require cross-generation evidence under a frozen or held-out evaluator: an improvement at cycle t must increase the productivity or capability of the improver at $t+1$, not merely the score of the current target.

4. L1: AI Provides the Search Direction

The control transferred at L1.

L1 transfers control over how to explore. Its defining capability is substantive AI control of the search direction: this may be expressed in a single target-specific intervention or through history-conditioned direction selection. In the latter case, given a human-specified search space and evaluation rule, the AI reads previous candidates, scores, critiques, failures, and partial discoveries, then decides which improvement trajectory should be pursued next. Section 4.1 formalizes this view. Section 4.2 studies evolutionary program improvement, including FunSearch and OpenEvolve. Section 4.3 covers prompt and workflow optimization. Section 4.4 connects direction discovery to reflection, memory, and explicit search over reasoning trajectories. Section 4.5 examines experiment-driven research agents, and Section 4.6 summarizes evaluation criteria, failure modes, and the boundary with L2.

Figure 3. History-conditioned direction selection at L1. The search space S and the operative evaluation criterion E are fixed externally, so the profile is $\langle \mathrm{A},\mathrm{H},\mathrm{H}\rangle$ and AI controls only the direction of the search. The AI reads four carriers of accumulated history—performance (candidate scores, learning curves, budget), evolutionary (population archive, ancestry, variation), reflective (execution traces, critiques, suggested edits), and experimental (hypotheses, results, persistent memory)—and its direction policy $P_D$ applies selection, diagnosis, abstraction, and portfolio control to that record. The resulting directional act selects an ancestor, repairs a module, changes an operator, proposes a new hypothesis, or allocates the next experiment. After execution and evaluation, the new candidates and the evidence they carry return along the rail at the bottom and close the loop. L1 is thus defined by what to try next within a fixed representation and objective; L2 begins when AI instead changes what can be tried.

Figure 3. History-conditioned direction selection at L1. The search space S and the operative evaluation criterion E are fixed externally, so the profile is $\langle \mathrm{A},\mathrm{H},\mathrm{H}\rangle$ and AI controls only the direction of the search. The AI reads four carriers of accumulated history—performance (candidate scores, learning curves, budget), evolutionary (population archive, ancestry, variation), reflective (execution traces, critiques, suggested edits), and experimental (hypotheses, results, persistent memory)—and its direction policy $P_D$ applies selection, diagnosis, abstraction, and portfolio control to that record. The resulting directional act selects an ancestor, repairs a module, changes an operator, proposes a new hypothesis, or allocates the next experiment. After execution and evaluation, the new candidates and the evidence they carry return along the rail at the bottom and close the loop. L1 is thus defined by what to try next within a fixed representation and objective; L2 begins when AI instead changes what can be tried.

4.1. History-Conditioned Direction Selection

History as search state.

Let the research history at cycle t contain attempted interventions, observed evidence, and the relations among them:

$$h_t={\left\{(c_i,q_i,{\delta }_i,{\rho }_i)\right\}}_{i<t},D_t=P_D(x_t,h_t,S_t).$$

Here $c_i$ is a previous candidate, $q_i$ its measured outcome, ${\delta }_i$ an optional textual or structured diagnosis, and ${\rho }_i$ its lineage, neighborhood, or experimental context. The direction policy $P_D$ may select a bottleneck, an ancestor to elaborate, a region to abandon, an operator to emphasize, or a hypothesis that explains the observed pattern. At canonical L1, the search space $S_t$ and the operative evaluation criterion $E_t$ remain externally fixed; AI controls which intervention or resource allocation is pursued within that space. A fixed pruning or acceptance rule is part of $E_t$, not an additional L1 decision.

Performance histories: scalar allocation.

This definition connects recent LLM systems to a longer history of adaptive search. Random search provides a history-agnostic baseline, whereas Bayesian optimization, model-based AutoML, and population methods use accumulated observations to decide which configuration or training regime deserves the next unit of compute [1,2,3,7]. Hyperband, BOHB, Optuna, and Freeze-Thaw Bayesian optimization provide useful allocation baselines: their fixed pruning or promotion criteria remain part of the external evaluation protocol, while the history-conditioned policy determines which configuration or budget receives the next unit of attention [78,79,80,81]. If an AI system learns or revises the pruning, acceptance, or stopping criterion, that component is evaluation control and is assigned L3 by the precedence rule rather than L1.

Performance histories: response surfaces.

Neural architecture search similarly learns or evolves proposal policies from previously evaluated architectures [5,6,25,63]. Progressive NAS and Neural Architecture Optimization use evaluated architectures to predict productive expansions or latent-space moves; ENAS and Network Morphism preserve information through shared parameters or function-preserving transformations [82,83,84,85]. Predictor-based methods such as BANANAS and Neural Predictor fit explicit response surfaces over architecture histories, while early performance prediction, zero-cost proxies, and Once-for-All reduce the evidence cost of deciding which direction deserves full training [86,87,88,89,90]. Reproducible suites including NAS-Bench-101, NAS-Bench-201, NATS-Bench, and surrogate NAS benchmarks make it possible to replay identical histories and compare direction policies rather than incomparable final models [91,92,93,94].

Evolutionary histories: archives and variation.

Population-based systems retain more than scores: they preserve ancestry, island membership, mutation operators, novelty, and rediscovery. FunSearch, AlphaEvolve, OpenEvolve, and ShinkaEvolve use archive state to decide which ancestor or island should generate the next program, while Language Model Crossover, LLMatic, SBLLM, PromptBreeder, and CodeEvolve use successful lineages to choose a variation strategy [10,11,13,95,96,97,98,99,100]. Here the history is relational: direction depends on where a candidate sits in an evolving population, not only on its scalar value.

Reflective histories: critiques and trajectories.

Language makes failed attempts directly interpretable as search evidence. ProTeGi, OPRO, TextGrad, and GEPA translate errors, scores, or execution traces into targeted edits to AI artifacts [12,69,101,102]. These methods treat a critique as a directional signal rather than as a final evaluation alone.

Experimental histories: replay and research memory.

The fourth family grounds direction selection in reproducible experimental records. NAS-Bench-101, NAS-Bench-201, NATS-Bench, and surrogate benchmarks permit counterfactual replay of the same evaluated history, making competing direction policies directly comparable [91,92,93,94]. Research agents such as AI Scientist, MLE-STAR, and AutoResearchClaw extend the same principle to literature, hypotheses, code, failed runs, and reviewer feedback, using accumulated evidence to select the next experiment [15,103,104]. Experimental history therefore supports both discovery and audit: it records why a direction was chosen and whether the choice survives replication.

From observation to a directional act.

Across the four families, history influences direction through selection, diagnosis, abstraction, and portfolio control. Performance histories primarily rank or predict; evolutionary histories preserve ancestry and strategy; reflective histories explain what should change; and experimental histories determine which uncertainty should be resolved next. Modern systems often combine several carriers. The history is therefore not merely a log, but the state from which the system constructs its next research move.

Figure 4 organizes the field into performance, evolutionary, reflective, and experimental histories according to the evidence that the AI actually reads. This organization is intentionally causal rather than application-based: one system may combine scores, lineages, critiques, and experimental memory, but each carrier supports a different kind of directional act. Table 3 then decomposes representative methods into their direction policy, the history evidence they read, and the next directional act they control.

4.2. Evolutionary Program Improvement

Archive-conditioned program evolution.

Evolutionary coding agents are the clearest current realization of history-conditioned direction discovery. FunSearch stores high-performing programs in an island-structured archive, samples exemplars from that archive, and asks an LLM to continue the observed line of improvement under a human-provided program skeleton and executable evaluator [10]. AlphaEvolve scales the same basic pattern to general codebases and multiple evaluators [11]; OpenEvolve exposes an open implementation with program databases, diversity-aware sampling, and iterative LLM mutation [95]. In all three, the decisive L1 operation is the use of accumulated program lineages and scores to choose how the next proposal should depart from its ancestors.

Language models as history-sensitive variation operators.

Several adjacent systems make this direction policy more explicit. Algorithm Evolution and Evolution of Heuristics evolve natural-language algorithmic ideas together with executable implementations [109,110]. LLMs can also serve as evolutionary optimizers, surrogate models, or learned variation operators that infer productive moves from the current population [111,112]. Evolution through Large Models and Language Model Crossover showed that pretrained models can produce semantic mutations and recombinations from parent examples rather than blind syntactic perturbations [97,113]. LLMatic couples this capacity to a quality-diversity archive for neural architecture search, and SBLLM retrieves successful optimization patterns before composing the next code edit [98,99]. These systems turn population history into an implicit local model of “what kind of change works here.”

Evolving the proposal policy.

EvoPrompt applies evolutionary selection to prompts [114], while PromptBreeder evolves both task prompts and the mutation prompts that generate them [13]. ShinkaEvolve adds novelty rejection, bandit-based model selection, and parent sampling to improve sample efficiency [96]. This is a stronger L1 pattern than merely sampling more candidates: past outcomes alter which parent, mutation model, and novelty threshold govern the next move. It remains L1 so long as the program representation, admissible edits, and executable objective are supplied externally.

Strategy-level archives.

The same loop now appears across algorithm and system design. CodeEvolve combines island-based evolution with inspiration-driven crossover [100]; LLM-FE evolves feature-engineering programs [115]; program-search benchmarks test whether search histories support reusable abstractions across games and ARC-like tasks [116,117]. Evolution of Kernels, SeaEvo, graph-augmented evolution, and adaptive population handoff further study how the archive should route proposals among local strategies [106,118,119,120]. Work isolating the contribution of evolutionary selection shows that the population mechanism, not only the base model, materially changes performance [121]. EvoTrace goes further by replaying evolutionary histories and separating structural innovations from constant tuning, rediscovery, and cyclic edits [107].

The L1–L2 classification test.

Under our unit-of-analysis rule, FunSearch and OpenEvolve belong to L1 when the mutable program boundary, programming language, evaluator, and admissibility constraints are supplied by humans and AI uses the archive to choose the next improvement direction. The same software can exhibit an L2 component if it invents new representations, primitives, or edit operators that redefine which candidates are expressible. This distinction classifies the demonstrated control decision, not the project name.

4.3. Prompt, Pipeline, and Workflow Optimization

Textual gradients over prompt histories.

Prompt optimization provides a second large family of L1 systems because the optimization trace can be represented directly in language. Automatic Prompt Engineer samples and ranks candidate instructions [68]; ProTeGi turns errors into textual gradients and edits prompts by beam search [12]; OPRO places previous solutions and scores in the optimizer model’s context so that it proposes a better next instruction [69]. PromptAgent formulates prompt revision as strategic planning [122], and TextGrad propagates language feedback through compound pipelines [101]. These methods differ in their search operator, but each converts a record of prior failures and successes into a directional signal.

Editable units from tokens to compound programs.

The field has progressively expanded the editable unit. AutoPrompt, BBT, BBTv2, GrIPS, RLPrompt, and TEMPERA optimize discrete tokens, continuous surrogates, edit sequences, or test-time prompt policies [123,124,125,126,127,128]. SAMMO searches structured prompt programs [129]; DSPy compiles declarative language-model modules into optimized pipelines [130]; MIPRO jointly selects instructions and demonstrations for multi-stage programs [131]. PromptWizard, CriSPO, and automatic instruction-exemplar selection use task analyses or multi-aspect critiques to decide which component should change next [132,133,134]. Local prompt optimization studies whether local edits can outperform global rewrites under constrained budgets [135].

Reflective evolution.

GEPA makes the L1 mechanism unusually visible: it samples execution trajectories, reflects on natural-language feedback, proposes targeted prompt updates, and maintains a Pareto frontier of candidates [102]. The value of such reflection is not guaranteed. Re-evaluations of OPRO show sensitivity to the optimizer model, scorer, handcrafted meta-instruction, and token budget [136]. These results motivate a distinction between history exposure and history use: placing scores in a context window does not establish that the next edit is causally responsive to them.

Credit assignment across workflows.

History-conditioned workflow search is especially important for AI4AI because prompts, evaluators, data filters, and agent roles interact. A weak pipeline may not need a globally better instruction; it may need a new decomposition, a different handoff, or a targeted repair at the module responsible for a recurring failure. DSPy-style compilation, textual gradients, and critique-suggestion loops make such credit assignment partially explicit [101,130,133]. They therefore move L1 from selecting among isolated prompt strings toward selecting directions in a structured development process.

Fixed workflow or AI-provided space?

The L1 interpretation depends on what remains fixed. If humans define the modules and AI only decides how to revise them using observed performance, the focal control is direction. If AI invents the module graph, the representation language, or an unbounded family of tools, it begins to provide the search space and must also be reported as L2. The same optimization trace should therefore be accompanied by its full responsibility profile rather than by the method label alone.

4.4. Reflection, Memory, and Search over Trajectories

Diagnostic histories.

Scalar scores are often too weak to identify a productive direction. In-scope reflective systems use execution traces, evaluator feedback, or artifact-level critiques to decide which AI artifact should be revised next. Textual gradients, structured critiques, and multi-stage code-generation flows provide such evidence when they change a prompt, program, training procedure, or agent scaffold; standalone answer-refinement and reasoning protocols are outside the AI4AI scope.

Branching histories.

Explicit search methods retain several possible directions. In AI4AI settings, the retained branches must correspond to alternative artifact edits, experiments, or research hypotheses rather than merely alternative answers to one task. STaR converts successful reasoning traces into training data for subsequent improvement [137]; this parameter update is why it belongs to AI4AI Learning. Choosing an AI4AI direction may therefore require maintaining a topology of artifact alternatives rather than compressing history into a single incumbent.

Persistent histories.

Long-term memory extends the horizon over which direction can change. MemoryBank and MemGPT distinguish active context from persistent experience [138,139]; ExpeL extracts transferable lessons across task trajectories [140]; Voyager accumulates an executable skill library and uses environment feedback to select increasingly ambitious goals [141]. Generative Agents similarly retrieve, reflect on, and synthesize past events into higher-level plans [142]. These systems are not automatically AI4AI, but their memory mechanisms become L1 components when the remembered experience guides the improvement of an AI artifact or its development process.

Self-correction is an empirical claim.

Evidence on intrinsic self-correction is mixed. Controlled studies report that language models often fail to repair reasoning without reliable external feedback, while other work finds gains under carefully constructed intrinsic critique protocols [143,144]. ReST^EM shows a different route: successful and unsuccessful traces can be converted into iterative self-training data rather than used only at inference time [145]. For L1, the central question is therefore not whether a model can produce a critique, but whether the critique selects a better intervention than score-only, shuffled-history, or no-history controls.

Counterfactual dependence on history.

The central limitation is that reflection is evidence of control only when it changes the search trajectory. A fluent critique that restates the failure message, a memory item that is never retrieved, or a tree whose branches collapse to the same proposal does not establish AI-provided direction. Causal ablations should remove, shuffle, or replace the historical record and measure whether the resulting direction and final discoveries change.

4.5. Experiment-Driven Research Direction

Research history as a heterogeneous record.

At the scale of research workflows, history consists of literature, experimental plans, implementation traces, failed runs, reviewer feedback, and intermediate results. ResearchAgent uses literature-grounded retrieval to propose and refine research ideas [71]. MLAgentBench evaluates whether language agents can plan and execute machine-learning experiments [72], while MLE-bench tests end-to-end machine-learning engineering under realistic competition tasks [146]. The AI Scientist and AI Scientist-v2 use prior experimental evidence to revise hypotheses, code, and reports over repeated cycles [15,16]. Agent Laboratory distributes literature review, experimentation, and writing among collaborating agents [73].

Search and targeted experimental refinement.

MLE-STAR first retrieves plausible model families and then uses block-level ablations to decide which part of a machine-learning solution should be refined next [103]. AutoResearchClaw similarly emphasizes persistent research memory and self-reinforcing cycles, while Jr. AI Scientist begins from a baseline paper and conducts autonomous extensions [104,147]. These systems are closer to L1 than agents that merely execute a static plan because experimental results can redirect attention among hypotheses, implementation components, and follow-up tests.

Multi-agent evidence aggregation.

General agent frameworks supply complementary mechanisms. Data Interpreter records data-science plans and execution feedback [148]; MetaGPT, AutoGen, and AgentVerse coordinate specialized roles through shared messages and artifacts [149,150,151]. AgentCoder iterates code generation against testing agents [152], while SWE-agent and Agentless expose how repository feedback can be converted into repair strategies with very different amounts of scaffolding [153,154]. OSWorld broadens the executable environment in which such history-conditioned decisions can be evaluated [155]. Automated Design of Agentic Systems treats the agent organization itself as an editable artifact [14].

AgentBench, AgentBoard, GAIA, and SWE-bench add complementary views of whether multi-turn histories improve action selection in interactive, assistant, and software-engineering settings [156,157,158,159]. More Agents Is All You Need reports gains from sampling and aggregating multiple agents, whereas AgentScope provides engineering support for maintaining their messages and states [160,161]. For L1, however, parallelism counts only when disagreement or complementary evidence changes the next research direction; a larger ensemble that repeats the same trajectory is additional compute, not additional control.

Degrees of directional autonomy.

These systems reveal a spectrum of directional autonomy. At the weakest end, AI executes a human-authored experiment list. Stronger systems diagnose why a run failed, compare competing explanations, and allocate the next experiment to resolve uncertainty. Stronger still, they may revise the research question after evidence invalidates its assumptions. Such revision is one strong example, but L1 more generally requires a target-specific change in how the investigation proceeds, rather than simply completing the next queued operation.

Research-agent audits.

Recent audits expose why final-paper appearance is an inadequate proxy for L1 competence. Evaluations of the AI Scientist report mixed reproducibility and uneven experimental validity [108]; implementation-focused analyses argue that weak execution and verification remain binding bottlenecks [162]. Other studies find that automation can hide consequential intermediate decisions, that independent AI scientists may disagree, and that headline scientific impact remains far from established [163,164,165]. MLReplicate measures whether autonomous systems can reproduce machine-learning results, while SciIntegrity-Bench tests citation, attribution, and experimental-integrity failures [166,167]. Package hallucinations provide a concrete example of a seemingly productive direction failing at the implementation layer [168].

Discoveries that update the improver.

Program-search systems also become research agents when discoveries feed back into the next cycle. AlphaTensor and AlphaDev used learned search to reveal new algorithmic strategies [66,67]; Eureka evolves reward programs from environment outcomes and is therefore an L3 evaluator-generation case rather than an L1 row here [19]; STOP and the Darwin Gödel Machine use previous improvements to modify an improver or coding agent within a fixed edit boundary [24,70]. AutoRISE applies related strategy evolution to adversarial testing [169]. Such systems are particularly informative because their histories contain both object-level results and evidence about the process that produced those results.

4.6. Direction Quality, Failure Modes, and the Boundary with L2

Degrees of history use.

History conditioning is not a binary property of an entire system. History-exposed systems receive earlier candidates or scores but need not respond to them. History-responsive systems produce detectably different proposals when the record changes. History-explanatory systems identify which observation supports the chosen move. History-counterfactual systems can state what would have been tried under a different outcome. The stronger degrees support more credible claims that AI, rather than a fixed script, supplies the direction. Reproducible NAS studies show why this distinction matters: sophisticated adaptive policies can lose to random search when budgets, spaces, and evaluation protocols are controlled [105,170,171].

Evaluating the direction rather than only the destination.

L1 should be evaluated at the level of the direction, not only the final artifact. A useful evaluation stack asks whether the chosen direction is novel relative to the supplied history, causally responsive to evidence, feasible under the remaining budget, diverse across independent runs, and more productive than random, greedy, or history-ablated baselines. For population methods, reporting should include archive coverage, lineage depth, repeated-edit rates, and the contribution of crossover or diversity maintenance [107,121]. For prompt and reflection methods, it should include edit locality, critique-action agreement, retrieval usage, and robustness to misleading history [101,133,140].

Characteristic failure modes.

Four failure modes recur. Historical anchoring keeps the search close to early incumbents; archive collapse removes competing hypotheses; credit misassignment attributes a gain to the wrong edit or module; and feedback overfitting selects directions that exploit a fixed evaluator. Evolutionary archives and multi-agent portfolios mitigate some of these risks but can also multiply compute without producing genuinely distinct research trajectories [10,100,150]. Direction discovery therefore needs independent replay, counterfactual history ablations, and held-out evaluators.

Boundary with L2.

The L1–L2 boundary is determined by the origin of the candidate domain. L1 may select ancestors, mutation strategies, modules to repair, or hypotheses to test inside a human-fixed representation. L2 begins when AI substantively changes the editable objects, primitives, constraints, or operators that define what can be proposed. FunSearch and OpenEvolve are canonical L1 examples in this chapter because their central mechanism uses previous programs and evaluator feedback to choose the next improvement direction under an externally supplied coding boundary. If a deployment allows the same agent to invent that boundary, its full profile must record the additional L2 control.

5. L2: AI Provides the Search Space

At L2, the focal object is the search space itself: where improvement can occur and what objects or moves are available there. A system reaches L2 only when AI substantively determines the search space by selecting, constructing, expanding, compressing, or revising its representation, primitive library, legal composition rules, or validity constraints. Direction may come from either source, while the evaluation signal remains human-authored or externally fixed. Note that AI-generated candidates alone do not establish L2. A system may produce highly novel designs within a human-specified space; L2 requires AI to substantively determine or revise the space from which those candidates can be generated. This process is summarized in Figure 5.

5.1. Formalization and Evaluation of AI-Defined Search Spaces

This subsection formalizes the L2 search space, its main components, and its evaluation. We first distinguish the AI-defined active space from the broader ambient universe, then decompose it into its representation, available primitives, legal composition and edit operators, and validity constraints, and finally discuss how to evaluate the space by distinguishing its contribution from that of the navigation policy. Figure 6 organizes L2 work by the search-space artifact supplied by AI.

AI-defined active search spaces.

At L2, AI defines an active search space within a broader universe. Let $\mathcal{U}$ denote this ambient universe: a programming language, hardware interface, broad architecture grammar, or set of executable APIs. At iteration t, the active space is represented by

$$S_t=({\mathcal{R}}_t,{\mathcal{P}}_t,{\mathcal{O}}_t,{\mathcal{K}}_t),$$

where ${\mathcal{R}}_t$ is the representation, ${\mathcal{P}}_t$ the available primitives or modules, ${\mathcal{O}}_t$ the legal composition and edit operators, and ${\mathcal{K}}_t$ the validity constraints. The candidates induced by this representation belong to the ambient universe, so ${\mathcal{C}}_t\subseteq \mathcal{U}$. L2 requires AI to construct or substantively revise the search space that shapes candidate generation:

$$S_t\sim P_S(·\mid x_t,h_t),{\mathcal{C}}_t={\left\{c_{t,i}\right\}}_{i=1}^{n_t}\sim G_t(·\mid S_t,D_t;B_t),q_{t,i}=E_t(c_{t,i},x_t,S_t,D_t).$$

What matters for L2 is that AI determines $S_t$, after which $G_t$ is the candidate-generation or navigation policy that samples or constructs candidates inside that space. In the batch abstraction of Section 3, $S_t$ is formed before $D_t$ is selected within it; online systems may instead alternate space construction and direction selection as evidence arrives. The ambient universe $\mathcal{U}$ may remain human-defined, just as a programming language can stay fixed while AI learns a new domain-specific library. This separates search-space construction from navigation: $S_t$ defines the domain over which downstream search operates, whereas $G_t$ determines how that domain is explored under the available budget. For an L2 assignment, $E_t$ in the displayed equation is held externally fixed; if AI constructs or revises its operative criterion, the precedence rule assigns L3.

Search-space evaluation and attribution.

Evaluation of an L2 system should focus on the quality and consequences of the AI-defined search space itself. Evidence should identify which components of $(\mathcal{R},\mathcal{P},\mathcal{O},\mathcal{K})$ are constructed or revised by AI and characterize how these changes alter the candidates, compositions, or constraints available to downstream search. Because downstream performance also depends on the navigation policy $G_t$, evaluation should control for this factor rather than treat it as part of the L2 contribution. Comparisons under a fixed or matched navigation policy can therefore help attribute gains specifically to the AI-defined search space.

We review existing L2 methods by the part of the search space that AI constructs or revises. Figure 6 provides an overview of this component-based organization. while Table 4 decomposes representative methods into their space-construction policies, human-provided ambient universes, and AI-provided active spaces. We organize the discussion around changes to primitives ${\mathcal{P}}_t$, representations ${\mathcal{R}}_t$, composition and edit operators ${\mathcal{O}}_t$, and admissibility constraints ${\mathcal{K}}_t$. Methods affecting multiple components are discussed under their primary space-defining change, with secondary effects noted where relevant.

Selecting and constructing primitives.

Primitive-level construction changes the modules from which downstream candidates are assembled. Neural operations, library functions, and callable tools or skills instantiate ${\mathcal{P}}_t$ in different settings; the candidate space consists of architectures, programs, or action routines built from these primitives under the remaining components of $S_t$. Selection alone can define an active primitive set. DDSAS represents a subspace as a binary edge–operation mask over a fixed architectural graph. Upper Confidence Bound (UCB)-guided global top-L selection dynamically constructs the active subspace, and differentiable optimization subsequently searches within and updates this subspace. [173]. The main change is therefore to the available neural operations, not to the graph encoding or the rules for editing architectures.

Program-library learning constructs new primitives rather than selecting existing ones. EC² learns reusable domain-specific subroutines while jointly training a neural recognition model to guide search over programs expressed in the learned domain-specific language(DSL) [174]. DreamCoder interleaves task solving with abstraction learning that extends its DSL with reusable symbolic abstractions, and drawing-program induction applies the same library-learning mechanism to induce reusable, abstract, and compositional drawing subroutines. [175,176]. LAPS additionally uses natural-language supervision to learn abstractions and search heuristics [177]. Stitch synthesizes abstractions that capture recurring program structure and compress the program corpus, while LILO integrates LLM-guided and enumerative program synthesis, Stitch-based library compression, and an LLM-based auto-documentation (AutoDoc) module that generates human-readable names and docstrings for learned abstractions. [178,179]. Across these systems, the learned functions become callable constituents of subsequent programs, making the library update the primary ${\mathcal{P}}_t$ intervention.

Tool-making systems expose the same mechanism through agent interfaces. CREATOR generates a tool before deciding how to apply it, LATM caches generated Python tools for subsequent requests, and Toolink creates a toolkit before planning and tool calling [180,181,182]. CRAFT abstracts generated code solutions into reusable tools, forming a specialized toolset for downstream retrieval and use, whereas TROVE incrementally grows and trims a toolbox of reusable high-level functions [183,184]. ToolLibGen clusters question-specific tools and refactors them into structured libraries with unified interfaces [185]. Here, tools affect the search space because later solutions invoke them as available building blocks, rather than because tool generation itself constitutes a final solution.

Voyager and DynaSaur extend this construction across tasks by accumulating executable skills or actions that later solutions can reuse [141,187]. Memento-Skills maintains and refines multi-artifact skills comprising declarative specifications, helper scripts, and prompts [188]. Their L2-relevant object is the evolving repertoire of usable routines, not the retrieval or routing policy that selects among them. Such primitives can encapsulate behavior already expressible in the base language; they need not introduce new semantic capabilities to alter the building blocks and lengths of candidate solutions.

ToolMaker illustrates a related but narrower case: it implements reusable tools from scientific code repositories and prepares their execution environments, while the desired task specification, repository, and required input arguments are provided externally [186]. This establishes tool realization, but does not by itself establish autonomous selection of the primitive vocabulary.

Learning candidate representations.

Representation-level construction changes the encoding through which candidates are exposed to downstream search, rather than merely changing how often fixed candidates are proposed. In hierarchical generative NAS, a graph variational autoencoder learns embeddings of cell architectures, while clustering based on zero-cost performance proxies identifies families of similar cells. The macro search operates on sequences of cell-family identifiers, channel counts, and strides; conditional generation with CCNF and G-VAE decoding then instantiates these high-level descriptions as concrete architectures. The method first explores this high-level space using evolutionary search (HL-Evo) and subsequently trains a sequence generator on the explored architectures [172]. We therefore attribute its primary learned space abstraction to the graph representation and cell-family abstraction. The human-specified architectural template remains distinct from this learned encoding, as does the sequence generator’s role in proposing candidate architectures.

Revising composition and edit operators.

Operator-level construction would change the reusable rules that assemble or transform candidates, such as grammar productions or admissible graph rewrites. This differs from adding a function that can be invoked through an unchanged composition language, and from selecting a particular sequence of existing actions. Under this distinction, the reviewed abstraction and tool-learning systems mainly modify ${\mathcal{P}}_t$, and do not provide a clear primary example of learned ${\mathcal{O}}_t$. SkillX further illustrates this boundary: although it learns hierarchical reusable skills, these skills are retrieved as execution guidance rather than modifying the underlying composition operators [189]. Such guidance does not by itself demonstrate that AI has changed the legal composition or edit operators. We therefore retain operator construction as a distinct intervention target without assigning these systems to it solely because they describe or perform composition.

Adapting admissibility constraints.

Constraint-level construction changes which otherwise expressible candidates are admitted to the active search. S3 represents an architecture space through admissible sets of values for design dimensions, including depth, embedding dimension, attention heads, window size, MLP ratio, and query–key–value dimensions. Their Cartesian product defines the active search space. Using a supernet-based space-quality estimate, S3 evolves these value sets before the final architecture search [190]. With the design variables and architectural building blocks held fixed, we classify this intervention primarily as a change to ${\mathcal{K}}_t$: it revises the active admissibility conditions rather than simply selecting an individual architecture.

5.2. Evaluation and Minimum Evidence for L2

Having identified the different components of $S_t$ that AI can construct or revise, the next question is whether downstream improvements can actually be attributed to the resulting search space. This requires evaluating the space itself while controlling for other factors that affect search performance.

Evaluating AI-defined search spaces.

Evaluation of an L2 system should assess the quality and consequences of the AI-defined search space $S_t$, rather than only the performance of an individual selected candidate. The quality of a final candidate reflects not only the space construction process, but also the navigation policy $G_t$, evaluator variance, and search budget. A source-matched L2 evaluation should therefore isolate the contribution of $S_t$ by comparing controlled conditions: the AI-constructed space with a fixed search procedure; a human-designed space under the same search procedure; a randomized or stale AI-derived space with comparable capacity; and the original method with its full procedure. Evaluation should consider properties of the induced space, including validity, unique coverage, semantic diversity, achievable quality under matched sampling, transfer performance, and search cost.

For induced libraries and toolboxes, space-level evaluation should further consider compression, reuse frequency, interface validity, and held-out task benefit, rather than relying only on performance over the tasks used for construction. Because downstream results depend jointly on $S_t$ and the navigation policy $G_t$, evaluations should control or match $G_t$ across conditions so that improvements can be attributed to changes in the search space itself.

Such attribution requires evaluation environments where the evaluator and task distribution remain external while the provenance of the search space is systematically varied.

Existing benchmarks.

Existing benchmarks provide standardized environments for evaluating search procedures and agent capabilities. In neural architecture search, NAS-Bench-101, NAS-Bench-201, NATS-Bench, and surrogate NAS benchmarks enable reproducible comparisons by providing predefined architecture spaces together with tabulated or learned performance estimates [91,92,93,94]. These resources allow researchers to replay architecture search algorithms under controlled conditions without repeatedly training all candidate architectures.

For tool- and skill-based agents, SWE-bench, OSWorld, AgentBench, AgentBoard, and MLE-bench provide task environments and execution-based evaluation protocols covering software engineering, computer interaction, general agent behavior, and machine learning workflows [146,155,156,157,159]. Together, these benchmarks establish common grounds for comparing systems that differ in their internal search spaces, tools, or learned capabilities.

Minimum reporting package.

An L2 paper should report: (i) the human-provided ambient universe $\mathcal{U}$; (ii) the machine-produced artifact defining $S_t$; (iii) the changed components of $(\mathcal{R},\mathcal{P},\mathcal{O},\mathcal{K})$; (iv) whether the artifact is persistent and reusable, where applicable; (v) freeze-and-replay or otherwise navigation-matched comparisons under matched compute; and (vi) who supplied direction $D_t$ and evaluator E. Together, these measurements attribute downstream gains specifically to the AI-defined search space.

5.3. Composition with Direction and Evaluation Control

Practical systems often combine L2 with other forms of AI control. It is therefore necessary to distinguish which system components determine direction, search space, and evaluation, rather than assigning a single control level to the system as a whole.

Composition with direction control.

Search within an AI-defined space may follow directions specified by humans or predefined rules, and can also be guided by an L1 component that determines which directions to pursue. Voyager exemplifies this combination: its automatic curriculum selects goals, while AI-generated skills expand the available reusable components [141]. Direction control determines what to pursue, while search-space construction defines the representations, primitives, operations, and constraints available for pursuing it. Voyager also uses AI-based self-verification to judge whether a task has been completed, which determines whether the resulting program is committed to its skill library, constituting L3 evaluation control under our taxonomy.

Evaluation remains external.

L3 begins when AI constructs or substantively revises what counts as progress. Eureka, Constitutional AI, RLAIF, LLM-as-a-judge, self-rewarding models, and process supervision concern evaluation control rather than search-space provenance [17,18,19,20,21,75]. Such mechanisms can coexist with L2, but their contributions should be attributed separately: an AI-generated library remains an L2 artifact when judged by a fixed external evaluator, whereas an AI-generated or substantively revised reward belongs to evaluation control even when the candidate space is entirely human-designed.

L2 should therefore be attributed to the component that constructs or revises $S_t$, rather than to the system as a whole. A single system may combine direction control, search-space construction, navigation, and evaluation control; when AI additionally begins to construct or revise the criterion E by which progress is judged, the analysis moves from L2 search-space control to L3 evaluation control.

6. L3: AI Provides the Evaluation Signal

The control transferred at L3.

L3 transfers control over the criterion that determines progress. An AI system qualifies for L3 when it constructs or substantially revises the operative signal used to rank candidates, allocate search effort, accept discoveries, or terminate the loop. Humans may still specify the direction and search space. L3 therefore includes every profile whose evaluation coordinate is AI-provided: $\langle \mathrm{H},\mathrm{H},\mathrm{A}\rangle$, $\langle \mathrm{H},\mathrm{A},\mathrm{A}\rangle$, $\langle \mathrm{A},\mathrm{H},\mathrm{A}\rangle$, and $\langle \mathrm{A},\mathrm{A},\mathrm{A}\rangle$. Only the last profile places all three control variables under AI control. The defining property of L3 is the provenance of the evaluation signal, rather than end-to-end autonomy.

The evaluator papers below are counted as AI4AI L3 evidence only when their AI-generated tests, judgments, rewards, or adaptive environments enter a discovery loop and change candidate selection, training, or acceptance. Standalone benchmark scoring, answer ranking, or post hoc review remains an evaluation technique, not an AI4AI intervention.

6.1. The Object of Attribution: the Operative Evaluation Signal

Evaluation as a structured artifact.

At iteration t, represent the operative evaluation object as

$$E_t=({\mathcal{T}}_t,J_t,A_t,{\tau }_t),$$

where ${\mathcal{T}}_t$ contains tests, tasks, or environments; $J_t$ maps evidence to local judgments; $A_t$ aggregates judgments across criteria, samples, or evaluators; and ${\tau }_t$ defines acceptance, rejection, or stopping thresholds. L3 requires an AI-generated component to enter the subsequent discovery loop:

$${\widehat{E}}_t\sim P_E(·\mid x_t,D_t,S_t,h_t,\mathcal{M}),q_{t,i}={\widehat{E}}_t(c_{t,i};x_t,S_t,D_t),c_{t+1}=Select\left({\{c_{t,i},q_{t,i}\}}_{i=1}^{n_t}\right).$$

Here $h_t$ is the accumulated research history used in Chapter 2, $\mathcal{M}$ denotes the model or agent that constructs the evaluator when such a model is present, and $c_{t,i}\in {\mathcal{C}}_t$ is an individual candidate. The evaluator may be instantiated before candidate scoring from $x_t,D_t,S_t,h_t$, or it may update online with additional history absorbed into $h_t$; in either case, $q_{t,i}$ is the candidate-level evidence used by selection. The selected candidate $c_{t+1}$ is the candidate-level counterpart of the target update $x_{t+1}$ in the full discovery cycle. The sources of direction $D_t$ and search space $S_t$ do not determine the L3 label. The relevant criterion is whether AI generates a component of ${\widehat{E}}_t$ and whether that component causally governs selection.

Seed specification, learned mapping, and operative authority.

Human involvement is compatible with L3. People may provide a constitution, examples, a broad rubric, or an executable interface, while AI generates tests, instantiates criteria, learns a reward mapping, generates reward code, or determines how evidence is aggregated. The attribution question is not whether humans appear upstream, but whether replacing the AI-generated component changes which candidates are judged better. A frozen, human-authored benchmark scored by deterministic execution remains a human evaluation, even if an AI agent reads its failures. An AI-generated test suite, learned verifier, or generated reward program qualifies as L3 when it determines subsequent selection.

The ranking-intervention test.

A strong L3 claim should make ${\widehat{E}}_t$ inspectable and replay the same candidate set under four conditions: the AI-generated evaluator, a human-authored anchor, a capacity-matched stale or randomized evaluator, and an independent holdout evaluator. The analysis should report rank correlation, pairwise disagreement, calibration, false-accept and false-reject rates, and downstream regret. It should repeat these comparisons after swapping candidate order and model identity, while matching output length and style and checking for contamination. If replacing the evaluator leaves the search trajectory unchanged, the evaluator provides auxiliary commentary rather than operative evaluation control.

Figure 7 summarizes how an AI-provided evaluation signal connects human anchors and generated evaluation components to consequential discovery decisions. The separate validation branch audits candidate gains using independent anchors; it does not grant the optimizing system control over the external evaluator.

Figure 8 organizes L3 work by the evaluation artifact supplied by AI. Table 5 uses the decomposition introduced for L1 and L2 and distinguishes the human anchor from the machine-generated signal that enters the loop.

6.2. Executable Evaluation Artifacts

Generated tests can become operative, but generation alone is insufficient.

CodeT uses language-model-generated tests and a dual execution-agreement score, combining agreement with the generated tests and with other sampled programs, to select a program at inference time [191]. ChatUniTest constructs unit tests tailored to the focal Java method and validates or repairs those tests. CodeJudge uses an LLM to estimate semantic code correctness without test cases [192,193]. These methods can act on different parts of E: test synthesis changes $\mathcal{T}$, whereas semantic judging changes J. The technical ability to generate a test or judgment does not by itself establish L3. ChatUniTest and CodeJudge count as L3 only when their generated tests or semantic judgments enter candidate selection, training, resource allocation, or an operative accept–reject rule; test repair, annotation, or post hoc scoring remains evaluation support. Their evidence is strongest when generated tests are checked for validity, coverage, independence from the candidate generator, and agreement with hidden tests.

Outcome verifiers learn a pass–fail boundary.

CodeRL trains a critic to predict functional correctness and feeds its dense feedback into actor updates and critical sampling. LEVER combines execution results with a learned verifier to rerank programs generated by a language model [194,195]. Cobbe et al. train an outcome verifier on final-answer correctness and use it to select among sampled GSM8K solutions with Best-of-N [212]. CRITIC instead runs a generate, tool-check, and revise loop for individual outputs. Its feedback can guide revision, although the paper neither trains a reward model nor explicitly ranks a population [213]. CRITIC counts as L3 only when the critique controls the operative revision or accept–reject decision in the analyzed discovery loop; a one-off tool check or post hoc critique remains an evaluation technique.

Process supervision localizes evaluation.

Outcome rewards score complete trajectories, whereas process rewards score intermediate steps and can reveal where a derivation first fails. PRM800K provides human step labels. Its solution score is the product of step-positive probabilities; minimum reduction is evaluated as an alternative for Best-of-N selection [75]. Math-Shepherd estimates step quality from rollout success without human step annotations and uses the resulting process reward for verification and PPO [196]. Generative verifiers recast verification as next-token prediction: GenRM scores a candidate by the probability of the “Yes” token, while GenRM-CoT aggregates scores across sampled verification rationales [197]. These methods move different parts of E from fixed specifications and final-answer checks to AI-generated judgments; their labels, rollouts, and aggregation procedures should therefore be reported separately.

6.3. Learned Preference Evaluation and Model Judges

Preference models turn comparisons into a reusable objective.

Preference-based reinforcement learning learns a reward function from human comparisons, and InstructGPT uses the inferred reward to guide PPO updates [74,198]. These are mixed-control L3 examples when the learned mapping is the operative score consumed by optimization: humans provide the comparisons, while the learned mapping produces the signal. Constitutional AI replaces part of direct human feedback with model-generated critiques, revisions, and preferences conditioned on written principles. RLAIF trains a reward model from AI-generated preferences and uses that model for reinforcement learning [17,18]. In both systems, the human constitution or task specification serves as an anchor, whereas the labels and reward are machine-generated; the L3 designation still requires that this machine-generated signal change training, selection, or acceptance.

Model judges often function as evaluation technologies rather than closed loops.

MT-Bench, G-Eval, JudgeLM, Prometheus, and Prometheus 2 introduce language-model evaluators, rubrics, and tests of alignment with human judgments. Their original papers mainly report benchmark scores and evaluator quality rather than downstream candidate optimization [21,199,200,201,214]. They therefore become L3 components only when their ratings influence candidate survival, resource allocation, or acceptance. PandaLM is a narrower closed-loop case: its judge feeds or supports instruction-tuning hyperparameter selection, while its synthetic GPT-3.5 judgments and human holdout serve distinct evidentiary roles [202]. Treating PandaLM as L3 requires evidence that these judgments causally alter which configuration is retained or receives resources, rather than merely informing an offline comparison.

Rubric generation changes the measurement model.

A fixed human rubric delegates scoring but not the selection of criteria. A stronger L3 system derives criteria, weights, counterexamples, and disqualifying conditions from the task and then applies them. Reports should state whether AI changed $\mathcal{T}$, J, A, or $\tau$, whether those changes entered optimization, and whether generated criteria survived expert review or predicted delayed real-world outcomes.

6.4. Generated Objectives and Self-Evaluation

Executable reward design exposes the evaluator as code.

Text2Reward translates a natural-language objective into executable reward code for reinforcement learning. Its term “data-free” refers to the absence of offline demonstrations, not to the absence of human task specifications or optional feedback. Eureka uses an LLM to synthesize and iteratively improve reward programs from environment code and training feedback [19,203]. The resulting program can be versioned, executed, ablated, and supplied to a different policy optimizer. This makes generated rewards unusually auditable L3 artifacts when the generated program is the operative training or selection signal. Eureka also illustrates compositional control. Reward-code evolution can additionally function as L1 direction over prior reward candidates if the configuration uses those alternatives to decide which objective to pursue; otherwise it remains part of the L3 evaluator. The underlying simulator and action interface may remain human-provided.

Self-reward closes the generator–evaluator loop.

Self-Rewarding Language Models use the model itself as a judge to create preference data for iterative training, placing response generation and part of evaluation in one shared loop [20]. Meta-Rewarding Language Models add a meta-judge that evaluates the quality of the model’s own judgments, creating a second-order evaluator over $J_t$ [204]. These systems are structurally important because evaluator improvement can amplify candidate improvement. However, shared-model errors, self-preference, and feedback collapse make independent anchors essential. Reported gains should therefore be separated from external benchmark validation, which does not itself provide the training signal.

6.5. Adaptive Oversight, Robustness, and Recursive Evidence

Adaptive evaluation searches for failures.

Language-model red teaming generates adversarial questions that elicit harmful behavior and changes the test distribution in response to the system under evaluation [205]. POET co-evolves environments and agents; PAIRED trains an adversarial environment generator through regret; and LLM-POET uses language models to propose and mutate environments [206,207,208]. Their evaluation artifact is not a static score but an adaptive distribution ${\mathcal{T}}_t$ whose difficulty and coverage evolve with the candidate population. An adaptive ${\mathcal{T}}_t$ is only operative L3 evidence when its changes alter the judgment mapping, aggregation, threshold, or candidate selection/training in the analyzed loop. If it only generates challenge cases or acts as a curriculum while the evaluator and acceptance rule remain fixed, it is an adaptive test or training artifact rather than L3 evaluation control.

Scalable oversight distributes judgment across agents.

AI safety via debate proposes adversarial arguments as a way to help a human judge questions that are difficult to evaluate directly [209]. Scalable-oversight work studies whether models and assistance protocols can extend human supervision, while weak-to-strong generalization asks whether weak supervision can elicit stronger model capabilities [211,215]. CriticGPT trains a critic to identify subtle errors in model-written code and improve human review quality [210]. These protocols combine human anchors with AI-produced evidence, but neither debate, CriticGPT, nor weak-to-strong generalization is automatically L3. They count as L3 only when the generated arguments, critiques, or supervision signals change the operative J, A, or $\tau$ and thereby alter selection, training, or acceptance in the discovery loop.

Evaluation-guided search and scientific review.

An AI score matters for AI4AI when it changes parent selection, mutation, experiment allocation, early stopping, or acceptance. Candidate-level evaluations should therefore be linked to a trajectory-level quantity such as cumulative independent utility, best-so-far quality, or discovery regret. This causal view separates systems that merely summarize experimental outputs from systems whose evaluators control the next experiment.

Scientific review is a compound evaluator.

The AI Scientist combines idea generation, experiment execution, manuscript production, and automated review; its successor increases the degree of end-to-end automation [15,16]. Automated review can apply criteria such as novelty, soundness, clarity, and significance, but it remains a proxy for scientific value. A rigorous decomposition should expose the review rubric, reviewer model, aggregation procedure, acceptance threshold, and any literature or execution checks. Review-model scores should be calibrated against blinded expert judgments and later reproducibility rather than treated as ground truth.

Evaluator cascades can combine heterogeneous evidence.

Low-cost unit tests may filter obvious failures before expensive learned judges, formal checkers, or expert audits. Such cascades should report which stage has veto power and how uncertainty propagates. Otherwise, an apparently independent final evaluator can inherit a biased candidate pool created by an earlier AI judge.

Optimization pressure exposes proxy mismatch.

Reward-model performance can degrade when policies are optimized beyond the data regime on which the reward was trained [23]. Reward hacking occurs when proxy improvement lowers the intended reward. Goal misgeneralization occurs when an agent pursues the wrong objective out of distribution, and sycophancy occurs when preference optimization favors agreement over truth [216,217,218]. These failure modes are related but distinct. The distinction matters at L3 because the evaluator is a mutable component inside the optimization loop.

Model judges have systematic preferences.

LLM evaluators can exhibit position bias and inconsistent pairwise preferences [219]. Broader audits find sensitivity to model identity and to demographic or stylistic features; evaluators may also prefer outputs generated by themselves or related models [22,220]. Evaluator ensembles can reduce some forms of overoptimization and variance in synthetic settings, but correlated training data and architectures preserve shared blind spots [221]. Optimization may therefore follow a proxy reward model while leaving the latent objective unchanged. Ensembles mitigate this risk but do not eliminate it [222].

Minimum reporting package.

An L3 paper should report: (i) the human-provided specification and data; (ii) the AI-generated components of $(\mathcal{T},J,A,\tau )$; (iii) how the signal changes selection; (iv) agreement and calibration against independent anchors; (v) robustness under increased optimization pressure; (vi) sensitivity to evaluator identity, prompts, ordering, and contamination; and (vii) the provenance of direction and search space. Useful anchors include executable ground truth, formal verification, hidden human-authored tests, cross-model judging, delayed real-world outcomes, preregistered protocols, and randomized expert audits.

Self-evaluation is necessary but not sufficient.

STOP uses a language model to improve a scaffolding program that recursively improves solutions. The Darwin Gödel Machine iteratively edits an agent and empirically validates proposed modifications [24,70]. Under the fixed boundaries used in the application table, both systems are neighboring L1 systems. They become L3 only if an AI-produced evaluator or acceptance rule governs the next modification. Self-rewarding and meta-rewarding systems, by contrast, place learned evaluators inside iterative improvement loops. These systems demonstrate increasingly tight feedback between candidate and evaluator, but a single generation can benefit from evaluator drift, benchmark overfitting, or lucky search.

Claims must survive a frozen external evaluator.

A recursive-improvement claim should show that generation $g+1$ improves the mechanism that produces generation $g+2$. It should also show that gains persist across multiple generations and that each generation remains better under an evaluator frozen before the run. The evaluator itself must be versioned so that criterion changes are not mistaken for candidate improvement. AI4AI-Bench begins to isolate agents’ ability to modify training algorithms rather than merely tune hyperparameters or collect data [62]. Stronger evidence would combine such mechanism-level tasks with held-out domains, compute-matched baselines, lineage tracking, rollback tests, and external evaluation that the improving system cannot inspect or rewrite. L3 therefore marks control over evaluation; it becomes evidence for recursive self-improvement only when evaluator improvement and candidate improvement remain distinguishable across generations.

7. Applications and Benchmarks

Complementing the analysis of control in Section 4, Section 5 and Section 6, this section offers a distinct perspective through applications, examining what AI4AI improves and how those improvements are evaluated across domains. We organize the discussion into four families: AI4AI Learning, AI4AI Inference, AI4AI Data, and AI4AI Infrastructure. These cover improvements to learning procedures, frozen-model behavior, data, and the software and hardware stack. Figure 10 groups representative methods by these targets. The tables select representative methods that illustrate distinct application artifacts, retaining the earlier level labels and summarizing AI-produced artifacts alongside the human-provided setup. Methods with several applications may contribute to more than one family. Research workflows and shared evaluation components connect these families, while Table 10 connects representative benchmarks to AI4AI development tasks and their validation.

Figure 9. Overview of AI4AI applications organized by the target of improvement: Learning, Inference, Data, and Infrastructure.

Figure 9. Overview of AI4AI applications organized by the target of improvement: Learning, Inference, Data, and Infrastructure.

Figure 10. Taxonomy of AI4AI applications. Representative methods are organized by the artifact being improved: learning procedures, inference-time behavior and computation, data construction, and infrastructure artifacts or tool flows. Benchmarks are listed separately in Table 10. This application axis is orthogonal to the L0–L3 control hierarchy: methods in any branch may differ in whether AI controls the search direction, search space, or evaluation signal. A superscript ^* marks the same configuration-dependent condition used in the application tables; the figure is representative rather than exhaustive.

Figure 10. Taxonomy of AI4AI applications. Representative methods are organized by the artifact being improved: learning procedures, inference-time behavior and computation, data construction, and infrastructure artifacts or tool flows. Benchmarks are listed separately in Table 10. This application axis is orthogonal to the L0–L3 control hierarchy: methods in any branch may differ in whether AI controls the search direction, search space, or evaluation signal. A superscript ^* marks the same configuration-dependent condition used in the application tables; the figure is representative rather than exhaustive.

7.1. AI4AI Learning

AI4AI Learning improves procedures that update a target model’s parameters. Its artifacts include configurations, pipelines, architectures, optimizers, learning rules, rewards, adapters, and compressed or distilled models. This includes continuous prompt vectors and recovery training. The resulting model is evaluated after the discovered procedure has been applied.

Table 6. Representative AI4AI Learning methods, selected to illustrate distinct training artifacts. Level labels follow Section 4, Section 5 and Section 6.

Method	Level	AI-designed	Human-fixed
Configurations and training pipelines
Hyperband [78]		configurations promoted at each rung	search space, budget schedule, fidelity metric
auto-sklearn [3]		pipeline, hyperparameters, ensemble	pipeline grammar, meta-tasks, validation metric
PBT [7]		per-member hyperparameter schedule	config space, mutation operators, train budget
Architectures and update rules
DARTS [63]		mixed-op weights, then discrete cell	operator set, search space, validation loss
S3 [190]		admissible architectural value sets	ViT blocks, initial choices, budgets
VeLO [225]		learned update-rule weights	optimizer family, meta-training distribution
AutoML-Zero [9]		setup, predict and learn programs	primitive set, function set, meta-distribution
Parameter-updating post-training
Constitutional AI [17]		critiques, revisions, preference labels	constitution, harm rules, base model
Eureka [19]		executable training reward programs	task description, simulator, policy optimizer
STaR [137]		rationales and rationalizations	seed rationales, answer key, fine-tuning recipe
Adaptation and compression
AutoPEFT [230]		adapter types, sizes, insertion layers	adapter space, performance and parameter cost
AMC [231]		per-layer compression ratios	pruning space, latency constraint, recovery

Table 6. Representative AI4AI Learning methods, selected to illustrate distinct training artifacts. Level labels follow Section 4, Section 5 and Section 6.

Method	Level	AI-designed	Human-fixed
Configurations and training pipelines
Hyperband [78]		configurations promoted at each rung	search space, budget schedule, fidelity metric
auto-sklearn [3]		pipeline, hyperparameters, ensemble	pipeline grammar, meta-tasks, validation metric
PBT [7]		per-member hyperparameter schedule	config space, mutation operators, train budget
Architectures and update rules
DARTS [63]		mixed-op weights, then discrete cell	operator set, search space, validation loss
S3 [190]		admissible architectural value sets	ViT blocks, initial choices, budgets
VeLO [225]		learned update-rule weights	optimizer family, meta-training distribution
AutoML-Zero [9]		setup, predict and learn programs	primitive set, function set, meta-distribution
Parameter-updating post-training
Constitutional AI [17]		critiques, revisions, preference labels	constitution, harm rules, base model
Eureka [19]		executable training reward programs	task description, simulator, policy optimizer
STaR [137]		rationales and rationalizations	seed rationales, answer key, fine-tuning recipe
Adaptation and compression
AutoPEFT [230]		adapter types, sizes, insertion layers	adapter space, performance and parameter cost
AMC [231]		per-layer compression ratios	pruning space, latency constraint, recovery

7.1.1. Configurations and Training Pipelines

Hyperparameter optimization uses trial outcomes to choose configurations and allocate training resources. Bayesian optimization learns a response surface over validation outcomes [2]. Freeze–Thaw Bayesian optimization, Hyperband, BOHB, ASHA, and DEHB use partial learning curves or adaptive allocation to concentrate resources on promising trials [78,79,81,223,269]; SMAC3 and Optuna support conditional and mixed domains [80,270]. Random search provides a reference for the benefit of adaptation [1].

AutoML systems expand the target from a configuration to a pipeline composing preprocessing, model choice, and training [3,271,272]. Population-Based Training adapts schedules during training by copying model states and mutating hyperparameters [7]. Comparisons should include the full trial budget and the cost of interrupted, resumed, and unsuccessful runs.

7.1.2. Architectures and Update Rules

Neural architecture search optimizes cells and macro-structures through reinforcement learning, evolution, progressive expansion, learned predictors, differentiable relaxation, and shared-weight training [5,6,63,82,83,84]. Network Morphism reuses trained networks through function-preserving transformations, while BANANAS and Neural Predictor guide proposals using evaluated architectures [85,86,87,171]. Performance prediction and zero-cost proxies reduce screening cost [88,89,105]. MnasNet and ProxylessNAS incorporate device latency, and Once-for-All and BigNAS extract device-specific subnetworks from a trained supernet [90,224,273,274]. EfficientNet combines a searched base network with compound scaling [275].

The search domain can itself be adapted to the workload. DDSAS dynamically selects active edge–operation combinations; hierarchical generative NAS learns cell embeddings and cell-family abstractions; and S3 evolves admissible sets of architectural dimensions before the final search [172,173,190]. These are the architecture-design applications of the L2 methods in Section 5. LLMatic uses language-model variation and a quality-diversity archive to explore architectures [98]. SPARK, GraphIR, and ADSL-PDE expose structured edit surfaces through factors, intermediate representations, and a domain-specific language for neural solvers [226,227,228].

The update rule itself can be discovered. Learned optimizers and VeLO learn neural update rules; symbolic optimizer search and evolved reinforcement-learning losses discover compact learning programs; and AutoML-Zero evolves complete algorithms from mathematical primitives [8,9,65,225,276,277]. MAML learns initial parameters for rapid adaptation across tasks [64]. Transfer to held-out workloads, longer horizons, larger models, and altered data regimes tests the usefulness of the discovered procedure. Evaluation should place discovery or meta-training cost alongside downstream learning curves.

7.1.3. Parameter-Updating Post-Training

Learned feedback supports alignment and task-specific training. Preference-based reinforcement learning and InstructGPT fit rewards from comparisons; Constitutional AI and RLAIF use model-generated critiques or preferences to guide training [17,18,74,198]. Self-Rewarding Language Models produce their own preference judgments, Meta-Rewarding adds a judge of those judgments, and PandaLM applies model judgments to instruction-tuning hyperparameter selection [20,202,204]. These applications reuse the evaluation mechanisms reviewed in Section 6.3.

Executable reward design provides feedback for reinforcement learning. Text2Reward translates task descriptions into reward code, and Eureka revises reward programs using environment code and training results [19,203]. CodeRL trains a correctness critic for code-policy updates, PRM800K supplies human step supervision, and Math-Shepherd builds step-quality labels from rollout outcomes and uses process rewards for verification and PPO [75,194,196]. Self-training provides a complementary route: ReST^EM retrains on correctness-filtered solutions, STaR fine-tunes on successful rationales and rationalizations, and Quiet-STaR learns internal rationales through token-prediction feedback [137,145,229].

AutoPEFT and NOAH search trainable adaptation modules, while BBT and BBTv2 optimize continuous prompt vectors [124,125,230,278]. AMC, MetaPruning, AutoCompress, HAQ, AutoQNN, and AutoKD optimize pruning, quantization, or distillation choices with subsequent training [231,232,233,279,280,281]. Reports should separate discovery cost from adaptation or recovery cost and include trainable parameters, optimizer-state memory, and final model accuracy.

Benchmarks for AI4AI Learning.

NAS-Bench-101, NAS-Bench-201, NATS-Bench, and NAS-Bench-301 provide exact or surrogate outcomes over architecture spaces; TransNAS-Bench-101 adds task diversity and HW-NAS-Bench adds device costs [91,92,93,94,282,283,284]. HPO-B and HPOBench provide reproducible black-box and multi-fidelity optimization tasks [285,286]. For learned architecture spaces, comparisons should run the same search procedure over the constructed space and a human-designed counterpart at matched cost, following Section 5.2.

AI4AI-Bench asks agents to modify training algorithms in frozen repositories and reruns submissions from scratch under a hidden evaluator [62]. RE-Bench compares agents with human experts at matched time budgets on training, scaling-law, and kernel-optimization tasks [287]. Automated LLM Speedrunning measures reproduction of known training-speed improvements [288]. MLAgentBench, MLE-bench, MLGym, PaperBench, and MLReplicate assess experiment implementation and result replication [72,146,166,289,290].

PostTrainBench adds autonomous LLM post-training under a bounded compute budget, allowing agents to develop training strategies, curate data, and run experiments [291]. MLS-Bench requires improvements to targeted method components to generalize across controlled settings and scales, with edit scopes, capacity constraints, and repeated evaluation limiting alternative sources of gain [292]. Its catalog also includes ML systems tasks, so individual tasks may belong to other application families. These protocols strengthen evidence for method effectiveness and transfer; scientific novelty requires additional assessment.

7.2. AI4AI Inference

AI4AI Inference improves behavior while target-model and adapter parameters remain frozen. Its artifacts include discrete prompts and demonstrations, workflows, agent scaffolds, reusable tools and libraries, routing and context policies, and test-time computation policies. A search controller or recognition model may be trained to produce these artifacts; the target model is used without parameter updates.

Table 7. Representative AI4AI Inference methods, selected to illustrate distinct prompts, agents, libraries, and computation policies. Target-model and adapter parameters stay frozen.

Method	Level	AI-designed	Human-fixed
Prompt and workflow optimization
APE [68]		candidate instructions; final pick	proposal prompt, output format, task metric
GEPA [102]		reflection-guided edits and candidate selection	editable prompts, task feedback, budget
DSPy [130]		module instructions, few-shot demos	program signature, module set, program metric
Agent, tool, and library design
ADAS [14]		agent code: roles, tools, control flow	tool pool, role template, task and holdout sets
DreamCoder [175]		reusable program abstractions	base DSL, execution semantics, task examples
CRAFT [183]		specialized reusable tool library	runtime, task APIs, training tasks, validators
Voyager [141]		skills, curriculum, success judgments	Minecraft APIs, environment mechanics
Test-time reasoning and serving
Self-Discover [237]		chosen modules; reasoning structure	module library, selection rules, task metric
Input-adaptive allocation [238]		learned per-input compute budget	budget grid, cost model, task mix
AutoPrune [60]		token-pruning policy in the DSL	pruning DSL, token budget, task metric

Table 7. Representative AI4AI Inference methods, selected to illustrate distinct prompts, agents, libraries, and computation policies. Target-model and adapter parameters stay frozen.

Method	Level	AI-designed	Human-fixed
Prompt and workflow optimization
APE [68]		candidate instructions; final pick	proposal prompt, output format, task metric
GEPA [102]		reflection-guided edits and candidate selection	editable prompts, task feedback, budget
DSPy [130]		module instructions, few-shot demos	program signature, module set, program metric
Agent, tool, and library design
ADAS [14]		agent code: roles, tools, control flow	tool pool, role template, task and holdout sets
DreamCoder [175]		reusable program abstractions	base DSL, execution semantics, task examples
CRAFT [183]		specialized reusable tool library	runtime, task APIs, training tasks, validators
Voyager [141]		skills, curriculum, success judgments	Minecraft APIs, environment mechanics
Test-time reasoning and serving
Self-Discover [237]		chosen modules; reasoning structure	module library, selection rules, task metric
Input-adaptive allocation [238]		learned per-input compute budget	budget grid, cost model, task mix
AutoPrune [60]		token-pruning policy in the DSL	pruning DSL, token budget, task metric

7.2.1. Prompt and Workflow Optimization

AutoPrompt, GrIPS, and RLPrompt search discrete prompts using token substitutions, phrase edits, or a learned prompt policy [123,126,127]. APE generates and ranks instructions, ProTeGi uses error critiques to guide edits, OPRO conditions proposals on previous prompts and scores, and EvoPrompt and Promptbreeder apply evolutionary search [12,13,68,69,114]. PromptAgent plans prompt revisions, while TEMPERA learns test-time prompt-editing policies [122,128].

Compound applications optimize several prompts or model calls together. SAMMO searches structured prompt programs, DSPy compiles language-model pipelines, MIPRO jointly selects instructions and demonstrations, and TextGrad propagates textual feedback through a computation graph [101,129,130,131]. PromptWizard, CriSPO, and instruction-exemplar selection use task analysis or multi-aspect critiques, while local prompt optimization focuses on constrained edits [132,133,134,135]. GEPA combines execution-trace reflection with a Pareto archive to select targeted changes [102]. Comparisons should report optimization cost and transfer across tasks and models; OPRO re-evaluations also motivate disclosing the optimizer model, scorer, meta-instruction, and token budget [136].

7.2.2. Agent, Tool, and Library Design

ADAS searches agent programs containing roles, tool calls, memory, and control flow; AFlow searches code-represented workflows; and GPTSwarm optimizes node prompts and graph connectivity [14,234,235]. STOP and the Darwin Gödel Machine revise improver or agent code across validated iterations [24,70]. HERO extracts and recombines program edits for applications including agent design [236]. AI4AI at Test-Time studies a stronger builder that constructs routing, deterministic code, and answer-format controls for a weaker frozen target [61].

Reusable tools change the building blocks available to an agent. CREATOR constructs tools before planning their use, LATM caches generated Python tools, and Toolink builds task-family toolkits [180,181,182]. CRAFT abstracts solutions into a specialized toolset, TroVE grows and trims reusable functions, and ToolLibGen aggregates tools into libraries with unified interfaces [183,184,185]. Voyager accumulates executable skills together with a curriculum and self-verification, DynaSaur expands available actions, and Memento-Skills refines skills comprising specifications, scripts, and prompts [141,187,188]. ToolMaker realizes tools from supplied repositories, and SkillX constructs skill knowledge used as execution guidance [186,189].

Program-library learning provides a complementary route to reusable inference-time components. EC², DreamCoder, and drawing-program induction learn reusable subroutines; LAPS adds language supervision; Stitch compresses recurring program structure; and LILO combines synthesis, compression, and documentation [174,175,176,177,178,179]. These applications connect the library-construction work in Section 5 to downstream program synthesis and agent development. Their value depends on interface validity, reuse, and held-out task benefit, together with library construction and maintenance cost.

7.2.3. Test-Time Reasoning and Serving

Self-Discover selects and adapts reasoning modules into a task-specific structure [237]. Input-adaptive allocation learns how to distribute computation across inputs, and AutoPrune searches training-free visual-token pruning policies for frozen multimodal models [60,238]. Best-of-N, majority voting, and fixed verifier-guided search provide reference quality–cost curves for these policy-design applications [293]. Useful measurements include generated tokens, verifier calls, tool calls, latency, memory, and energy.

Verification components support selection and refinement of generated programs and reasoning traces. CodeT selects programs using generated tests and execution agreement, LEVER combines execution with a learned verifier, and outcome verifiers select among sampled mathematical solutions [191,195,212]. GenRM produces generative correctness judgments, and CRITIC uses tool feedback to guide revision [197,213]. These mechanisms supply evaluation components for the AI4AI loops reviewed in Section 6. Their contribution to a developed prompt, agent, or computation policy can be measured by replacing the verifier while matching candidates and serving budgets.

Benchmarks for AI4AI Inference.

AIE-Bench evaluates agents that build or modify agents, and VeRO-Bench evaluates versioned target–optimizer pairs under controlled budgets [294,295]. AgentBench, AgentBoard, and GAIA assess interactive task performance; SWE-bench and OSWorld provide software and computer-interaction environments for evaluating developed agents and tools [155,156,157,158,159]. Code-to-Play and ConceptSearch add program-search tasks over games and ARC-like problems [116,117]. Prompt and workflow studies should report optimization cost alongside task scores, with target models, tool access, and serving budgets held comparable.

AutoHarnessBench separates a proposer from a fixed-weight actor: the proposer revises the actor’s harness using bounded public feedback, and an independent evaluator compares the frozen result with the initial harness on held-out tasks [296]. ${\tau }^{\tau }$-Bench extends agent construction to client requirements, business records, inherited code, production APIs, and serving constraints, evaluating the delivered agent against held-out simulated users [297]. These protocols assess the development intervention as well as the resulting agent’s behavior.

7.3. AI4AI Data

AI4AI Data improves the examples, mixtures, transformations, and curricula used to develop AI systems. The discovered artifact is the data or data policy; downstream training tests its usefulness. Comparisons use a shared training recipe and report data construction and processing costs.

Table 8. Representative AI4AI Data methods, selected to illustrate distinct data artifacts and policies.

Method	Level	AI-designed	Human-fixed
Selection and mixing
DoReMi [239]		domain mixture weights	domain partition, reference model, excess-loss objective
LESS [241]		gradient-similarity scores; subset	target examples, warm-up recipe
Model-judged quality filtering
QuRating [245]		pairwise judgments; trained rater	named quality criteria, sampling rule
Augmentation and feature construction
AutoAugment [248]		op pairs, probabilities, magnitudes	operation set, magnitude bins, child model
LLM-FE [115]		evolved feature-engineering programs	tabular tasks, input schema, validation metric
Synthetic corpora and curricula
Self-Instruct [252]		new instructions, inputs and outputs	seed tasks, output format, heuristic filters
Automated curriculum [255]		which task to train on next	task set, progress signals

Table 8. Representative AI4AI Data methods, selected to illustrate distinct data artifacts and policies.

Method	Level	AI-designed	Human-fixed
Selection and mixing
DoReMi [239]		domain mixture weights	domain partition, reference model, excess-loss objective
LESS [241]		gradient-similarity scores; subset	target examples, warm-up recipe
Model-judged quality filtering
QuRating [245]		pairwise judgments; trained rater	named quality criteria, sampling rule
Augmentation and feature construction
AutoAugment [248]		op pairs, probabilities, magnitudes	operation set, magnitude bins, child model
LLM-FE [115]		evolved feature-engineering programs	tabular tasks, input schema, validation metric
Synthetic corpora and curricula
Self-Instruct [252]		new instructions, inputs and outputs	seed tasks, output format, heuristic filters
Automated curriculum [255]		which task to train on next	task set, progress signals

7.3.1. Selection and Curation

DoReMi optimizes domain weights with a proxy model; DSIR resamples toward a target distribution; LESS selects instruction data through gradient alignment; and JEST jointly selects batches using learner and reference-model losses [239,240,241,242]. SemDeDup supplies a semantic deduplication baseline [243]. Influence functions, TracIn, dataset cartography, and forgetting events offer complementary signals for diagnosing and selecting examples [298,299,300,301]. Rankings should be validated on disjoint data and across architectures.

Model-judged filtering makes quality evaluation part of corpus construction. AlpaGasus rates instruction–response pairs, QuRating learns a corpus rater from pairwise judgments, FineWeb-Edu distills educational-value annotations into a classifier, and Ask-LLM judges informativeness for pretraining [244,245,246,247]. These applications reuse the model judges reviewed in Section 6.3. Downstream value should be evaluated independently of the rater, including corpus coverage and sensitivity to rating prompts and thresholds.

7.3.2. Augmentation, Synthesis, and Curricula

AutoAugment, Population Based Augmentation, DADA, and SelfAugment search transformation policies or schedules [248,249,250,251]. SelfAugment uses a self-supervised proxy in place of labeled validation accuracy. Policies should be tested across child architectures and datasets, with controller cost separated from final training cost.

Self-Instruct, Evol-Instruct, Orca, UltraChat, and Magpie generate instructions, responses, or dialogues. Cosmopedia generates textbook-style pretraining text, and Nemotron-CC combines quality filtering with synthetic rephrasing [252,253,254,302,303,304,305]. The generator, quality filter, deduplication rule, and downstream recipe can be ablated separately at matched token budgets. LLM-FE adds a feature-engineering application by evolving programs for tabular learning [115].

Curriculum methods determine which tasks or environments supply subsequent training data. Automated curriculum learning treats task selection as a nonstationary bandit rewarded by learning progress [255]. POET, PAIRED, and LLM-POET generate or evolve environments together with agents [206,207,208]. Their generated environments serve as training artifacts, while their evaluation roles follow the component analysis in Section 6.5. Evaluation should test transfer beyond the construction curriculum.

Benchmarks for AI4AI Data.

DataPerf, DataComp, and DataComp-LM compare data artifacts under standardized downstream tasks and training protocols [306,307,308]. DataPerf covers several data-centric tasks, DataComp targets image–text pretraining, and DataComp-LM uses a standardized Common Crawl pool for language-model pretraining. Data-Juicer supplies processing infrastructure for such experiments [309]. Reports should include coverage, duplication, contamination, privacy, licensing, and fairness, and confirm proxy-scale rankings at larger model and data scales.

Synthetic-data evaluation adds complementary evidence. AgoraBench compares language models as data generators through standardized student-training outcomes, while DataEnvGym provides teacher environments in which generation policies adapt to student errors and skill feedback across training iterations [310,311]. The former isolates generation utility; the latter tests a feedback-driven data-construction process.

Curation-Bench holds the model, training recipe, and evaluator fixed while agents inspect data and iteratively implement selection policies; its vision–language instruction-tuning experiments distinguish successful execution from effective research exploration [312]. RSIBench-Data evaluates data-centric post-training research through capability-gap diagnosis, data strategies, and checkpoint feedback using shared training and evaluation services [313]. Because it also permits changes to specified training settings, reports should identify which gains arise from data and which involve learning-procedure changes. Training a student to assess data value does not by itself change the primary domain from Data to Learning.

7.4. AI4AI Infrastructure

AI4AI Infrastructure improves the software and hardware stack used to train and serve AI: algorithms, kernels, tensor programs, compiler schedules, parallel execution plans, accelerators, RTL, and physical design. Artifacts are evaluated through execution, compilation, simulation, or hardware measurement. General-purpose logic and EDA methods provide complementary techniques for this stack; Table 9 identifies their application scope.

7.4.1. Kernels and Tensor Programs

AlphaTensor searches matrix-multiplication algorithms, and AlphaDev searches assembly implementations of sorting routines [66,67]. AutoTVM, Ansor, and the Halide autoscheduler optimize tensor-program schedules with learned cost models [256,257,258]. LLM-driven kernel evolution extends the target to CUDA source and dispatch logic [118]. AlphaEvolve applies program evolution to a matrix-multiplication tiling heuristic used in Gemini training and an arithmetic-circuit simplification for a TPU [11].

Evolutionary program systems provide reusable optimization machinery for these applications. FunSearch, OpenEvolve, ShinkaEvolve, and CodeEvolve maintain archives and generate edits from successful lineages [10,95,96,100]. Algorithm Evolution and Evolution of Heuristics combine algorithmic ideas with implementations; Evolution through Large Models, Language Model Crossover, and LLM evolutionary optimizers or surrogates supply proposal and variation mechanisms [97,109,110,111,112,113]. SBLLM retrieves code-optimization patterns, while SeaEvo, graph-augmented evolution, and adaptive population handoff organize strategy archives [99,106,119,120]. Their infrastructure applications are assessed on the executable algorithm or implementation produced. EvoTrace and evolutionary-search ablations distinguish structural changes from constant tuning, rediscovery, and additional sampling [107,121].

Kernel comparisons should cover tiling, warp mapping, memory layout, fusion, and dispatch under a common correctness and timing harness. Shapes, dtypes, strides, masks, and numerical tolerances belong in correctness tests. Search and compiler costs should accompany steady-state speedups.

7.4.2. Execution Plans and Hardware Co-Design

FlexFlow searches distributed-training parallelization strategies with an execution simulator [259]. Apollo optimizes accelerator parameters under area constraints, and NAAS jointly searches accelerator architecture, compiler mapping, and neural architecture [260,261]. ArchGym supplies common interfaces between searchers and architecture simulators [314]. Co-design studies should report fixed-compiler and retuned-compiler comparisons, multiple devices, search cost, and quality–latency–energy–area trade-offs.

7.4.3. Logic, RTL, and Physical Design

DRiLLS and PrefixRL search synthesis sequences and parallel-prefix circuits; AlphaChip, AutoDMP, and MaskPlace optimize macro placement or placement parameters [262,263,264,265,315]. AlphaChip and PrefixRL have been applied to production TPU and GPU blocks, respectively. AutoChip, ChatEDA, and MCP4EDA connect language-model generation to compilation, simulation, or RTL-to-GDSII feedback [266,267,268]. VeriGen and RTLCoder supply learned HDL generation, GPT4AIGChip targets AI accelerator generation, and DeepGate supplies circuit representations for the surrounding design process [316,317,318,319]. Evaluation should separate generation, repair, and tool orchestration and validate final power, performance, and area (PPA) with independent verification.

Benchmarks for AI4AI Infrastructure.

KernelBench evaluates GPU kernels through correctness and speedup over PyTorch reference workloads [320]. CompilerGym and ArchGym provide compiler and architecture search environments with runtime, code-size, or simulator costs [314,321]. VerilogEval and RTLLM evaluate HDL correctness and design quality, ChipBench covers hierarchical Verilog generation, and ChiPBench evaluates placement through a full physical-design flow [322,323,324,325]. RE-Bench includes a kernel-optimization research task [287]. Reports should include compile or synthesis success, latency distributions, memory traffic, energy, verification coverage, PPA, tool runtime, and transfer across shapes, devices, designs, and technology libraries.

FastKernels checks whether kernel-level gains persist inside production-model execution paths, while $\Phi$-Bench extends evaluation to repository-level implementation and end-to-end optimization of training and inference infrastructure [326,327]. KernelGenBench evaluates generated Triton kernels across operator sources and hardware platforms, adding controlled evidence about deployment transfer and its cost [328]. MetaKernelBench instead transfers a natural-language skill distilled from one optimization attempt to a fresh attempt at the same problem in another domain-specific language [329]. This diagnostic remains within Infrastructure: it measures same-problem, cross-language knowledge reuse, which should be distinguished from transfer to new tasks or hardware.

7.5. Research Workflows and Shared Evaluation

Research workflows connect the application families.

ResearchAgent proposes literature-grounded ideas; The AI Scientist, The AI Scientist-v2, and Agent Laboratory connect ideation or a supplied goal to experiments and reporting [15,16,71,73]. MLE-STAR refines machine-learning pipelines through search and ablations, AutoResearchClaw maintains persistent research evidence, and Jr. AI Scientist extends a baseline paper [103,104,147]. Their application is the development workflow: an investigation can modify a training recipe, data policy, inference scaffold, or implementation. The direction-selection components in Section 4.5 support these changes, and automated reviewers supply complementary evaluation components.

Data Interpreter, MetaGPT, AutoGen, AgentVerse, and AgentScope provide planning and coordination; AgentCoder, SWE-agent, and Agentless provide code-development and repair mechanisms [148,149,150,151,152,153,154,161]. MemoryBank, MemGPT, ExpeL, and Generative Agents offer memory and experience-management techniques that can support artifact improvement [138,139,140,142]. Multi-agent aggregation also provides a compute baseline for coordinated workflows [160]. Workflow comparisons should track experimental validity, reproducibility, implementation failures, and discovery cost alongside artifact quality [108,162,163,164,165].

AIRS-Bench evaluates idea generation, implementation, experiment analysis, and iterative refinement on paper-derived research tasks without supplying baseline code [330]. RSIGym supplies shared research services with Data, Harness, and Joint tracks, allowing component-specific studies and joint optimization of data, training settings, and execution harnesses [331]. These are complementary research protocols across the four application families. Their domain coverage follows the actual task and permitted intervention; an extensible environment does not establish coverage of every family, and each track’s fixed components should be reported separately.

Evaluation components serve several applications.

ChatUniTest and CodeJudge supply generated tests and semantic code judgments; MT-Bench judging, G-Eval, JudgeLM, Prometheus, and Prometheus 2 provide reusable model judges [21,192,193,199,200,201,214]. Their use across training, data filtering, and agent development follows the integration analysis in Section 6. Red teaming and AutoRISE supply adaptive adversarial tests; debate, scalable oversight, CriticGPT, and weak-to-strong supervision combine AI-produced evidence with human oversight [169,205,209,210,211,215]. Independent checks should test evaluator agreement, calibration, model and style biases, and resistance to optimization pressure [21,22,23,219,220,221,222].

Benchmarks for research diagnostics.

WhatWorkedBench measures experimental understanding by asking agents to acquire budgeted measurements and reconstruct configuration responses, conditional component effects, and interactions [332]. It complements the direction-selection analysis in Section 4.5 by assessing what agents learn from experiments beyond their best observed score. BenchBench evaluates the validity, discrimination, and interaction biases of automatically generated test suites [333]. EvalResearchBench evaluates budgeted task selection or synthesis, grader implementation, and pilot-driven revision, followed by independent assessment of the frozen evaluator’s measurement quality and execution cost [334]. These evaluation-design benchmarks provide evidence relevant to E. Under Section 6, an L3 assignment additionally requires that the AI-produced signal becomes operative in a specified improvement loop; independent outer scoring can remain human-defined.

Comparable application evidence.

Across the four families, evaluation should report artifact quality, total discovery cost, transfer, and variation across runs. Table 10 links each benchmark to an AI4AI development task, the protocol used to assess it, and the evidence it provides. Some protocols run the optimizer or research agent, while others validate the resulting architecture, dataset, agent, or implementation through shared downstream tests. Search and deployment costs should be separated, including failed trials. MLReplicate adds reproducibility checks, while SciIntegrity-Bench tests research integrity through dilemmas that place honest acknowledgment of failure in conflict with task completion [166,167]. Together with the application-specific measures above, these protocols connect the direction, space, and evaluation mechanisms reviewed earlier to observable benefits in AI development.

System domains and assessment roles should remain separate from method-level responsibility profiles. A fixed task permits history-conditioned direction selection, while evidence for AI-provided search space requires tracing changes to active representations or constraints rather than candidate code alone. Repeated research runs should test whether benefits survive variation in experimental trajectories. Recursive progress requires an additional comparison: accepted changes must improve how subsequent improvements are produced. RSIGym’s current experiments do not establish this subsequent-cycle benefit [331]. Thus, improved artifacts, reusable research knowledge, and improved future discovery require distinct evidence.

Table 10. Representative benchmarks for AI4AI development. Domain groups indicate primary targets; the cross-family group covers research workflows, experimental understanding, and evaluator design.

Benchmark	AI4AI task	Evaluation protocol	Evidence provided
AI4AI Learning
NAS-Bench-201 [92]	Select neural architectures for training	Query tabulated outcomes under a shared cell space and training recipe	Accuracy or regret versus search cost
HPOBench [286]	Tune hyperparameters and allocate trial budgets	Compare optimizers on common datasets, spaces, and fidelities	Anytime performance and cost to reach target quality
AI4AI-Bench [62]	Redesign training algorithms	Rerun edited code from scratch against the original algorithm; hidden evaluator	Capability gain from the revised learning procedure
AI4AI Inference
AutoHarnessBench [296]	Improve a fixed actor’s execution harness	Separate proposer and actor; freeze the selected harness after public trials; assess held-out lift	Generalization of harness improvements and research cost
${\tau }^{\tau }$-Bench [297]	Build a deployable task agent	Construct from client requirements, business records, APIs, and inherited code; test with held-out simulated users	Delivery success under serving constraints
AI4AI Data
DataComp [307]	Select or filter multimodal training data	Train CLIP with a shared recipe and compute scale	Downstream gains from the submitted dataset
DataEnvGym [311]	Construct training data from student feedback	Iterate generation, student training, and evaluation in shared teacher environments	Student gains across rounds and use of feedback
Curation-Bench [312]	Discover data-selection policies	Fix the model, training recipe, and evaluation; iterate executable data policies	Data efficiency and research behavior beyond execution
AI4AI Infrastructure
KernelBench [320]	Generate and refine ML GPU kernels	Execute against PyTorch references on specified hardware	Fraction correct and faster than a speedup threshold
$\Phi$-Bench [327]	Engineer training and inference infrastructure	Implement and optimize real-repository tasks; gate rewards on correctness and anti-hacking checks	Repository-level functionality and performance
ChiPBench [325]	Optimize chip-placement methods	Run placements through a shared downstream physical-design flow	Final routed PPA beyond intermediate placement proxies
Cross-family AI research and evaluation
RE-Bench [287]	Automate ML research engineering	Compare agents and human experts under matched time budgets	Task improvement versus time and monetary cost
PaperBench [290]	Reproduce AI research methods and experiments	Execute submitted code in a fresh environment; grade with paper-specific rubrics	Weighted replication score over implementation and result checks
WhatWorkedBench [332]	Understand effects of experimental changes	Buy limited configuration measurements; predict effects and interactions against exhaustive references	Effect recovery, configuration choice, and experimental understanding
EvalResearchBench [334]	Construct reliable executable evaluators	Select or synthesize tasks, implement graders, and pilot within budgets; freeze for independent assessment	Score/rank agreement and execution cost

Table 10. Representative benchmarks for AI4AI development. Domain groups indicate primary targets; the cross-family group covers research workflows, experimental understanding, and evaluator design.

Benchmark	AI4AI task	Evaluation protocol	Evidence provided
AI4AI Learning
NAS-Bench-201 [92]	Select neural architectures for training	Query tabulated outcomes under a shared cell space and training recipe	Accuracy or regret versus search cost
HPOBench [286]	Tune hyperparameters and allocate trial budgets	Compare optimizers on common datasets, spaces, and fidelities	Anytime performance and cost to reach target quality
AI4AI-Bench [62]	Redesign training algorithms	Rerun edited code from scratch against the original algorithm; hidden evaluator	Capability gain from the revised learning procedure
AI4AI Inference
AutoHarnessBench [296]	Improve a fixed actor’s execution harness	Separate proposer and actor; freeze the selected harness after public trials; assess held-out lift	Generalization of harness improvements and research cost
${\tau }^{\tau }$-Bench [297]	Build a deployable task agent	Construct from client requirements, business records, APIs, and inherited code; test with held-out simulated users	Delivery success under serving constraints
AI4AI Data
DataComp [307]	Select or filter multimodal training data	Train CLIP with a shared recipe and compute scale	Downstream gains from the submitted dataset
DataEnvGym [311]	Construct training data from student feedback	Iterate generation, student training, and evaluation in shared teacher environments	Student gains across rounds and use of feedback
Curation-Bench [312]	Discover data-selection policies	Fix the model, training recipe, and evaluation; iterate executable data policies	Data efficiency and research behavior beyond execution
AI4AI Infrastructure
KernelBench [320]	Generate and refine ML GPU kernels	Execute against PyTorch references on specified hardware	Fraction correct and faster than a speedup threshold
$\Phi$-Bench [327]	Engineer training and inference infrastructure	Implement and optimize real-repository tasks; gate rewards on correctness and anti-hacking checks	Repository-level functionality and performance
ChiPBench [325]	Optimize chip-placement methods	Run placements through a shared downstream physical-design flow	Final routed PPA beyond intermediate placement proxies
Cross-family AI research and evaluation
RE-Bench [287]	Automate ML research engineering	Compare agents and human experts under matched time budgets	Task improvement versus time and monetary cost
PaperBench [290]	Reproduce AI research methods and experiments	Execute submitted code in a fresh environment; grade with paper-specific rubrics	Weighted replication score over implementation and result checks
WhatWorkedBench [332]	Understand effects of experimental changes	Buy limited configuration measurements; predict effects and interactions against exhaustive references	Effect recovery, configuration choice, and experimental understanding
EvalResearchBench [334]	Construct reliable executable evaluators	Select or synthesize tasks, implement graders, and pilot within budgets; freeze for independent assessment	Score/rank agreement and execution cost

8. Open Questions and Future Works

The preceding sections organized AI4AI by the source of control over direction, search space, and evaluation. This section addresses two complementary questions: what remains unresolved about AI-controlled discovery, and what evidence and research methods would be needed to address these gaps.

8.1. Open Questions

When is research control worth delegating? AI-provided direction, search space, or evaluation does not necessarily improve research quality [38,163]. The value of delegation may depend on how quickly errors become observable, whether their consequences are reversible, how costly independent verification is, and how much human effort the decision would otherwise require [215]. These properties need not favor the same responsibility profile across domains or stages of a project. Control variables may also interact: a constructed space may be productive only under a compatible direction policy, while that policy may depend on feedback that an existing evaluator cannot provide. Which task properties predict these dependencies, and when does joint delegation outperform selective delegation?

Answering this question requires separating decision provenance, causal influence, and beneficial contribution. An AI-generated decision may change the search trajectory without improving it; observed gains may also reflect mechanisms other than the one a system claims to introduce [107,170]. A small intervention may instead unlock discoveries that would otherwise remain inaccessible. Can these effects be identified through controlled interventions rather than inferred from system descriptions? More broadly, should research autonomy be a fixed configuration or a revisable allocation of authority that changes with evidence, uncertainty, and failure risk?

Can AI expand the boundaries of practical discoverability? A sufficiently expressive language may already represent a desirable algorithm without making it discoverable within a realistic budget. New abstractions, primitives, and composition rules can shorten useful descriptions, alter search neighborhoods, or eliminate unproductive combinations without necessarily enlarging the set of theoretically expressible solutions [171,175,179]. The central question for search-space construction is therefore not simply whether AI can propose more candidates, but whether it can make previously inaccessible, high-quality solutions practically reachable. When does a learned representation expand this frontier, and when does it merely encode a narrow preference for familiar solutions?

The same question extends to the organization of discovery. Recent systems illustrate both progress and remaining constraints. AIDE² recursively improves research-agent mechanisms while retaining a fixed benchmark-based acceptance rule [335]. The Agentic Scientist supports AI-generated task interfaces and evaluators, but its main empirical studies rely on manually prepared tasks, and reliable task construction remains challenging in complex settings [336]. At a given unit of analysis, AI may provide D, S, and E while higher-level rules for maintaining hypotheses, decomposing experiments, accumulating evidence, and coordinating research programs remain human-designed. Can AI identify limitations in this organization and improve the research workflow itself? Such changes can be analyzed by shifting the unit of analysis rather than introducing another autonomy level. Whether improved workflows transfer beyond the settings in which they were discovered remains a separate question from whether they improve the current run.

What establishes progress when evaluation itself evolves? When a candidate system and its evaluator change together, increasing internal scores does not isolate capability improvement from changes in the measurement procedure. Even a fixed proxy can become unreliable under stronger optimization [23,222], while evolving model-based judgments introduce further risks of changing standards and shared biases [22,204]. A revised evaluator may detect previously overlooked failures, but it may also reward easier tasks, favor the generator’s characteristic outputs, or relax acceptance conditions. These effects can influence not only the current ranking but also which evidence becomes available to later discovery cycles. How can a system distinguish better measurement of an intended objective from an unintended change in what it is optimizing?

Reliable assessment requires evidence that is not reducible to the improving loop’s own judgments. Such grounding need not consist exclusively of human ratings: it may include executable checks, independent experiments, hidden tests, or delayed observations [75,195,215]. However, each anchor has a limited scope. Formal correctness does not establish scientific importance, and agreement with a simulator does not establish validity in the target environment. What combination of independent evidence is sufficient for a particular discovery claim? How does the required verification budget scale with optimization pressure, discovery horizon, and shared errors between generator and evaluator? Any assurance must remain conditional on the validity and coverage of these anchors.

When do local improvements become cumulative research knowledge? An artifact can be useful without revealing why it works, when its advantages persist, or how it should inform subsequent designs. The stronger question is whether AI4AI can convert experimental outcomes into knowledge that supports new predictions and discoveries. Prior work on learned program libraries and experiential learning provides starting points for reusable abstractions and accumulated knowledge [140,175,179]. Such knowledge might take the form of executable abstractions, experimentally supported design rules, or validated negative results with explicit applicability conditions. It need not be immediately reducible to a concise human-readable explanation, nor must every constituent be unprecedented. Its research value depends on whether others can test, reuse, and revise it.

What representations allow successful discoveries to remain reusable without turning contingent observations into rigid assumptions? Approaches based on persistent skill libraries show one way to carry experience forward [141,188], but the ability to preserve conflicting evidence and recognize misleading abstractions remains an open question. Most importantly, how can the contribution of accumulated knowledge be distinguished from access to more compute, longer histories, or stored solutions? A convincing account of cumulative discovery should explain how inherited knowledge changes the productivity of research on genuinely new problems, not merely how it reproduces previous successes.

When does recursive self-improvement become sustained and reinforcing? Successive improvements to an artifact do not establish that the mechanism producing those improvements has become more capable. Likewise, repeated self-modification does not, by itself, establish sustained gains in research productivity [24,70]. A claim of recursive benefit requires evidence that an earlier improvement strengthens the production of later improvements. Recent tests of self-improving research agents illustrate both the relevance and difficulty of measuring this effect independently [335]. Under what conditions does this feedback remain beneficial across generations, and when does it saturate because verification, experimentation, or accessible novelty becomes the limiting factor? Sustained improvement and accelerating improvement are also distinct claims; neither should be inferred from generation count alone.

The relevant feedback may extend beyond a single self-editing agent. AI-assisted methods have already produced advances in algorithm discovery, data optimization, and computational infrastructure [11,239,256]; these advances do not, by themselves, establish recursive benefits across these areas. Can improvements in inference, learning, data, and infrastructure reinforce one another after accounting for integration costs, verification overhead, and resource constraints? Conversely, which dependencies prevent local gains from propagating through the wider AI development process? These questions concern the dynamics of improvement rather than its control label: an externally evaluated loop may exhibit recursive gains, while an AI-evaluated loop may fail to do so.

8.2. Future Work

Causal evaluation and adaptive allocation of research control. Future evaluation environments should expose D, S, and E as inspectable, versioned components that can be replaced independently or jointly where their interfaces permit meaningful comparisons. Reproducible search benchmarks and trajectory-level analyses offer useful starting points, but need to be extended to comparisons of control-source changes [91,107,287]. Runs should share initial targets and resource constraints while recording human effort, candidate histories, rejected directions, space revisions, evaluator changes, and rescue interventions. Comparisons should distinguish whether a component changes the discovery trajectory from whether that change improves independently assessed outcomes. Joint interventions are needed to reveal interactions that single-component ablations may miss.

These environments could support adaptive delegation policies that allocate authority according to uncertainty, decision consequences, and verification cost, extending concerns already raised in work on automated learning and scalable oversight [38,215]. Such policies should also specify when to seek external approval or restore an earlier configuration. Their objective would be reliable research productivity under resource and risk constraints, rather than maximizing the number of AI-controlled variables. This would make evolving responsibility profiles experimentally testable choices about how research should be organized.

Open-ended search-space construction and meta-discovery. Research systems should be able to construct and revise candidate representations, reusable primitives, composition operators, and task-specific admissibility constraints within explicit external boundaries. Program abstraction learning and dynamic search-space methods provide partial precedents [173,175,179]. Suitable tasks would require the system to diagnose why an existing representation obstructs progress and then propose a space-defining artifact that supports subsequent discovery. Both expansion and compression should be permitted: a smaller space may be more productive if it removes irrelevant combinations while preserving useful alternatives.

Evaluation should include the cost of constructing the space and test its utility on unseen tasks with multiple compatible search procedures. This can help separate reusable space quality from adaptation between one representation and one search policy. A complementary direction is to make experimental decomposition, hypothesis management, and evidence-update protocols editable research objects, building on broader work on automated agent and workflow design [14,234]. Improvements to these mechanisms should be tested through independent replay and transfer, while execution permissions, resource limits, and non-negotiable validity requirements remain outside the system’s unilateral control.

Independently grounded evaluator co-evolution. A promising experimental design separates an adaptive internal evaluator from an independent validation path. Research on AI-generated rewards and meta-judges illustrates mechanisms for constructing or refining internal evaluation signals [203,204]. The internal evaluator may generate tests, revise judgment mappings, or improve feedback as new failures emerge. The validation path should assess whether those revisions remain faithful to the intended objective and should not be rewritable by the improving system during the same run. Independence should be investigated through error analysis and interventions rather than assumed from different model names, given documented biases in model-based judgments [22,219].

Experiments should vary search intensity, discovery horizon, and evaluator flexibility while measuring false acceptance, false rejection, and divergence between internal scores and external outcomes wherever independently assessed outcomes are available. Evaluating optimized high-scoring candidates is essential because static evaluator quality may not survive optimization pressure [23,222]; rejected candidates should also be sampled to detect discoveries that a biased evaluator excludes. Longer studies could use pre-specified audit updates and cross-version calibration, with fresh audit data unavailable to the optimizing loop. The resulting evidence could characterize how verification requirements scale, rather than treating evaluator accuracy on a fixed candidate distribution as sufficient.

Knowledge-producing research memory. Research memory should preserve more than successful candidates and their scores. Existing systems have demonstrated the utility of retaining experiences, skills, and reusable program abstractions [140,141,179]. Structured records can connect hypotheses, implementation versions, experimental conditions, failures, applicability boundaries, and replication results. Proposed abstractions should retain links to supporting and conflicting evidence so that later systems can inspect their provenance and revise them when conditions change.

Knowledge extraction should be evaluated through its downstream consequences. One system could infer a design rule from historical experiments, while another independently implements it and tests predictions on unseen tasks. Ablations should distinguish access to original artifacts, raw histories, textual summaries, and reusable abstractions under comparable budgets. Shared repositories should also support negative and retracted findings, allowing accumulation to reduce redundant exploration rather than merely enlarge the archive. The central outcome is whether inherited knowledge enables new discoveries more effectively, not whether the system produces persuasive retrospective explanations.

Longitudinal and cross-family recursive-improvement experiments. Multi-generation studies should evaluate both the current artifact and the system’s ability to produce subsequent improvements. Initial work on self-improving agents and benchmarks for AI algorithm design motivates this distinction [62,70,335]. Each generation should be tested on common starting targets and held-out research tasks under matched budgets. Relevant controls include a frozen initial improver, a system that accumulates history without modifying its research mechanism, and alternatives given equivalent additional computation. Selective rollback and interrupted inheritance can test whether later gains causally depend on earlier discoveries.

Integrated environments could further allow improvements to propagate across Learning, Inference, Data, and Infrastructure. Existing work demonstrates optimization within several of these areas, but not necessarily a closed, mutually reinforcing cross-family loop [11,239,256]. Experiments should separately report research capability at fixed resources, gains from reinvesting saved resources, and the total cost of validation and integration. Blocking individual feedback paths would reveal whether cross-family coupling adds value beyond isolated improvements. Measuring progress against both resource use and elapsed time would help distinguish persistent productivity gains from apparent acceleration caused by changing budgets or shorter discovery cycles.

AI4AI4Science: discovering AI methods for scientific discovery. AI4AI4Science extends this agenda to the AI-driven discovery of methods that enable scientific progress. Work on algorithmic discovery and automated scientific research provides relevant foundations [10,11,15], but AI4AI4Science specifically targets improvements to the AI methods used in scientific inquiry. These methods may include representations, architectures, learning rules, data strategies, inference procedures, and computational implementations. Their ultimate value is assessed through the scientific investigations they make possible. The defining intervention is a substantive AI-originated change to a scientific AI method, rather than simply executing a fixed AI-assisted research workflow.

Future environments could couple scientific bottleneck diagnosis with AI-method construction. In scientific computing, a system might respond to numerical or long-horizon prediction failures by proposing new solver representations, training objectives, or computational implementations; automated design of neural PDE solvers offers a relevant starting point [228]. In molecular or materials research, it might revise generative methods, uncertainty estimation, or experimental acquisition strategies when evidence exposes limitations in existing approaches. These examples are proposed research settings, not evidence that reliable end-to-end AI4AI4Science loops have already been established.

Evaluation should establish both methodological and scientific value. First, the discovered AI method should be compared with appropriate baselines under matched data, compute, and experimental conditions. Second, its gains should translate into independently supported scientific outcomes, more reliable predictions, or lower costs of obtaining useful evidence. Improvements against a surrogate model or simulator must not be equated with scientific validation. Studies of benchmark and metric failures in automated research, alongside reward overoptimization, illustrate why internal or proxy improvements require careful interpretation [23,163]. Stronger evidence may require higher-fidelity computation, independent measurements, or physical experiments. The long-term research objective is a reciprocal process in which scientific problems motivate new AI methods, and independently validated method improvements expand the range of scientific questions that can be investigated.

9. Conclusion and Limitations

AI4AI research can be analyzed through changing sources of control over the discovery loop: who specifies how to explore, where to explore, and what counts as progress. This survey formalizes these differences through a Direction–Space–Evaluation ladder. Under the proposed taxonomy, the highest-ranked AI-provided component determines a system’s level. L0 serves as the reference level, with direction, space, and evaluation specified by humans. L1 denotes AI-provided direction while space and evaluation remain human-authored. L2 denotes AI-provided search space with human-authored evaluation, regardless of who supplies direction. L3 denotes AI-provided evaluation regardless of who supplies direction or space.

Higher levels are not guaranteed to produce better systems. At L1, promising directions may not translate into successful experiments [162], and learned exploration strategies may fail to transfer across tasks, scales, or optimization horizons [225,276]. Learning from execution can also improve average outcomes without improving the best discoveries. At L2, richer representations do not necessarily yield more usable search spaces. Learned abstractions may be difficult to compose or reuse [179], while observed gains may come from additional sampling rather than the constructed space itself [170]. At L3, evaluation errors can become selection pressures. Signals that perform well on fixed candidates may become unreliable under sustained optimization [23,222], and more faithful evaluation can consume resources otherwise available for discovery [78,105].

Across levels, end-to-end improvements do not by themselves identify which control mechanism contributed to progress [107,121]. Comparisons must separate changes in research control from differences in underlying models, experimental infrastructure, and computational investment [170,287]. Jointly adapting control mechanisms introduces a further challenge: stronger task performance does not establish a stronger capacity for subsequent self-improvement [62,70]. Overall, the proposed taxonomy provides a systematic basis for comparing AI4AI systems, while distinguishing the allocation of research control from evidence of its effectiveness.