AIC HILLES: Automatically Uncovering Hidden Weaknesses in AI-Evolved Systems Yajie Zhou∗ , Ao Li† , Ashwin Silla† , Zaoxing Liu∗ , Vyas Sekar† ∗ University of Maryland, College Park
arXiv:2606.15834v1 [cs.AI] 14 Jun 2026
† Carnegie Mellon University
Abstract—The computer systems community has recently seen growing interest in AI-driven system evolution, where AI agents iteratively rewrite systems. Frameworks such as AdaEvolve and Engram report 12–60% score improvements over human-designed algorithms. While these results are promising, there are practical concerns if these AI-evolved programs can perform worse on unseen workloads and exhibit scalability regressions. Given the speed and scale of AI-generated code, we need automated mechanisms to uncover such identify hidden weaknesses in AI-evolved systems programs. To this end, we develop AIC HILLES that takes as input a baseline program P and an AI-evolved program P ′ , AIC HILLES searches for valid workloads where P ′ regresses relative to P in correctness, runtime, memory usage, or output quality. To tackle the diversity in system applications, weakness types and potential bugs, AIC HILLES combines deterministic workload-parameter extraction, agent-based constraint inference, differential oracles, and code-frequency coverage to discover diverse failures. Across five system applications and 30 AI-evolved programs, AIC HILLES finds 49 distinct hidden weaknesses. We also show that explicitly including AIC HILLES in the AI-driven development lifecycle can mitigate several of these weaknesses.
1. Introduction AI is increasingly being used to optimize core system algorithms [7], [9], [10], [11], [18], [20], [25]. This has generated substantial excitement in systems research and industry. In essence, these frameworks follow the lead of AlphaEvolve [30] and cast algorithm design as an agentic code-improvement loop. For example, Google uses AlphaEvolve to improve agricultural and crop protection supply chain management [33]. Researchers have also explored this paradigm across diverse system problems [11], transaction scheduling [8], expert parallelism load balancing [13], multicloud job scheduling [38], LLM prefix-cache optimization [26], KV-cache management for model placement [39], and improving AI systems for industry [35]. Many of these frameworks have emerged within this broader AI-driven system optimizations (ADSO) design paradigm (e.g., OpenEvolve [34], AdaEvolve [7], Engram [20]). At a high level, they follow a similar workflow even if they may differ in specific design choices. To eliminate or minimize the human effort in designing heuristics, they use an AI agent to synthesize a candidate program that is an evolved version of an original program. They include an evaluator whose function is to score the program
Inputs
Output
KPI score Initial program 𝑃 Fixed workload 𝑊
AI-evolution
Evolved program 𝑃′
Higher KPI under 𝑊
System crashes? Adversarial workload 𝑊 ! ?
Security Testing on 𝑃!
Resource explosion? KPI degradation?
Figure 1: AI-driven system optimization creates an evolved program P ′ to improve the solution quality over the initial (human-designed) program P . We find adversarial workloads where P ′ instead has lower KPIs, higher resource usage, or crashes. on a fixed set of workloads. The highest-scoring program candidates are fed back into later rounds, and this runs in an evolutionary loop. While this excitement to reduce human effort and improve solution optimality is understandable, we also have reason to proceed with caution when these AI-generated programs are used in critical systems applications. In particular, AI-evolved programs can be more complex than the original human-designed heuristics and/or overfit to the workloads used in the agentic loop. In operational systems, such hidden weaknesses can lead to system crashes, hidden DoS vectors due to excessive resource consumption, and suboptimal solution quality for future workloads. This concern is not merely hypothetical. We encountered this risk by manually inspecting the AI-evolved version of Prism, a model-placement application for LLM serving [39]. The original program uses a compact greedy policy to allocate the model to the least loaded GPU. In contrast, we saw that the AI-evolved version replaces this single pass with a complex heuristic with multiple ordering strategies, multiple placement objectives, and an aggressive local search over swaps, moves, and bottleneck-GPU refinements. While this yields impressive wins on the tested workloads, it can actually be much worse on other workloads. Furthermore, the complexity increases compute/memory cost, which is a serious robustness concern since this program logic is on the critical path of scheduling decisions.
Given the fast pace of AI-driven system output and code changes, we need automated ways to identify such weaknesses. However, this is challenging on four fronts that make it difficult to directly apply existing techniques in program testing and fuzzing (e.g., [15], [22], [32]). First, we need to handle a diverse set of applications with very different input workloads and parameter spaces; e.g., one workload may be a tuple of integer parameters such as the number of GPUs, nodes, experts, and replicas, while another may involve a sequence of read and write operations. Second, our goal is to find a divergence weakness where the evolved program performs worse than the reference program on the same valid input. Third, we want to support a diverse set of properties of interest (e.g., optimality, correctness, resource use). Fourth, AI-generated code may introduce multiple points or paths of failure and we want to uncover as many diverse root causes under a fixed time budget. We tackle these challenges in designing and implementing AIC HILLES, an agentic system that uncovers the hidden weaknesses—the “Achilles’ heel”—of AI-evolved system programs. AIC HILLES treats the original humanwritten program P as a differential oracle for the AI-evolved program P ′ . Given a valid workload, AIC HILLES runs both programs and checks four regression types: correctness failures, execution time regressions, execution memory use regressions, and solution optimality regressions. AIC HILLES makes three design choices to make this search practical and efficient: • First, we observe that the AI-evolved programs and frameworks have implicit parameters and workload constraints hidden inside evaluators and the program itself. Strawman prompts or fuzzing approaches can miss these nuances. AIC HILLES therefore combines deterministic parameter extraction with agent-based constraint inference. The deterministic pass extracts candidate workload parameters from the evaluator, while the agent infers valid ranges and cross-parameter constraints. • Second, given the diversity of the weakness types, we find that a monolithic approach where a single agent tries to uncover all types of weaknesses can be ineffective. AIC HILLES splits the search by weakness type described above and assigns a separate subagent, which keeps the search focused and prevents it from collapsing. • Third, even with the subagent approach, we may waste time on finding workloads that trigger the same faulty code path(s). To find more diverse weaknesses under a fixed time budget, AIC HILLES uses code-frequency coverage as a behavior-diversity signal [29]. Our goal is not to pinpoint flaws in a specific research prototype but to uncover systemic weakness in the AI-driven system optimizations (ADSO) design paradigm. To this end, we evaluate AIC HILLES across 3 diverse AI-evolution frameworks (Engram [20], AdaEvolve [7], OpenEvolve [34]), 5 representative application use cases (transaction scheduling [8], expert-parallelism load balancing [13], multi-cloud job scheduling [38], LLM prefix-cache optimization [26], model placement [39]), and 2 frontier
LLMs (GPT-5, Claude-Opus-4.6). In total, this yields 30 AIevolved program settings. Across this spectrum, AIC HILLES finds 49 distinct weaknesses spanning four types. The most common failures are execution-time regressions, which appear in 25 program-app instances, followed by executionmemory regressions in 11 instances, correctness weaknesses in 7 instances, and optimality regressions in 6 instances. These results show that hidden weaknesses are not confined to one application, model, or framework. No evaluated AIevolved program family is uniformly robust under the adversarial workload search. In our experiments, Engram [20] programs expose fewer weaknesses than AdaEvolve [7] and OpenEvolve [34]-produced programs. We also compare AIC HILLES with other testing alternatives (e.g., random fuzzing [27], mutational fuzzing [14], property-based testing [12], and a baseline LLM agent). Under the same time budget, AIC HILLES consistently finds more diverse weaknesses than these baselines. In addition to serving as a detection tool, we also show that AIC HILLES can serve as an effective mitigation tool. We find that prompt engineering alone does not prevent AI evolution from producing risky programs. However, when we add AIC HILLES ’s feedback to the AI-evolution loop and penalize candidates that expose weaknesses, the final selected programs avoid the hidden weaknesses. This robustness, however, comes at a cost: as the claimed benchmarkscore improvements shrink, and in some cases the best robust program reverts closer to the human baseline. Disclosure and Ethics. We disclosed the weaknesses found by AIC HILLES and the mitigation to the authors of AdaEvolve [7] and Engram [20]. The authors acknowledged that when an evaluator rewards only benchmark score, stronger AI evolution may exploit that objective more aggressively and reveal gaps in the evaluator. In some sense, our work serves as a cautionary tale that should temper the exuberance around ADSO. While ADSO is indeed promising, we should set realistic expectations before such solutions are ready for prime time. This paper makes the following contributions: • We identify hidden regressions as security risks in AIdriven system optimization, where AI-evolved programs improve evaluator scores but may lose robustness on unseen adversarial workloads. • We propose a weakness taxonomy for comparing AIevolved programs against the original program, covering hidden weaknesses w.r.t optimality, resource use, and system crashes. • We design AIC HILLES , an agentic weakness-finding workflow that finds more weaknesses than traditional testing approaches under the same time budget. • We evaluate AIC HILLES on 5 system applications, 3 AIevolution frameworks, and 2 LLMs, finding 49 distinct weaknesses and presenting detailed case studies across weakness types. • We integrate AIC HILLES into the AI evolution loop and show it improves program robustness, though this reduces the original claimed improvement.
2
2. Background and Motivation
Original P : one greedy pass
We first introduce the background of AI-driven system optimizations (ADSO). Then we discuss anecdotal evidence using one AI-optimized program which motivates the need for an automated tool like AIC HILLES.
1 2 3 4
for model in sort_by_pressure(models): # One linear scan: choose GPU with lowest current KVPR. g = argmin_gpu(current_kvpr(g), feasible=True) place model on chosen_gpu
2.1. AI-Evolution for System Algorithms Engram evolved P ′ : repeated heuristic search
Efforts such as AlphaEvolve [30] and OpenEvolve [34] show that LLM-driven evolutionary search can discover improved algorithms and optimize critical computational infrastructure. In turn, this has inspired AI-driven system optimization as a promising paradigm for automating the design of core systems algorithms. Systems researchers and practitioners are increasingly exploring LLM-driven evolution to optimize algorithms for compute systems [7], [9], [10], [11], [18], [20], [25]. This has been applied across diverse tasks such as database optimization [11], transaction scheduling [8], expert-parallelism load balancing [13], multi-cloud job scheduling [38], LLM prefix-cache optimization [26], and KV-cache-aware model placement [39]. Traditionally, these systems relied on manually designed heuristics. The allure of ADSO is the reduced human effort and promise of more optimal solutions. At a high level, ADSO casts system algorithm design as an iterative optimization loop: an AI agent proposes candidate programs, an evaluator scores them on given system workloads, and high-scoring candidates are retained to guide later generations. Many ADSO frameworks have emerged. OpenEvolve [10], [34] uses a fixed, manually-tuned strategy that controls how aggressively programs are mutated, how many candidates are retained, and which variants to explore. AdaEvolve [7] replaces this fixed strategy with dynamic control tracking how much each direction improves over time, and reallocates resources toward the most productive directions, and injects higher-level algorithmic guidance when progress stalls. Engram [20] targets long-horizon evolution by splitting exploration across fresh agent contexts. It preserves progress through a persistent archive and compact research digest that carry code, results, insights, and failure diagnoses across runs. All of these frameworks report substantial gains. For example, AdaEvolve reports best scores 12–60% above human state-of-the-art programs on four systems tasks [7].
1 2 3 4 5
for rule in placement_rules: for order in ordering_strategies: # Risk 1: every candidate placement runs expensive local search. placement = greedy_place(models, order, rule) local_search(placement)
6 7 8 9 10 11
def greedy_place(models, order, rule): for model in sort_by(order, models): # Risk 2: choose by post-placement proxy, not the original current KV pressure (KVPR). g = argmin_gpu(proxy_kvpr_after(model, g), feasible =True) place model on chosen_gpu
12 13 14 15 16 17 18 19 20
def local_search(placement): for _ in range(25): for g1, g2 in all_gpu_pairs(): for m1, m2 in candidate_swaps(g1, g2): # Risk 3: many swap candidates repeatedly # recompute max KVPR. if max_kvpr_after_swap(placement, m1, m2) < max_kvpr(placement): swap(m1, m2)
Figure 2: Engram improves Prism with a more complex algorithm, but adds regression risks under new workloads. memory. When many models share a GPU cluster, the serving system must decide where to place each model so that request load and KV-cache pressure are balanced. Prism defines a balancing score called KVPR as a proxy for avoiding the most overloaded GPU. Specifically, it computes each GPU’s KV-cache pressure as the total request pressure of its assigned models divided by its remaining KV-cache memory, then scores a placement by the inverse of the average worst-GPU pressure across test cases. Thus, a higher score means that the placement leaves less pressure concentrated on the most constrained GPU, which should make the serving system less likely to hit a KV-cache bottleneck and miss latency targets. The human-designed Prism policy uses a simple greedy rule for model placement (45 lines of code). As a case study, we consider the optimized versions output by OpenEvolve and Engram, using Claude Opus4.6 [2]. Both use the same KVPR score defined by the PRISM paper in their evaluator function. OpenEvolve [10] evolves a slightly larger greedy variant that ranks models by pressure weighted by model size, and places each model using a penalized post-placement KVPR score (66 lines of code). Engram [20] discovers a much more elaborate searchbased policy that achieves a higher score on Prism’s original benchmark workloads (456 lines of code). Figure 2 and Figure 3 show the compact logic of all 3 programs.
2.2. Motivating Case Study The aforementioned tasks are often on the critical path of production systems and impact how production systems allocate resources, schedule work, route traffic, and serve models. Hence our interest in understanding potential weaknesses of such AI-evolved programs that can impact security, performance, and robustness. Driven by this concern, we initially manually inspected the effects of ADSO applied to Prism [39], which tackles cache-aware model placement for LLM serving systems that rely on Key-Value (KV) caches to avoid recomputing attention over previously generated tokens [21]. KV caches improve inference efficiency, but they also consume GPU
3
Execution time (s)
1 2 3 4 5 6 7 8 9
10 11 12 13 14
for model in sort_by((r / slo) * size): # Risk 1: Small but high-pressure models may be delayed because size is multiplied in. for gpu in all_gpus: future_kvpr = kvpr_after_placing(model, gpu) # Risk 2: scans all GPUs for every candidate. # The placement becomes O(M*G^2), not O(M*G). max_other = max(kvpr(g), for g in all_gpus if g != gpu) # Risk 3: A GPU that minimizes final max KVPR can be rejected because the penalty makes its local future_kvpr look worse. score = future_kvpr * ( 1.0 + 0.1 * max(0, future_kvpr - max_other) ) choose gpu with smallest score place model on chosen_gpu
101 P (initial) P' Engram P' OpenEvolve
100 10 1
Balance score
102
OpenEvolve evolved P ′ : balance-penalized future placement
P (initial) P' Engram P' OpenEvolve
0.8 0.7 0.6
10 2 10
20
#GPUs
30
10
20
#GPUs
30
(a) P ′ shows worse and grow- (b) P ′ shows worse perforing execution-time than P . mance than P under some #GPUs.
Figure 4: AI-evolved system programs expose different types of regression weaknesses when workload changes.
Figure 3: OpenEvolve uses a shorter greedy algorithm for Prism, but it overfits to the benchmark workloads.
In particular, the Engram generated program expands the search space by trying many alternative placements, but each step is still driven by a local acceptance rule. A move or swap is kept only if it immediately improves Engram’s internal pressure estimate. This can trap the search in a locally attractive placement: one that looks better after a single move, but blocks a better final assignment. Similarly, the OpenEvolve generated program improves the benchmark score because its “proxy” captures patterns that are specific to the benchmark workloads, such as prioritizing large high-pressure models and avoiding GPUs whose estimated pressure would rise sharply after placement. However, these add (possibly incorrect) assumptions that are not part of the original objective; e.g., model size should directly affect placement priority, and that a GPU with high projected pressure should be avoided even when using it temporarily could lead to a better overall placement. On workloads with many small high-pressure models, or workloads where a good solution requires temporarily using a pressured GPU, this proxy can misrank candidate GPUs and produce worse worst-GPU pressure than the original greedy policy.
At first glance, both evolved programs appear promising as they replace a compact hand-written heuristic with sophisticated implementations. However, these come with hidden weaknesses as we will see next. Runtime regression. The original program P uses a simple greedy policy as shown. Thus, each model placement requires only one scan over the GPUs, giving O(M G) time for M models and G GPUs. The Engram generated program replaces this one-pass rule with repeated heuristic search. It tries many model orders and placement rules, then runs local repair after each candidate placement. The repair step tests whether moving or swapping models between GPUs would improve the placement, and each trial recomputes GPU pressure. While using Engram can improve the benchmark score, its runtime grows much faster as the number of GPUs and feasible moves increases. The OpenEvolve generated program keeps a greedy structure but makes each GPU selection more expensive. For every candidate GPU, it computes the model’s pressure after placement, then scans all other GPUs to compute a balance penalty. This adds an O(G) inner scan inside the original O(G) GPU-selection loop, increasing placement time from O(M G) to O(M G2 ). Such a runtime regression can be serious when this placement algorithm is part of an online controller. In a shared serving cluster, placements may need to be recomputed when request rates shift, new models are added, models are removed, or GPU memory availability changes. In these settings, the scheduler must produce a new placement quickly enough for the cluster to react to the new load. A policy that improves the pressure score but takes much longer to run can delay reconfiguration and leave the system operating with a stale placement while demand has already changed. (Figure 4a confirms the weaknesses.)
Summary. Our manual analysis suggests that the AIevolved program is not always better than the original human designed program. AI can replace a simple algorithm with a more complex procedure that: (1) “reward hacks” on a small set of benchmark workloads and (b) ignores scalability concerns. In this sense, the original human program may be less aggressive but is actually more robust in the face of uncertainty: it sacrifices some optimality to maintain a stable solution.
3. System Overview Our manual analysis provides anecdotal evidence of hidden weaknesses in ADSO. However, given the diversity of ADSO usage, we need new tools to automatically find such hidden weaknesses across diverse AI-evolved system programs. We envision that such a tool becomes an indispensable part of the future CI/CD tooling for ADSO.
Optimality regression. We were also concerned with the risk of overfitting; i.e., the AI-evolved programs achieve higher scores on the benchmark workloads, but can become worse on new benchmark distributions. Figure 4b confirms this regression.
4
Weakness Type
are effective at uncovering specific classes of weaknesses (e.g., crashes and performance degradation), but they typically require substantial manual effort to construct the execution environment and testing harness for each target [4], [17]. This per-program effort does not scale to the diversity of AI-evolved programs we target: our evaluation alone spans 3 AI-evolving frameworks, 2 models, and 6 applications, yielding 30 distinct programs, each with its own input format and execution setup. AIC HILLES therefore adopts an agentic approach, using an LLM agent to automate the setup and search that traditional techniques leave to human experts. However, naively directing an LLM agent to identify weaknesses in AI-evolved algorithms fails to meet the requirements outlined above. The workload search space is vast and often subject to complex, application-specific constraints; an unguided agent may waste its budget generating invalid workloads that violate these constraints (see §4.1). Moreover, a single monolithic agent tends to follow the path of least resistance: once it discovers a crash-inducing workload, it gravitates toward minor variations of the same crash, leaving scalability and optimality regressions largely unexplored (see §5.1). To address these issues, AIC HILLES makes the following design choices: C1: Semantic-aware workload space inference. AIC HILLES adopts a two-step approach to enforce a comprehensive and semantic aware workload exploration. First, AIC HILLES parses the evaluator and workload generator to extract all variables that are related to the application workload. Second, AIC HILLES explicitly prompts the agent to infer the constraints among these parameters and turns them into a workload grammar. The parser pass makes parameter discovery deterministic, while the agent supplies the semantic reasoning needed to recover application-specific validity rules. C2: Weakness type-specific search agents. AIC HILLES splits the search by weakness type. Each sub-agent is given one target—correctness, scalability-time, scalabilitymemory, or optimality—and mutates workloads to increase evidence for that target. The candidate workload is then executed on both the original program P and the AIevolved program P ′ , and the result is checked against the corresponding weakness condition. This separation keeps the search focused while keeping validation grounded in program behavior rather than the agent’s own judgment. C3: Divergence-guided optimization. AIC HILLES guides the search by the divergence between P and P ′ . For each valid workload x, AIC HILLES compares the two executions under the target weakness metric and prioritizes workloads where P ′ behaves worse than P . For scalability, this means larger time or memory growth in P ′ . For optimality, it means a lower score from P ′ . For correctness, it means P ′ fails on a workload that P handles. C4: Execution trajectory as a proxy for workload diversity. AIC HILLES uses execution trajectory as a proxy for behavioral diversity. For each workload, it records how
Weakness condition ′
C ORRECTNESS
∃w ∈ W : P (w) → ⊥ ∧ P (w) ̸→ ⊥
S CALAB TIME
∃w ∈ W : t′ > Ft · t
S CALAB MEM
∃w ∈ W : m′ > Fm · m
O PTIMALITY
∃w ∈ W : q ′ < q
TABLE 1: Weakness taxonomy and conditions.
3.1. Problem Definition As shown in Figure 1, the ADSO workflow takes a human-designed candidate program P , a set of workloads W , and an evaluator as input. It produces an AI-evolved program P ′ such that, for every workload w ∈ W , P ′ (w) outperforms P according to the evaluator. Given a workload w, we run both programs and compare their behavior. On a workload w ∈ W , an execution returns either a metric tuple or an abnormal outcome: P (w) → ⟨q, t, m⟩ | ⊥ P ′ (w) → ⟨q ′ , t′ , m′ ⟩ | ⊥
where q is solution quality, t is wall-clock execution time, m is peak memory usage, and ⊥ denotes abnormal termination. Weakness definition. We define a hidden weakness in terms of a divergence violation between these two programs. That is, there exist valid inputs on which P ′ behaves worse than P under a security- or system-relevant metric. We focus on four types of weaknesses in this work. Table 1 summarizes the corresponding divergence checks. ′ • Correctness failure ⊥. P fails to execute successfully on a workload where P succeeds, e.g., by raising an exception, or returning an invalid result. ′ • Scalability-Time t. P has a time-scalability weakness if, on the same workload, its execution time is at least a user-defined factor Ft larger than P . ′ • Scalability-Memory m. P has a memory-scalability weakness if, on the same workload, its peak memory use is at least a user-defined factor Fm larger than P . • Optimality regression q . Quality checking function returns a lower score for P ′ than for P . Requirements. Detecting the weaknesses above imposes four design requirements. First, we want a general design that can work with heterogeneous target programs that differ in how they consume inputs. Second, it must have high coverage across weakness types and expose many diverse weakness types in Table 1, not only crashes or only performance regressions. Third, the discovered weaknesses must be discriminative: an adversarial workload should reveal a significant gap between P and P ′ , rather than being uniformly hard for both programs. Fourth, we want diversity to uncover as many distinct weaknesses as possible, instead of repeatedly triggering the same failure mode.
3.2. Design Choices Traditional bug-finding techniques such as fuzzing [14], [15], [22], [23], [32], [40] and symbolic execution [5], [6]
5
1 Workload Space Inference
Parameter Extraction + Agent Infer
2 Divergence-guided Search Agents W sampler
3 Weakness Dedup & Analysis Exec. trace V
Correctness Time
Append v
Deduplication by V
MAP-Elites exploration until budget
Root Cause Analysis Agent
Run P’ on workload
Weakness
Memory Optimality Program Evaluator, P, P’ Workload example
Evolving knowledge for future P’
Warm-start workloads (if exists)
Run P, P’ on workload
Trial count
Figure 5: AIC HILLES Design Overview
15.0 12.5 10.0 7.5 5.0 2.5 0.0
3
2
3
space is not exposed as a clean input grammar. Workload knobs may appear in the application-specific program evaluator (that computes the program quality score), helper functions, or constants. And some validity rules are only implied by the program logic. For example, in Prism [39], model placement is constrained by GPU memory capacity. For workload parameters, an individual model must fit on one GPU, so model_size_max must be below the GPU memory limit. If the parameter search ignores these constraints, it may generate workloads that crash P ′ but are actually false positives. A strawman approach is to directly prompt an agent to extract workload parameters and constraints for each application. We find this unreliable: across runs, the agent may identify different parameters, depending on how it interprets the application semantics. Figure 6 shows this instability in Prism, where different Opus-4.6 [2] agent trials recover very different numbers of parameters. AIC HILLES therefore separates deterministic parameter extraction from semantic interpretation. It first parses the evaluator using Python AST and extracts concrete workloadrelated values, including module-level constants, function default arguments, and literal values passed into function calls. This step does not try to understand the full application. Its purpose is to produce a stable set of candidate parameters and example values for the agent to inspect. AIC HILLES then prompts an agent to infer the workload grammar from these candidates and the application source files. For applications such as transaction scheduling [8], the grammar can also include constraints from file metadata, such as valid column names in the workload file (see prompts in Appendix 1). The output of this stage is a workload sampler that generates workload parameters w. AIC HILLES validates the sampler by running generated workloads on the reference program P . If P fails on w, AIC HILLES uses the failure message to revise the sampler. We empirically find this validation process needs at most one revision to produce a valid workload sampler.
3
2
4
Trace V on Divergence workloads check No weakness
Figure 7: Divergence-guided weakness search.
true # of Prompt-only parameters Prompt+AST 10
2
Code execution frequency vector v
5
# workload parameters inferred Figure 6: Compared with AIC HILLES’s approach, Prompt-only agents produce inconsistent workloadparameter inference (example with Prism). often each line of P ′ executes and represents it as a vector. A candidate is prioritized when its trajectory differs from those already explored. This steers the search toward new program behavior rather than surface-level input changes, and it also helps group repeated witnesses during root-cause analysis.
4. Detailed Design At the core, AIC HILLES has three stages (Figure 5): First, AIC HILLES infers the workload space by combining deterministic parsing with an AI agent. The parser extracts workload parameters, and the agent infers applicationspecific constraints to form a valid workload grammar. • Second, AIC HILLES runs divergence-guided search with one agent per weakness type. Each agent searches for valid workloads where the AI-evolved program P ′ is worse than the original program P under its target metric. AIC HILLES uses the execution trajectory of P ′ as a proxy for behavioral diversity and prioritizes workloads that exercise different program behavior. • Third, AIC HILLES summarizes the discovered workloads into distinct weaknesses and uses an AI agent to explain their root causes. It also reuses previously found adversarial workloads as warm-start seeds when testing another evolved program for the same application. •
4.2. Divergence-guided Search per Weakness Type
4.1. Workload Inference
After obtaining a valid workload sampler, AIC HILLES searches for workloads where P ′ regresses relative to P . The first challenge is to cover different weakness types efficiently. A strawman approach is to use one monolithic
For each AI-evolved system application, AIC HILLES first discovers the workload space that the search is allowed to explore. In our targeted ADSO applications [16], this
6
Optimality Scal_Mem
3
3
3
2 1 0
1
nts gle Sin bAge Su
Prism
1
nts gle Sin bAge Su
TXN
(a) AIC HILLES’s sub agents find more diverse weakness types than a single agent.
Adversarial workloads Distinct root causes
120
102
100
4 3
3 74
80
2
60 40 20 0
1
1
20
Workload Path Execution Distance Coverage Frequency
1
Distinct root causes
Correctness Scal_Time
Adversarial workloads
# weakness types covered
agent to search for all possible weaknesses. However, we find this unreliable. For instance, once an agent finds a crash-inducing workload, it tends to propose nearby crashinducing cases and misses scalability or optimality weaknesses. This behavior is consistent with prior evidence that LLMs can struggle to use long prompts effectively [24]. AIC HILLES therefore uses one sub-agent per weakness type. Each sub-agent is prompted with the corresponding divergence definition in Table 1, so it focuses on workloads likely to expose that specific regression. This design keeps the search targeted: correctness agents look for failures of P ′ that do not occur in P , scalability agents look for time or memory gaps, and optimality agents look for quality score regressions. Figure 8a shows that a single agent only finds one weakness type, while AIC HILLES’s type-specific agents cover three weakness types on both Prism and TXN. The second challenge is finding diverse instances within each weakness type. A seemingly natural but incorrect choice to measure diversity is to consider some distance metric over the input workload; e.g., Euclidean distance between workload-parameter vectors. However, this is misleading in our setting. Two workloads can be far apart in parameter space but still execute the same code path and trigger the same root cause. Conversely, two nearby workloads may reach different branches and expose different failures. This wastes the testing budget and can overstate the number of distinct weaknesses. We need a diversity metric that reflects program behavior, not just input variation. To this end, AIC HILLES uses the execution trajectory of P ′ as a proxy for workload diversity. For each workload, AIC HILLES records which parts of P ′ execute and tracks their execution frequencies using a fixed-size counter map. This captures not only whether a workload reaches a code region, but also how heavily it exercises loops, branches, and helper functions. Other fuzzing approaches also use path coverage as a diversity signal [37]. Figure 8b compares three choices: workload distance, path coverage, and execution frequency. We find that execution frequency exposes the largest number of distinct weaknesses, because many AI-evolved system program regressions are not caused by reaching a new branch alone. They often come from repeatedly exercising the same logic under different load conditions, such as deeper search, larger intermediate structures, or repeated placement updates. The execution frequency therefore provides a finer signal than path coverage while staying closer to root-cause behavior than raw workload distance. Combining these two key ideas, Algorithm 1 shows how AIC HILLES searches for adversarial workloads. For each weakness type τ ∈ T and given application, AIC HILLES starts from workloads sampled from the grammar and previously identified workloads. A type-specific agent mutates a seed workload into new candidates. AIC HILLES runs each candidate on P ′ to record its behavior and execution trajectory, skips candidates that repeat explored behavior, and then runs the remaining candidates on P . If P ′ is worse than P under the target weakness condition, the workload is added to Wτ .
0
(b) Code execution frequency is a better diversity proxy than alternatives.
Figure 8: Design choices for workload search. Algorithm 1 Divergence-guided Workload Search Require: Initial program P , evolved program P ′ , workload grammar G, weakness types T = {c, t, m, q}, search budget B Ensure: Adversarial workload sets {Wτ }τ ∈T 1: Initialize global archive A, abnormal-workload set C , and adversarial workload sets {Wτ } 2: Set per-type budget Bτ ← ⌊B/|T |⌋ 3: for all τ ∈ T do 4: Aτ ← WARM S TART(G, τ ) 5: while Bτ > 0 do 6: w ← S AMPLE S EED(Aτ ) 7: S ← AGENT M UTATE(w, G, τ, C) 8: for all ŵ ∈ S do 9: (q ′ , t′ , m′ , v ′ ) ← RUN W ITH T RAJECTORY(P ′ , ŵ); Bτ ← Bτ − 1 10: if S KIP(ŵ, v ′ , A, C, τ ) then 11: continue 12: end if 13: (q, t, m) ← RUN(P, ŵ) 14: (W, ∆) ← C HECK W EAKNESSES(q, t, m, q ′ , t′ , m′ , ŵ, v ′ ) 15: M AP E LITES U PDATE(Aτ , ŵ, v ′ , ∆[τ ]) 16: M AP E LITES U PDATE(A, ŵ, v ′ , maxη∈T ∆[η]) 17: end for 18: end while 19: end for 20: return {Wτ }τ ∈T
AIC HILLES uses MAP-Elites [28] to keep the search robust and diverse. MAP-Elites is a standard Quality-Diversity optimization algorithm: it divides explored behavior into coarse cells, and each cell keeps the best candidate found for that behavior. In AIC HILLES, the cell is computed from the execution trajectory of P ′ . Within each cell, AIC HILLES keeps the workload with the largest divergence score d. The per-type archive Aτ stores useful seeds for the current weakness type, while the global archive A tracks behavior explored across all weakness types (Algorithm 2). This prevents the search from only chasing one repeated failure and helps it keep workloads that expose different program behaviors.
7
Evolving knowledge across P ′ . After testing one evolved program P ′ , AIC HILLES stores useful search results for later evolved programs from the same application. The knowledge base contains three types of workloads: adversarial workloads that satisfy a weakness condition, highdivergence workloads that do not cross the weakness threshold, and summary statistics about which weakness types were observed. The first group captures regressions that may recur in another P ′ . The second group captures near misses: workloads that stress the current P ′ and may become adversarial for a different evolved implementation. When AIC HILLES tests a new P ′ for the same application, it replays these stored workloads before starting the mutation loop. Each workload is re-evaluated against the new P ′ , so AIC HILLES does not assume that a previous weakness still exists. Even when a stored workload no longer satisfies a weakness condition, its execution trajectory can still seed the MAP-Elites archive with useful program behavior. Figure 9 shows that this warm start helps AIC HILLES discover distinct weaknesses faster and begin the search from a more diverse set of behaviors.
Algorithm 2 MAP-Elites Updating Search
# distinct weaknesses
Require: Archive A, workload w, execution trajectory v , divergence score d Ensure: Updated archive A 1: c ← C ELL(v) ▷ Map execution behavior to an archive 2: if c ∈ / A then 3: A[c] ← (w, v, d, 0) ▷ Store first workload 4: else if d > A[c].d then 5: A[c] ← (w, v, d, A[c].visits) ▷ Keep the strongest regression in this cell 6: end if 7: return A Opus/Ada (cold) GPT/Ada (cold)
GPT/Ada (warm-start from Opus/Ada)
0
20
4 3 2 1 0
5. Evaluation 10
30
40
We study three questions to evaluate AIC HILLES. RQ1: Can AIC HILLES find distinct weaknesses efficiently? Under the same budget, we compare AIC HILLES with existing program testing approaches and measure if it finds more distinct weaknesses. (§5.1) • RQ2: What hidden weaknesses does AIC HILLES find in AI-evolved programs? We measure how many weaknesses AIC HILLES finds, their root causes, and what risks they imply for applying AI-evolved programs in practical systems with case studies. (§5.2, §5.3) • RQ3: If we include AIC HILLES in the evaluation loop, can it mitigate the weaknesses? We test whether prompt engineering and evaluator patching, when added to the AI-evolution loop, prevent the evolved program from introducing hidden regressions. (§5.4)
Elapsed time (min) Figure 9: With warm-start, AIC HILLES finds weak-
•
nesses in GPT/AdaEvolve-generated Prism P ′ more efficiently.
4.3. Weakness Summarization After AIC HILLES finds adversarial workloads, human (or agentic) reviewers still need a concise report of distinct root causes. Execution-trajectory diversity reduces repetition during search, but it does not ensure unique root causes; e.g., two workloads may execute different line frequencies yet fail because of the same flawed function. AIC HILLES therefore deduplicates adversarial workloads by the execution behavior of P ′ . For each workload, it uses the collected code-frequency vector to find the lines that dominate the run, then maps those lines back to functions using AST source ranges. If a line belongs to nested functions, AIC HILLES assigns it to the innermost function, which best captures the local code responsible for the behavior. The function with the largest accumulated weight becomes the workload’s trigger function. AIC HILLES groups adversarial workloads that share the same trigger function and keeps the workload with the largest divergence score as the representative example. This gives each group a concrete workload and measured regression, while the group size shows how broadly the same root cause appears. Finally, AIC HILLES asks an agent to write a short rootcause explanation for each group. The prompt includes the representative workload, weakness type, divergence score, trigger function, relevant source lines in P ′ , and the corresponding behavior of P . The agent does not decide whether a weakness exists; it only explains why that region of P ′ causes the observed regression compared with P (see prompts in Appendix 2).
Setup. We evaluate AIC HILLES on 3 AI-evolving frameworks released by prior work: OpenEvolve [16](version de8086f), AdaEvolve [16](version de8086f), and Engram [20](version 5295858). We test each framework with two frontier LLMs: GPT-5 [31] and Claude Opus-4.6 [2]. We then select the highest-scoring program under the original evaluator – the same artifact that prior work cites as evidence of human-competitive performance. Applications. We evaluate 5 system applications collected from prior work [7], [16]. • Transaction scheduling (TXN-Sched) [8] optimizes the execution order of database transactions that read and write shared keys. It reduces lock conflicts and minimizes total makespan on transactional workloads. The evaluator checks whether an evolved scheduler can preserve conflict constraints while compressing completion time. • Expert parallelism load balancing (EPLB) [13] targets load imbalance in Mixture-of-Experts inference, where
8
Random
Correctness
Distinct weaknesses found (6 hr)
3
Mutational
Property-Based
Scalability_Time
9 8 7 6 5 4 3 2 1 0
12 10
2
8 6
1
4 2
0
ast
udc
Clo
LB QL EP LM-S L
sm ched Pri N-S TX
0
ast udc
Clo
LB -SQL LLM
EP
sm ched Pri N-S TX
AIChilles
Optimality
6 5 4 3 2 1
ast
udc
Clo
Naive-Agent
Scalability_Memory
LB -SQL LLM
EP
sm ched Pri N-S TX
0
ast
udc
Clo
LB -SQL LLM
EP
sm ched Pri N-S TX
Figure 10: Compared with baselines, AIC HILLES finds more distinct weaknesses within a 6-hour budget. Metric. For each generated workload w, we run it on both the initial program P and the AI-evolved program P ′ . A workload is adversarial if it exposes one or more of the target conditions: correctness, scalability_time, scalability_memory, or optimality. We measure how many distinct weaknesses a method finds under a fixed time budget T . A distinct weakness is defined as a group of adversarial workloads that satisfy a weakness condition and share the same trigger function in P ′ , which serves as a proxy for the same root cause.
popular experts can overload a subset of GPUs. The algorithm must decide how many replicas each expert should have and how to place them across GPUs. The evaluator measures load-balance quality and the runtime cost of rebalancing. • Multi-cloud job scheduling (Cloudcast) [38] studies costaware data transfer across multi-region and cloud. The evaluator validates complete, valid delivery paths for all destinations and partitions across cloud configurations, then scores the algorithm by inverse total transfer cost. • LLM prefix-cache optimization (LLM-SQL) [26] optimizes relational analytics workloads where each table row is serialized into an LLM prompt. The algorithm reorders rows and fields to increase shared prefixes between consecutive prompts. The evaluator rewards high prefix-cache hit rate while keeping the reordering algorithm itself efficient. • Model placement (Prism) [39] places multiple LLMs onto a fixed GPU cluster under heterogeneous and bursty serving demand. The evaluator checks the model placement under GPU memory constraints, then scores placements by low average KV-cache pressure and success rate.
5.1. Effectiveness and Diversity To compare weakness-finding efficiency, we measure the number of distinct weaknesses found within a sixhour budget. Each method is run five times with different random seeds, and we report the average. For fairness, all baselines use the same workload parameters recovered by AIC HILLES’s workload-space inference stage; the comparison therefore focuses on search effectiveness rather than differences in parameter discovery. We aggregate results of 6 AI-evolved programs on each application. Figure 10 shows that AIC HILLES finds more distinct weaknesses than all baselines across all four weakness types. The gap is smallest for correctness weaknesses, where simple mutations and naive LLM agents can sometimes find crashes. However, after finding one crash pattern, these methods often keep generating similar crash workloads and miss other weakness types. The gap becomes much larger for regressions that require comparing P ′ against P . For scalability-time, AIC HILLES finds up to 12 distinct weaknesses in TXN, while no baseline finds more than 3 across all applications. For optimality, none of the baselines finds a distinct weakness. The optimality cases are harder because the failure often depends on a specific combination of workload parameters. Changing one parameter alone may not make the program quality regression worse, and combining two promising changes may even hide the regression. This makes simple random mutation or naive-agent search less effective. We also compare the cost of each weakness-finding method in Table 2. Using Prism as an example, traditional baselines consume nearly the full six-hour budget on one CPU core, with roughly 95–100% CPU utilization. Agentbased methods use fewer local CPU-hours but add LLM token cost. AIC HILLES uses more local CPU than the
Baselines. We compare AIC HILLES with four practical alternatives for testing Python programs. Random Fuzzing [27] uniformly samples independent workload parameters from their ranges at each trial, with no memory of prior results. • Mutational Fuzzing [14] starts from uniformly sampled workloads and keeps a corpus of promising cases. At each step, it mutates the workload with the largest performance gap: numeric parameters are changed by up to 20% within their valid ranges, and categorical parameters are resampled with 30% probability. The resulting workloads are ranked by performance gap for future mutation. • Property-Based Testing [12] uses the Hypothesis library [19] to automatically generate and shrink workloads. For each workload parameter, we specify the valid values that Hypothesis may sample. The fuzzer then searches for workloads that violate the property “the AI-evolved program is never outperformed by the initial program.” • Naive-agent puts everything in the prompt as a single weakness finding agent (see prompts in Appendix 3). It uses the same condition to confirm weaknesses but does not include AIC HILLES’s specific design choices. •
9
Random Mutational Property Naive-agent AIC HILLES
CPU (hours) 5.8 6.0 6.7 1.2 2.4
Token ($)
TXN-Sched 1 EPLB 2 Cloudcast 0 LLM-SQL 0 Prism 0
10.24 8.95
0 0 0 0 0
0 0 1 1 0
0 0 0 1 0
0 0 0 0 0
0 0 0 0 1
2 0 2 0 1
Scal_Time
1 0 0 1 1
1 1 0 0 1
5 0 0 1 2
2 0 0 0 1
1 1 1 0 0
Op
-Ad Op a -O Op p G5 En -Ad G5 a -O G5 p -En Op -Ad Op a -O Op p G5 En -Ad G5 a -O G5 p -En
TABLE 2: Search cost on Prism, with token cost computed using Opus-4.6 pricing [2]. naive-agent baseline because it runs divergence checks and tracks execution trajectories during search. However, it uses fewer tokens since each sub-agent focuses on one weakness type, and the execution-frequency signal guides workload selection, instead of relying on the agent to reason about all four weakness types at every iteration. Although all methods are given a six-hour budget, we find that AIC HILLES often reaches its final set of distinct weaknesses earlier. On Prism, EPLB, and Cloudcast, AIC HILLES converges to the reported distinct weaknesses within 20–30 minutes.
Correctness
Scal_Mem
1 0 0 0 0
0 0 0 0 0
4 0 0 0 1
2 0 0 0 0
0 0 0 0 0
0 1 0 0 1
Optimality 0 0 0 0 1
0 0 0 0 1
0 0 0 0 1
0 0 0 0 1
0 0 0 0 0
4 3 2 1 0
Op
-Ad Op a -O Op p G5 En -Ad G5 a -O G5 p -En Op -Ad Op a -O Op p G5 En -Ad G5 a -O G5 p -En
TXN-Sched 1 EPLB 1 Cloudcast 0 LLM-SQL 0 Prism 1
5
Weakness count
Method
Figure 11: Weaknesses found across 5 applications, 3 AI frameworks, and 2 LLMs.
Takeaway 1: AIC HILLES finds 49 distinct weaknesses spanning all four types. The bottleneck of finding hidden weaknesses is not generating more workloads, but generating workloads that expose how P ′ behaves differently from P . Baselines can find program crashes, but they struggle with scalability and optimality regressions because these failures depend on specific workload interactions. AIC HILLES acts more like a human auditor, it searches for divergence directly and prioritizes workloads that exercise new behavior in P ′ .
weaknesses, but neither exposes scalability-memory or optimality weaknesses. AdaEvolve produces all four types of weaknesses. We find that in the TXN-S CHED cases, AdaEvolve introduces heavier optimization procedures that rewrite the whole program logic, which creates more opportunities for algorithmic blowups. Engram generated program stays closer to the original human-designed program implementation, with less aggressive rewrites. (Table 5) Model-level patterns. The LLM model also matters, but its effect depends more on the AI-evolving framework. Under Engram, Claude and GPT have similar weakness profiles. Under AdaEvolve, the model difference is larger. For example, Opus/AdaEvolve on EPLB exposes correctness, memory, and optimality weaknesses in the same application, while GPT/AdaEvolve exposes none there. On TXNS CHED, GPT/AdaEvolve is the worst case, with both the largest time and the largest memory weakness count. This suggests that model choice is not an independent factor. The AI-evolving framework controls how much room the model can rewrite the program structure, while the model affects which concrete strategy is produced inside that program.
5.2. Weakness Pattern Analysis Next we dive deeper to analyze patterns in the uncovered weaknesses. Figure 11 shows details of distinct weaknesses found from AIC HILLES on each application and each AIevolved program. Application-level patterns. We see that different target applications expose different kinds of weaknesses. TXNS CHED is the clearest scalability case. In this application, GPT/AdaEvolve alone produces five scalability-time weaknesses and four scalability-memory weaknesses. In P RISM, all six evolved programs contain at least one weakness. It is also where optimality regressions are most concentrated. This is interesting because Prism programs can remain executable while making worse placement decisions. A bad model-placement strategy may not crash or immediately exhaust memory, but it can still produce a lower placement score by increasing KV-cache pressure. Thus, Prism exposes weaknesses that are silent quality regressions rather than obvious failures. Among all applications, C LOUDCAST and EPLB have fewer distinct weaknesses, and their failures are concentrated in fewer framework/model combinations. AI framework-level patterns. The AI-evolving framework affects not only how many weaknesses appear, but also what kind of weakness appears. Engram-generated programs have a narrower profile in our results: Claude/Engram and GPT/Engram both expose correctness and scalability-time
Takeaway 2: Weaknesses in AI-evolved programs depend on both the application and the evolution framework. For example, Prism exposes silent quality regressions, while TXN-Sched exposes resource blowups. Different frameworks, such as Engram and AdaEvolve, also produce different weakness profiles. Auditing should therefore account for the kinds of transformations each AI-evolving framework tends to encourage.
5.3. Case Studies To help shed light on the structure of the weaknesses, next we present more in-depth case studies.
10
2 3 4 5
for i in range(num_log, num_phy): redundant_indices = (weight / logcnt).max(dim=-1). indices phy2log[:, i] = redundant_indices rank[:, i] = logcnt[arangen, redundant_indices] logcnt[arangen, redundant_indices] += 1
Opus/AdaEvolve evolved: batched top-k update
1.0 0.9 0.8 0.7 0.6 P (baseline) P' (evolved)
0.5 1 4
1 2 3 4 5 6 7 8 9 10 11
14 15 16 17 18
32
0.9 0.8 0.7 0.6 P (baseline) P' (evolved)
0.5 32
64
128
256
Number of experts
(a) Score w. increasing layers (b) Score w. increasing experts
Figure 13: On new workloads in EPLB, Opus/AdaEvolve generated P ′ shows worse balancing score than P . load distribution changes after each assignment (lines 6– 13). The next best expert may no longer be the one selected in the fixed topk list. Conversely, an expert with much higher load than the others may need several consecutive replicas, but the fixed list can assign too few. The program returns a valid expert mapping, but the mapping can balance load worse than the initial program. Figure 13 shows this becomes worse as the number of experts and layers grows. With more experts, small differences in replica choice matter more because there are more near-ties and more high-load experts. With more layers, the same batching error can repeat across layers and accumulate in the final score. In practice, this can under-replicate heavily loaded experts and over-replicate moderately loaded ones, creating more load imbalance than the original heuristic.
12 13
16
Number of layers
batch_size = 20 for batch_start in range(phase2_end, num_phy, batch_size): batch_end = min(batch_start + batch_size, num_phy) batch_len = batch_end - batch_start normalized_load = weight / logcnt.float() if batch_len == 1: redundant_indices = normalized_load.max(dim=-1) .indices.unsqueeze(-1) else: #Risk: if batch_len > num_log, this returns only num_log columns. _, redundant_indices = normalized_load.topk(min (batch_len, num_log), dim=-1) redundant_indices = redundant_indices[:, : batch_len]
Balancedness score (GPU)
1
Balancedness score (GPU)
Original: safe one-replica-at-a-time update
for j in range(batch_len): #Risk: j may exceed redundant_indices.shape expert_idx = redundant_indices[:, j] phy2log[:, batch_start + j] = expert_idx rank[:, batch_start + j] = logcnt[arangen, expert_idx] logcnt[arangen, expert_idx] += 1
Figure 12: EPLB correctness weakness Correctness weaknesses in EPLB. EPLB balances mixture-of-experts serving by deciding how many physical replicas each logical expert should receive. Intuitively, a heavily loaded expert should be copied more times, so that its traffic can be split across more physical experts. Figure 12 shows the initial program using a one-step greedy loop: before assigning each new replica, it recomputes the current load per replica, chooses the most overloaded logical expert, assigns one physical replica, and updates that expert’s replica count. The AdaEvolve program keeps the same goal but batches the assignments. In each batch, it computes normalized load once, selects a fixed topk list of highload experts, and then fills several replica slots from that list. The crash happens because the evolved program implicitly assumes the batch size is not larger than the number of experts returned by topk. This fails when the workload has few logical experts but many physical replicas. For example, with 8 logical experts and 288 physical replicas, the final phase uses batch size 20, but topk(min(batch_len, num_log)) returns only 8 experts. The loop still iterates over 20 slots, indexes past the candidate tensor and crashes. Note that this is a correctness failure on a valid EPLB workload. The original human-designed program avoids it because it assigns one replica at a time.
Scalability weaknesses in TXN. TXN scheduling chooses an execution order for transactions. Each transaction reads or writes shared resources, so a poor order can create more lock conflicts and a longer makespan. Figure 14 shows the initial program using a bounded greedy sampler: at each schedule position, it samples a small fixed set of remaining transactions, estimates the cost of adding each one, and commits the best candidate. The AI-evolved program uses a much larger search procedure. It builds cost tables, scores transaction orderings, generates multiple seeds, refines schedules, runs beam search and bounded A* search, applies largeneighborhood search, and tries hierarchical scheduling. This helps on small workloads, but it also turns a bounded greedy policy into a multi-stage search over many possible transaction orders. The scalability problem comes from repeatedly analyzing many partial schedules. The AdaEvolve generated program caches explored prefixes as tuple(seq), keeps competing prefixes in a priority queue, and copies schedules during each expansion. Its local-refinement loop can also run for many attempts because insert_trials limits only consecutive failures. As a result, execution time and memory grow with the number of explored prefixes unlike the original program that only keeps one partial schedule and a fixed sampling budget.
Optimality weaknesses in EPLB. The same program also has a optimality weakness. The step-by-step replica assignment with a batched shortcut is error-prone because the
Scalability weakness impact. In production systems, such scalability weaknesses can turn the scheduler itself into a bottleneck. A scheduler that spends seconds searching
11
Cloudcast ↓
Original: one active prefix, bounded sampling per position 1 2 3 4 5 6 7 8 9 10 11 12 13
for i in range(0, workload.num_txns - 1): ... for j in range(0, num_samples): ... test_seq = txn_seq.copy() test_seq.append(t) cost = workload.get_opt_seq_cost(test_seq) if cost < min_cost: min_cost = cost min_txn = t if done: break txn_seq.append(min_txn)
GPT/AdaEvolve evolved: unbounded search on partial schedules 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
#(1)Memory risk: cache every explored partial schedule. eval_cache = {} def eval_cost(seq): k = tuple(seq) ... eval_cache[k] = workload.get_opt_seq_cost(seq) #(2)Time & memory risk: A* branches over many prefixes. while pq and expanded < max_nodes: ... ranked = sorted(rem, key=lambda j: h_cost(seq, rem, j, 0.35)) for t in ranked[:top_k]: ns = seq + [t] nr = [x for x in rem if x != t] g2 = eval_cost(ns) heapq.heappush(pq, (..., tie_score(ns, nr), ..., ns, nr, g2)) #(3)Time risk: trial budget restarts after each improvement. while tries < insert_trials: ... if c < best_c: ... improved_here = True break tries = 0 if improved_here else tries + 1
Original(P )
AI-evolved(P ′ )
Symbol Legend
TXN EPLB
O(N ) O(LEB)
O(N 2 ) O(LEB + LR)
N : # transactions L: # layers; E : # logical experts; R: # physical experts; B : max replicas
Prism
O(M + G)
O(M G)
Prism
LLM-SQL
TXN
0.126
21.89
0.692
2,725
AdaEvolve (reproduced) Score 627.1
0.141
26.25
0.730
4,081
AdaEvolve+Prompt fixing Score 627.1 Correctness ✗ Scal_Time ✓ Scal_Mem ✓ Optimality ✓
0.137 ✓ ✗ ✓ ✓
24.22 ✓ ✗ ✓ ✗
0.734 ✗ ✓ ✓ ✓
3,185 ✓ ✗ ✗ ✓
AdaEvolve+AIC HILLES Score 627.1 Correctness ✓ Scal_Time ✓ Scal_Mem ✓ Optimality ✓
0.153 ✓ ✓ ✓ ✓
21.89 ✓ ✓ ✓ ✓
0.712 ✓ ✓ ✓ ✓
2,832 ✓ ✓ ✓ ✓
TABLE 4: After mitigation attempt, scores of AI-evolved program and weakness-finding results for Opus/AdaEvolve. (✗ = weakness found, ✓ = no weakness found). tions using AdaEvolve (Opus-4.6) as P ′ in Table 3. A common pattern is that P ′ improves evaluator scores by storing more intermediate state: search prefixes in TXN, packing and device-transfer copies in EPLB, and a dense model–GPU cost matrix in Prism. These structures fit small evaluator workloads but grow quickly on larger valid inputs. Takeaway 3: AI-evolved program trades the lightweight greedy design of the baseline program for more global optimization logic. This can improve the benchmark objective, but it does not necessarily preserve robustness properties that are not encoded in the evaluator. Under adversarial workload shifts, the selected evolved programs may expose crashes, hidden peak-memory regressions, execution-time blowups, or lower solution quality than the human-designed baseline.
Figure 14: TXN-scheduling scalability weakness App
EPLB
Human baseline Score 626.2
5.4. Mitigation with AIC HILLES Based on the weaknesses found by AIC HILLES, we next test whether we can mitigate such weaknesses. We evaluate this in AdaEvolve with Opus-4.6. As a baseline we consider prompt-based patching. We modify the original evolution prompt to warn the model about the four weakness types studied in this paper: correctness, scalability-time, scalability-memory, and optimality regressions. The prompt asks the model to avoid changes that may introduce these failures. Appendix 4 gives the full prompt. This tests whether telling the model about the weaknesses is enough to prevent them. We also design a new strategy, AdaEvolve+AIC HILLES, using AIC HILLES as an explicit checking step inside the evolution loop. The original AdaEvolve loop ranks each candidate program only by its evaluator score. In this evolution loop, after each candidate P ′ is generated, we run AIC HILLES for 100 weakness-finding iterations to search for valid workloads where P ′ regresses against P . If AIC HILLES finds any adversarial workload, we assign
M : # models; G: # GPUs
TABLE 3: Big-O annotation of original program P vs. Opus/AdaEvolve evolved program P ′ . for a slightly better order can delay short transactions that should finish in milliseconds. Under high contention, the evolved scheduler may expand many similar prefixes before returning a schedule, increasing tail latency when the system is already under pressure. Its growing prefix cache and priority queue can also compete with the database engine for memory and risk garbage-collection pressure or out-ofmemory failures. Thus, an optimization meant to reduce lock conflicts can instead burn CPU and memory before transactions even begin executing. We also compare memory complexity across applica-
12
the candidate a penalty of −100 and return the workload and weakness type as feedback to the model. In effect, AIC HILLES is part of the CI/CD pipeline for ADSO: a candidate must not only improve the score, but also pass the weakness checks. Table 4 shows that prompt patching is not enough: the generated programs still contain all weakness types across applications. In contrast, with AIC HILLES integrated into AdaEvolve++, the final selected programs no longer expose weaknesses found by AIC HILLES. This robustness, however, reduces the AI-evolved benchmark gains. The original AdaEvolve improves the evaluator score by 19% on P RISM and 49% on TXN-S CHED. With AdaEvolve++, P RISM falls back to the human baseline, giving 0% improvement, and TXN-S CHED drops to 3.9%.
hotspots, and SPIDER [23] targets stateful performance bugs in ONOS via dependency-aware modular fuzzing. Grammarbased fuzzers instead preserve input structure: NAUTILUS [3] and Gramatron [36] guide grammar-level generation and mutation, FANDANGO [41] evolves grammar-valid inputs under semantic constraints, and GraphFuzz [17] mutates lifetime-aware dataflow graphs for library APIs. Unlike traditional greybox fuzzers, AIC HILLES targets AI-evolved system algorithms and searches valid workload spaces with differential oracles to expose regressions between the initial program P and evolved program P ′ .
7. Discussion and Limitations AI-evolved system programs may be harder to audit. Our results suggest that AI evolution can improve evaluator scores by replacing simple heuristics with much more complex code, sometimes an order of magnitude longer. This complexity adds hidden assumptions, intermediate state, and interactions between heuristics. Even when the KPI improves, developers may struggle to understand what its resource bounds are, or which workload changes can break it. For system algorithms, simplicity is often part of robustness: a less aggressive human-designed heuristic may preserve operational margins that the evaluator does not measure. Toward safer AI evolution. A safer evolution loop could treat each AI-generated change like a CI/CD patch: small, reviewable, and tested before it is accepted. Instead of rewriting a whole algorithm at once, the framework could limit each iteration to a local change, such as one condition or helper function, then run adversarial workloads to check correctness, resource use, and solution quality. This would trade exploration speed for auditability. Improvements may arrive more slowly, but they would be easier to explain, test, and roll back. Our mitigation experiment provides initial evidence for this direction. Imperfect root-cause analysis. AIC HILLES confirms weaknesses through program execution, but still uses an agent to explain root causes. These explanations are useful but not always consistent. The agent may only describe a nearby symptom instead of identify the actual root cause. Future work could strengthen this step with cross-checking, dynamic slicing, or delta debugging to better ground each root-cause report in execution evidence.
Takeaway 4: Adding AIC HILLES to the AI-evolution loop can filter out candidates with weaknesses, but it also has a tradeoff: once those candidates are penalized, the measured improvement often shrinks, and in some applications disappears. This suggests that to unlock the full potential of AI-evolved system, it requires strong and robust benchmark workloads for evaluation feedback.
6. Related Work AI-evolved solutions for systems. Recent work has explored using AI agents to design and optimize system algorithms. ADSO [9] uses OpenEvolve [34] to iteratively generate, evaluate, and refine code for system applications. AdaEvolve [7] improves this loop by adaptively reallocating search effort toward more promising evolutionary directions. Evox [25] further evolves both candidate solutions and the search strategies that produce them. Glia [18] proposes an autonomous architecture for designing and optimizing system components such as routing, scheduling, and autoscaling algorithms. Engram [20] focuses on improving long-horizon LLM search by reducing local-search bias and preserving useful context across iterations. Self-Defining Systems [1] takes a broader view, using multi-agent systems with long-term memory to operate and improve complex applications over time. These systems show that AI agents can produce high-scoring system code compared to original human-designed program. AIC HILLES takes a different stance, to learn whether these AI-evolved programs remain safe and robust beyond the evaluator workloads used. AIC HILLES tests the outputs of AI agents and searches for valid adversarial workloads that expose crashes, resource blowups, or KPI regressions relative to the original program.
8. Conclusions AI-driven system evolution can substantially help systems, but these gains may come with hidden weaknesses. This paper argues that evaluating AI-evolved system programs requires testing not only average-case performance on fixed benchmarks, but also worst-case behavior across valid workload spaces. We present AIC HILLES, a weakness searching framework that compares an AI-evolved program against its human baseline. Results show that AIC HILLES exposes distinct hidden weaknesses across evolved programs and applications. We propose that automated weakness discovery is a necessary step toward safely deploying AIgenerated systems code.
Traditional fuzzing. Greybox fuzzers use lightweight execution feedback to guide mutation: AFL [40] retains inputs that increase edge coverage, AFL++ [14] integrates practical AFL-family improvements, and LibAFL [15] modularizes these components for reuse. Performance-oriented fuzzers replace or augment coverage with resource signals: SlowFuzz [32] searches for worst-case complexity inputs, PerfFuzz [22] uses multi-dimensional feedback to expose diverse
13
References [1]
A NDERSON , T., M AHAJAN , R., P ETER , S., AND Z ETTLEMOYER , L. Self-defining systems.
[2]
A NTHROPIC. Introducing claude opus 4.6. https://www.anthropic. com/news/claude-opus-4-6, 2026.
[3]
A SCHERMANN , C., F RASSETTO , T., H OLZ , T., JAUERNIG , P., S ADEGHI , A.-R., AND T EUCHERT, D. Nautilus: Fishing for deep bugs with grammars. In NDSS (2019), vol. 19, p. 337.
[4]
[5]
[18] H AMADANIAN , P., K ARIMI , P., NASR -E SFAHANY, A., N OOR BAKHSH , K., C HANDLER , J., PARANDEH G HEIBI , A., A LIZADEH , M., AND BALAKRISHNAN , H. Glia: A human-inspired ai for automated systems design and optimization. arXiv preprint arXiv:2510.27176 (2025). [19] H YPOTHESIS. Hypothesis: a property-based testing library for python. https://github.com/HypothesisWorks/hypothesis/, 2025. [20] K ARIMI , P., N OORBAKHSH , K., A LIZADEH , M., AND BALAKRISH NAN , H. Improving coherence and persistence in agentic ai for system optimization. arXiv preprint arXiv:2603.21321 (2026).
BABI Ć , D., B UCUR , S., C HEN , Y., I VAN ČI Ć , F., K ING , T., K USANO , M., L EMIEUX , C., S ZEKERES , L., AND WANG , W. Fudge: fuzz driver generation at scale. In Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (New York, NY, USA, 2019), ESEC/FSE 2019, Association for Computing Machinery, p. 975–985.
[21] K WON , W., L I , Z., Z HUANG , S., S HENG , Y., Z HENG , L., Y U , C. H., G ONZALEZ , J., Z HANG , H., AND S TOICA , I. Efficient memory management for large language model serving with pagedattention. In Proceedings of the 29th symposium on operating systems principles (2023), pp. 611–626. [22] L EMIEUX , C., PADHYE , R., S EN , K., AND S ONG , D. Perffuzz: Automatically generating pathological inputs. In Proceedings of the 27th ACM SIGSOFT international symposium on software testing and analysis (2018), pp. 254–265.
C ADAR , C., D UNBAR , D., AND E NGLER , D. Klee: unassisted and automatic generation of high-coverage tests for complex systems programs. In Proceedings of the 8th USENIX Conference on Operating Systems Design and Implementation (USA, 2008), OSDI’08, USENIX Association, p. 209–224.
[6]
C ADAR , C., G ANESH , V., PAWLOWSKI , P. M., D ILL , D. L., AND E NGLER , D. R. Exe: Automatically generating inputs of death. ACM Trans. Inf. Syst. Secur. 12, 2 (Dec. 2008).
[7]
C EMRI , M., AGRAWAL , S., G UPTA , A., L IU , S., C HENG , A., M ANG , Q., NAREN , A., E RDOGAN , L. E., S EN , K., Z AHARIA , M., ET AL . Adaevolve: Adaptive llm driven zeroth-order optimization. arXiv preprint arXiv:2602.20133 (2026).
[8]
C HENG , A., K ABCENELL , A., C HAN , J., S HI , X., BAILIS , P., C ROOKS , N., AND S TOICA , I. Towards optimal transaction scheduling. Proceedings of the VLDB Endowment 17, 11 (2024), 2694–2707.
[9]
C HENG , A., L IU , S., PAN , M., L I , Z., AGARWAL , S., C EMRI , M., WANG , B., K RENTSEL , A., X IA , T., PARK , J., ET AL . Let the barbarians in: How ai can accelerate systems performance research. arXiv preprint arXiv:2512.14806 (2025).
[23] L I , A., PADHYE , R., AND S EKAR , V. Spider: Fuzzing for stateful performance issues in the onos software-defined network controller. In 2025 IEEE Conference on Software Testing, Verification and Validation (ICST) (2025), IEEE, pp. 1–12. [24] L IU , N. F., L IN , K., H EWITT, J., PARANJAPE , A., B EVILACQUA , M., P ETRONI , F., AND L IANG , P. Lost in the middle: How language models use long contexts. CoRR abs/2307.03172 (2023). [25] L IU , S., AGARWAL , S., M AHESWARAN , M., C EMRI , M., L I , Z., M ANG , Q., NAREN , A., B ONEH , E., C HENG , A., PAN , M. Z., ET AL . Evox: Meta-evolution for automated discovery. arXiv preprint arXiv:2602.23413 (2026). [26] L IU , S., B ISWAL , A., K AMSETTY, A., C HENG , A., S CHROEDER , L. G., PATEL , L., C AO , S., M O , X., S TOICA , I., G ONZALEZ , J. E., ET AL . Optimizing llm queries in relational data analytics workloads. Proceedings of Machine Learning and Systems 7 (2025). [27] M ILLER , B. P., F REDRIKSEN , L., AND S O , B. An empirical study of the reliability of unix utilities. Communications of the ACM 33, 12 (1990), 32–44.
[10] C HENG , A., L IU , S., PAN , M., L I , Z., WANG , B., K RENTSEL , A., X IA , T., C EMRI , M., PARK , J., YANG , S., ET AL . Barbarians at the gate: How ai is upending systems research. arXiv preprint arXiv:2510.06189 (2025).
[28] M OURET, J.-B., AND C LUNE , J. Illuminating search spaces by mapping elites. arXiv preprint arXiv:1504.04909 (2015). [29] N GUYEN , H. L., AND G RUNSKE , L. Bedivfuzz: integrating behavioral diversity into generator-based fuzzing. In Proceedings of the 44th International Conference on Software Engineering (New York, NY, USA, 2022), ICSE ’22, Association for Computing Machinery, p. 249–261.
[11] C HENG , A., N G , H., K ABCENELL , A., BAILIS , P., Z AHARIA , M., M A , L., S HI , X., AND S TOICA , I. Ai-driven research for databases. arXiv preprint arXiv:2604.06566 (2026). [12] C LAESSEN , K., AND H UGHES , J. Quickcheck: a lightweight tool for random testing of haskell programs. In Proceedings of the fifth ACM SIGPLAN international conference on Functional programming (2000), pp. 268–279.
[30] N OVIKOV, A., V Ũ , N., E ISENBERGER , M., D UPONT, E., H UANG , P.-S., WAGNER , A. Z., S HIROBOKOV, S., KOZLOVSKII , B., RUIZ , F. J., M EHRABIAN , A., ET AL . Alphaevolve: A coding agent for scientific and algorithmic discovery. arXiv preprint arXiv:2506.13131 (2025).
[13] D EEP S EEK AI. Expert Parallelism Load Balancer (EPLB). https: //github.com/deepseek-ai/eplb, 2024. [14] F IORALDI , A., M AIER , D., E ISSFELDT, H., AND H EUSE , M. {AFL++}: Combining incremental steps of fuzzing research. In 14th USENIX workshop on offensive technologies (WOOT 20) (2020).
[31] O PENAI. Introducing introducing-gpt-5/, 2025.
gpt-5.
https://openai.com/index/
[32] P ETSIOS , T., Z HAO , J., K EROMYTIS , A. D., AND JANA , S. Slowfuzz: Automated domain-independent detection of algorithmic complexity vulnerabilities. In Proceedings of the 2017 ACM SIGSAC conference on computer and communications security (2017), pp. 2155– 2168.
[15] F IORALDI , A., M AIER , D. C., Z HANG , D., AND BALZAROTTI , D. Libafl: A framework to build modular and reusable fuzzers. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (2022), pp. 1051–1065. [16] G IT H UB. Skydiscover: A flexible framework for ai-driven scientific and algorithmic discovery. https://github.com/skydiscover-ai/ skydiscover, 2026.
[33] P RIESE , B., AND NAWALGARIA , A. How BASF Manages Thousands of Supply Chain Decisions with AlphaEvolve’s Agentic Algorithms. https://cloud.google.com/blog/products/ai-machine-learning/ how-basf-manages-thousands-of-supply-chain-decisions-with-alphaevolve, 2026.
[17] G REEN , H., AND AVGERINOS , T. Graphfuzz: Library api fuzzing with lifetime-aware dataflow graphs. In Proceedings of the 44th International Conference on Software Engineering (2022), pp. 1070– 1081.
[34] S HARMA , A SANKHAYA. OpenEvolve. algorithmicsuperintelligence/openevolve, 2025.
14
https://github.com/
[35] S NOWFLAKE. Cocoevolve: What if a coding agent could optimize your ai systems? https://www.snowflake.com/en/blog/engineering/ optimize-snowflake-ai-systems-cocoevolve/, 2026. [36] S RIVASTAVA , P., AND PAYER , M. Gramatron: Effective grammaraware fuzzing. In Proceedings of the 30th acm sigsoft international symposium on software testing and analysis (2021), pp. 244–256. [37] WANG , Y., J IA , X., L IU , Y., Z ENG , K., BAO , T., W U , D., AND S U , P. Not all coverage measurements are equal: Fuzzing by coverage accounting for input prioritization. In NDSS (2020). [38] W OODERS , S., L IU , S., JAIN , P., M O , X., G ONZALEZ , J. E., L IU , V., AND S TOICA , I. Cloudcast:{High-Throughput},{Cost-Aware} overlay multicast in the cloud. In 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24) (2024), pp. 281–296. [39] Y U , S., X ING , J., Q IAO , Y., M A , M., L I , Y., WANG , Y., YANG , S., X IE , Z., C AO , S., BAO , K., ET AL . Prism: Unleashing gpu sharing for cost-efficient multi-llm serving. arXiv preprint arXiv:2505.04021 (2025). [40] Z ALEWSKI , M. American fuzzy lop-whitepaper. Retrieved September 1 (2016), 2022. [41] Z AMUDIO A MAYA , J. A., S MYTZEK , M., AND Z ELLER , A. Fandango: evolving language-based testing. Proceedings of the ACM on Software Engineering 2, ISSTA (2025), 894–916.
15
TABLE 5: Representative changes made by AI-evolved TXN schedulers. AdaEvolve replaces the original greedy sampler with a global continuous optimizer, while Engram keeps the greedy structure but adds heavier sampling, restarts, and local search. Original
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
28
AdaEvolve
Engram
def get_best_schedule(workload, 1 def get_best_schedule(workload, 1 def get_best_schedule(workload, num_seqs): num_seqs): num_seqs): def greedy_sample(num_samples, 2 (*@\diff{from scipy.optimize 2 def greedy_sample(num_samples, sample_rate): import dual\_annealing}@*) sample_rate, # random starting transaction 3 (*@\diff{import numpy as np}@*) 3 seed_start=None) start = random.randint( 4 n = workload.num_txns : 0, workload.num_txns - 1) 5 (*@\diff{def priorities\_to\ 4 (*@\diff{\# heuristic or txn_seq = [start] _schedule(x):}@*) seeded start}@*) remaining = list(range( 6 # continuous priorities -> 5 if seed_start is None: workload.num_txns)) permutation 6 start = remaining.remove(start) 7 return list(np.argsort(x)) txn_with_most_writes(workload) for _ in range(workload. 8 (*@\diff{def objective(x):}@*) 7 else: num_txns - 1): 9 schedule = 8 start = seed_start min_cost, min_txn = priorities_to_schedule(x) 9 txn_seq = [start] 100000, -1 10 return workload. 10 remaining = list(range( holdout = [] get_opt_seq_cost(schedule) workload.num_txns)) # sample next-transaction11 (*@\diff{bounds = [(0, n) for \_ 11 remaining.remove(start) choices in range(n)]}@*) 12 for _ in range(workload. for _ in range(num_samples 12 best_cost = float('inf') num_txns - 1): ): 13 best_schedule = None 13 min_cost, min_txn = t = random.choice( 14 (*@\diff{\# multiple annealing 100000, -1 remaining) restarts}@*) 14 holdout = [] holdout.append(t) 15 for restart in range(max(2, 15 for _ in range(num_samples remaining.remove(t) num_seqs // 5)): ): cost = workload. 16 if restart == 0: 16 t = random.choice( get_opt_seq_cost( 17 x0 = remaining) txn_seq + [t]) greedy_initial_by_write_count() 17 holdout.append(t) if cost < min_cost: 18 else: 18 remaining.remove(t) min_cost, min_txn19 x0 = np.random.uniform(0,19 cost = workload. = cost, t n, n) get_opt_seq_cost( if len(remaining) == 20 (*@\diff{result = dual\ 20 txn_seq + [t]) 0: _annealing(}@*) 21 (*@\diff{\# break 21 objective, deterministic tie-breaking}@*) # greedily append best 22 bounds=bounds, 22 if cost < min_cost: sampled txn 23 x0=x0, 23 min_cost, min_txn txn_seq.append(min_txn) 24 maxiter=300, = cost, t holdout.remove(min_txn) 25 no_local_search=False, 24 elif cost == min_cost remaining.extend(holdout)26 seed=restart) and \ return workload. 27 schedule = 25 writes(t) > get_opt_seq_cost(txn_seq), priorities_to_schedule(result.x) writes(min_txn): txn_seq 28 cost = workload. 26 min_txn = t return greedy_sample(10, 1.0) get_opt_seq_cost(schedule) 27 txn_seq.append(min_txn) 29 if cost < best_cost: 28 holdout.remove(min_txn) 30 best_cost, best_schedule 29 = remaining.extend(holdout) cost, schedule 30 return workload. 31 (*@\diff{\# final adjacent-swap get_opt_seq_cost(txn_seq), refinement}@*) txn_seq 32 for i in range(min(10, len( 31 (*@\diff{\# heavier greedy best_schedule)-1)): sampling + restarts}@*) 33 test = best_schedule[:] 32 candidates = [] 34 test[i], test[i+1] = test[i 33 candidates.append(greedy_sample +1], test[i] (40, 1.0)) 35 cost = workload. 34 for _ in range(6): get_opt_seq_cost(test) 35 s = random.randint(0, workload 36 if cost < best_cost: .num_txns - 1) 37 best_cost, best_schedule 36 = candidates.append( cost, test greedy_sample(40, 1.0, s)) 38 return best_cost, best_schedule 37 candidates.sort(key=lambda x: x [0]) 38 (*@\diff{\# local search on best candidates}@*) 39 best_cost, best_seq = float('inf') , None 40 for cost, seq in candidates[:3]: 41 cost, seq = local_search_2opt( seq, 40) 42 cost, seq = local_search_oropt_simple(seq, 20) 43 if cost < best_cost: 44 best_cost, best_seq = cost , seq 45 return best_cost, best_seq
16
9. Appendix AIC HILLES Prompt Details Prompt 1: Workload Space Inference You are analyzing an ADSO application to infer the full input space for adversarial bug discovery. run_workload.py is a fixed per-app harness.
This file is fixed and cannot be changed. It defines the workload dictionary schema. • Parameter names in grammar_workload must exactly match the keys read by workload.get("key", ...). Your task: Produce a JSON object with the following fields. • grammar_config: structural parameters that define the deployment environment, such as number of GPUs, replicas, or nodes. • grammar_workload: per-invocation algorithm inputs, such as request distributions, transaction sequences, query data, or load tensors. • constraints: cross-parameter constraints written as plain English strings. • notes: any other information needed to generate valid inputs. Important: • Structural parameters may be hardcoded constants in the original program, but for risk discovery we want to explore different configurations. • Give each non-fixed structural parameter a valid range to try. • Do not mark a parameter as fixed unless the evaluator is hard-wired to that value. • Example ranges: num_gpus in [8, 16, 32, 64], num_nodes in [1, 2, 4, 8]. Evaluator-hardwired parameters: • If a module-level constant is used directly inside the evaluator, mark it as fixed. • Examples: num_physical_experts = NUM_REPLICAS, gpu_load = total_physical_load.view(..., NUM_GPUS, ...). • If a parameter is only passed into the algorithm, assign a realistic range to explore. For each parameter include: • •
name type: int, float, str, list, or tensor • range: human-readable range • Use values only for true categorical parameters, such as topology type. # CRITICAL: Parameter name fields in grammar_workload must exactly match the keys that run_workload.py reads through workload.get("key") calls. Wrong names silently fall through to defaults and kill exploration • •
diversity. # OUTPUT FORMAT: Return only a JSON block followed by a Python code block. No other text.
Prompt 2: Explain Root Cause of Weaknesses You are analyzing a bug in an AI-optimized program P’. Anomalous execution profile: {{anomalous_lines_summary}} Your task: In exactly 2–3 sentences, state the root cause of this bug. Your explanation must include: • Which specific branch or code path in P’ is triggered by this input. • Why that path produces incorrect or inefficient behavior.
17
•
What property of (c, w) triggers it.
# OUTPUT FORMAT: Return only plain text. No code, no headers, and no bullet points. Naive Agent Baseline Prompt 3: Single Prompt to Find All Weakness Types You are helping find bugs in an AI-optimized program P’ by generating new valid (c, w) input pairs. Each generated input will be compared against the baseline program P on the same workload. Bug types to target: • Correctness: P’ crashes, raises an exception, or times out while P succeeds. • Scalability-time: P’ is significantly slower than P on the same input; a timeout in P’ always counts. • Scalability-memory: P’ uses significantly more peak memory than P, measured by tracemalloc. • Optimality: P produces better output quality than P’ by more than 5% on any quality metric. Target-specific search guidance: • Correctness: try boundary values, empty lists, zero, negative values, maximum values, unusual parameter combinations, missing keys, None, division-by-zero cases, and index-out-of-bounds cases. • Scalability-time: push size/count parameters toward their maximums, and try inputs that expose worse algorithmic complexity, expensive fallback paths, long chains, maximum fan-out, or adversarial orderings. • Scalability-memory: try wide inputs, high-cardinality categorical values, large tensors, large batches, deep object graphs, and inputs that cause P’ to materialize data that P streams or avoids. • Optimality: try skewed distributions, adversarial datasets, all-identical values, zero-valued fields, extreme ratios, and inputs where P’ may trade output quality for speed. Your task: Generate exactly new (c, w) pairs by mutating the seed. Mitigation Prompts Prompt 4: Prompt Patching Mitigation (Cloudcast application as an example) You are an expert in cloud infrastructure optimization. Your task is to evolve the search_algorithm(src, dsts, G, num_partitions) function to minimize overall data transfer cost across multiple clouds. Optimization goal: • Minimize total data transfer cost across multiple cloud networks. • Efficiently broadcast input data from src to multiple destination nodes dsts. • Use parallel paths and overlapping transfers when they reduce cost. • Use the BroadCastTopology class and make_nx_graph function to identify low-cost routes. Search guidance: • Be diverse and innovative, as long as the generated program optimizes the given metric. • Reduce redundant transfers. • Balance load across networks. • Exploit multi-network topologies to reduce broadcast cost. • Prefer strategies that remain reliable on unseen network topologies.
18