Paper deep dive
Self-Evolving Coding Rules for AI Coding Agents
Zhengyuan Jiang, Reachal Wang, Yuepeng Hu, Yupu Wang, Yuqi Jia, Neil Zhenqiang Gong
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 93%
Last extracted: 10/2/2026, 9:24:48 AM
Summary
The paper introduces RuleEvolve, a self-evolving framework for coding rules used by AI coding agents. Unlike static, hand-crafted rules, RuleEvolve iteratively improves a pool of candidate rules using an LLM-powered mutator and a judge module that evaluates correctness, code length, and generation cost. A strategic mutation-allocation method based on performance variance and mean differences optimizes the search process. Experiments across multiple benchmarks (BigCodeBench, HumanEval) and frameworks (OpenHands, OpenAI SDK) show that RuleEvolve outperforms manual rules and prompt optimization baselines by maintaining high functional correctness while significantly reducing code length and token usage.
Entities (10)
Relation Signals (9)
RuleEvolve → evaluatedon → BigCodeBench
confidence 95% · Extensive evaluations across ... three benchmarks demonstrate that RuleEvolve outperforms
RuleEvolve → evaluatedon → HumanEval
confidence 95% · Extensive evaluations across ... three benchmarks demonstrate that RuleEvolve outperforms
Mutator Module → poweredby → LLM
confidence 95% · employs an LLM-powered mutator module
RuleEvolve → uses → Judge Module
confidence 95% · uses a judge module to evaluate these variants and update the pool with the best-performing ones
RuleEvolve → uses → Mutator Module
confidence 95% · RuleEvolve employs an LLM-powered mutator module to generate variants from existing candidates
RuleEvolve → appliedto → OpenHands
confidence 90% · We evaluate our method using two distinct agentic frameworks: OpenHands
RuleEvolve → appliedto → OpenAI SDK
confidence 90% · We evaluate our method using two distinct agentic frameworks: ... a custom GPT-based agent implemented via the OpenAI SDK
RuleEvolve → outperforms → Prompt-Ops
confidence 90% · RuleEvolve outperforms both manual engineering and existing prompt optimization baselines
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:The performance of AI coding agents is highly dependent on their underlying coding rules. However, existing coding rules are typically hand-crafted and fixed, making the process labor-intensive and often suboptimal. In this work, we propose RuleEvolve, a self-evolving framework for coding rules. RuleEvolve maintains a pool of candidate coding rules and iteratively improves them. In each iteration, it employs an LLM-powered mutator module to generate variants from existing candidates, and then uses a judge module to evaluate these variants and update the pool with the best-performing ones. Extensive evaluations across two coding-agent frameworks, four backbone LLMs, and three benchmarks demonstrate that RuleEvolve outperforms both manual engineering and existing prompt optimization baselines in terms of functional correctness of the generated code, code length, and/or generation cost (e.g., tokens used).
Tags
Links
- Source: https://arxiv.org/abs/2610.00650v1
- Canonical: https://arxiv.org/abs/2610.00650v1
Trouble viewing inline? Open PDF directly →
Full Text
58,579 characters extracted from source content.
Expand or collapse full text
Self-Evolving Coding Rules for AI Coding Agents Zhengyuan Jiang Duke University zhengyuan.jiang@duke.edu Reachal Wang Duke University reachal.wang@duke.edu Yuepeng Hu Duke University yuepeng.hu@duke.edu Yupu Wang Duke University yupu.wang@duke.edu Yuqi Jia Duke University yuqi.jia@duke.edu Neil Zhenqiang Gong Duke University neil.gong@duke.edu Abstract The performance of AI coding agents is highly dependent on their underlying coding rules. However, existing coding rules are typically hand-crafted and fixed, making the process labor-intensive and often suboptimal. In this work, we propose RuleEvolve, a self-evolving framework for coding rules. RuleEvolve maintains a pool of candidate coding rules and iteratively improves them. In each iteration, it employs an LLM-powered mutator module to generate variants from existing candidates, and then uses a judge module to evaluate these variants and update the pool with the best-performing ones. Extensive evaluations across two coding- agent frameworks, four backbone LLMs, and three benchmarks demonstrate that RuleEvolve outperforms both manual engineering and existing prompt optimization baselines in terms of functional correctness of the generated code, code length, and/or generation cost (e.g., tokens used). 1 Introduction The evolution of AI coding agents, such as OpenHands [22], OpenCode [2], Claude Code [3], and Cursor [8], has fundamentally redefined code generation tasks by shifting the focus from manual implementation to high-level orchestration. Central to the performance of these agents is the coding rules file, often instantiated as anAGENTS.mddocument and prepended to the backbone model’s input context [1]. These rules play a critical role in determining the correctness and length of the generated code, as well as the associated generation cost. Despite the critical importance of these rules, they are currently almost exclusively hand-crafted by human developers [18]. This manual process is inherently labor-intensive and suboptimal, as human-written rules often lack task-specific alignment and can even degrade agent performance [11]. Although automatic techniques [23] for prompt optimization have been developed, these methods remain difficult to directly apply to self-evolving coding rules. Existing approaches primarily target short, few-sentence instructions, whereas coding rules are typically long, well-documented guidance that present a significantly larger search space. Furthermore, the resource-intensive nature of coding agents renders previous random mutation strategies computationally prohibitive. Consequently, there is a critical need for a framework that can automatically evolve complex coding rules. To bridge this gap, we propose RuleEvolve, a self-evolving framework for coding rules. The overall pipeline is illustrated in Figure 1. RuleEvolve takes as input a set of coding tasks and aims to evolve coding rules that can generalize to improve code generation on other tasks. Specifically, RuleEvolve maintains a pool ofmcandidate coding rules and iteratively evolves them. In each iteration, it employs an LLM-powered mutator module to generateNmutations from the current candidates. Each mutation is then evaluated by a judge module, which assesses performance in terms of code 40th Conference on Neural Information Processing Systems (NeurIPS 2026). arXiv:2610.00650v1 [cs.CL] 30 Sep 2026 correctness, code length, and generation cost. Based on these evaluations, RuleEvolve updates the pool by retaining the top-performing m candidates. Initial Rules Pick Top-m Candidates Update Rule Pool ... ... Coding Rules Task Coding Agent Code Correctness Cost Length Score Judge Module Mutator Module Score Candidate RulesMutated Candidates Allocated Mutations Rule Pool ...... Mutated Cadidates Iterations Refined Rules Figure 1: Pipeline of RuleEvolve. One challenge is how to allocate theNmutations among themcandidates in the pool in each iteration. Naive strategies, which distribute mutations equally or proportionally based on each candidate’s performance, produce suboptimal results, as demonstrated in our experiments. To enhance effectiveness, we propose a strategic mutation-allocation method, which dynamically distributes theNmutations by prioritizing candidates with higher performance variance or those whose mean performance is closer to the current best. We evaluate RuleEvolve across two coding-agent frameworks, four backbone LLMs, and three coding benchmarks. Extensive experiments show that the proposed method consistently maintains or improves functional correctness measured by pass rate, while significantly reducing code length and generation cost, as measured by generation time and token usage. For instance, on the BigCodeBench dataset using the OpenAI SDK with gpt-5.3-codex, RuleEvolve successfully reduced average code length by over 60% without sacrificing pass rate. 2 Related Works 2.1 AI-assisted Code Generation The landscape of software engineering has been transformed by AI-assisted code generation. To evaluate these AI-generated code, the research community has established several coding benchmarks, such as HumanEval [6] and BigCodeBench [28], which assess the ability of models to generate executable and functional code across a variety of programming tasks. Recent works [16,26] have sought to enhance the quality of generated code through prompting strategies. However, these efforts primarily focus on the performance of the underlying coding LLM in isolation rather than within the agentic framework. Furthermore, these studies focus on the optimization of task-specific prompts to the coding LLM, without considering the self-evolving of the coding rules that guide the code generation process universally. 2.2 Coding Rules for AI Coding Agents AI coding agents rely on coding rules, typically stored in anAGENTS.mdfile, to guide the generation of code. These rules and guidance are combined with the system and user prompts to serve as input for the backbone LLM. The specific rules provided influence the structure and style of the generated code. While recent works [10,11,7] have explored the impact of these rules on code generation, these studies primarily focus on measurement without providing practical insights into how these coding rules can be systematically improved or evolved. 2 2.3 Self-evolving Agents Existing studies on self-evolving agents primarily focus on models, tools, skills, and mem- ory [25,19,20,27]. While coding rules are central to coding agents, their self-evolving remains largely unexplored. Automatic prompt optimization techniques [23,14,21,9,17,15,4,12] can theoretically be applied to optimize coding rules; however, these methods primarily target short prompts consisting of only a few sentences. In contrast, coding rules are extensive, well-documented sets of instructions that create a significantly larger search space beyond the capability of existing optimizers. Consequently, applying current prompt optimization techniques directly to coding rules yields suboptimal performance, as confirmed by our experiments with Prompt-Ops [23]. 3 Problem Definition 3.1 AI Agents for Code Generation We consider an AI coding agentA θ powered by a backbone LLM with parametersθ. The agent gen- erates code conditioned on a specific programming task and underlying coding rules. In practice, for most modern coding agents, these rules are instantiated via anAGENTS.mddocument and prepended to the LLM’s input context. Letx ∈ Xdenote a coding task (i.e., the problem description),rdenote the coding rules, andy denote the generated code, whereXis the coding task set. Formally, the coding agentA θ samples the code y from the conditional distribution: y ∼ p θ (·| x,r).(1) Given a coding taskxand fixed parametersθ, the coding rulesrsignificantly influence the code generation process, thereby affecting the correctness, length, and inference cost. While correctness ensures the functional integrity of the code, length and inference cost are equally critical for real-world deployment. Code length determines the performance of the generated code, where optimized logic reduces execution latency and resource consumption. Inference cost directly affect the scalability of the agentic system; by minimizing token usage and generation time, developers can substantially lower API expenses and improve the responsiveness of the development cycle. Formally, we define two primary goals for the coding rule self-evolving process: • The generated code y should be executable and functionally correct. •The evolved coding rules should reduce the code length as possible and minimize inference costs during the generation process. 3.2 Objective To satisfy the first goal, we define a correctness constraint. LetV(x,y)∈0, 1be a code verifier that determines whether codeyis executable and correctly solves the programming taskx, where V(x,y) = 1indicates success. In practice,Vmay be implemented by executingyagainst a set of test cases associated with x. The evolved coding rules r must satisfy: 1 |X| X x∈X E y∼p θ (·|x,r) [V(x,y)]≥ τ,(2) whereτis a predefined threshold ensuring that the average correctness rate of the agentA θ across the task setX remains acceptable. To satisfy the second goal, we define a code-length scoreE(y)and a cost scoreC(A θ ,x,r). A higher E(y)indicates that the generated codeyis more concise, while a higherC(A θ ,x,r)indicates lower resource consumption during the generation process. Formally, the coding rule self-evolving process is expressed as the following constrained optimization problem: max r 1 |X| X x∈X E y∼p θ (·|x,r) [E(y) + C(A θ ,x,r)] s.t. 1 |X| X x∈X E y∼p θ (·|x,r) [V(x,y)]≥ τ.(3) 3 4 RuleEvolve 4.1 Overview To achieve these objectives, we propose RuleEvolve, a self-evolving framework for coding rules. As illustrated in Figure 1, RuleEvolve consists of three primary components: a rule pool of fixed sizem, a mutator module for generating mutated candidates, and a judge module for evaluation and selection. Given the initial coding rulesr, RuleEvolve first employs the mutator module to populate the pool withmmutated versions. In each subsequent iteration,Nnewly mutated candidates are generated frommcandidates in the current pool. Mutations are strategically allocated based on the historical mean and variance of the candidates’ scores. Finally, them + Ncandidates are evaluated by the judge module; the top m candidates are retained for the next iteration, while others are pruned. Challenge and motivation: The self-evolving of coding rules presents two key challenges. First, the generation process in a coding agent typically involves multi-turn interactions and external tool- calling, rendering the pipeline non-differentiable and precluding direct gradient-based optimization. We address this by implementing an iterative mutation and pruning framework that leverages the mutator module and the judge module to approximate the optimization process (see Section 4.2). Second, unlike standard prompt optimization tasks that involve short targets and low evaluation costs, coding rules are significantly more resource-intensive to evolve. Each rule set requires full agent execution and verification, leading to substantial latency and API token consumption. To avoid resource waste and enhance effectiveness, we propose a strategic mutation-allocation method that prioritizes mutating promising candidates, as detailed in Section 4.3. 4.2 Iterative Mutation and Pruning MutatorM: The mutator module, powered by an LLM, takes the coding rulesrand a mutation guidancegas input to produce a mutated candidater m =M(r,g). The mutation guidancegtypically consists of a natural language directive, such as: "Mutate the coding rules for an AI coding agent into a new variant by improving wording, reordering or combining steps, and varying the style." JudgeJ: The Judge module provides the evaluation environment for generating code under specific coding rules, executing the generated code, and assessing performance across the dimensions of correctness, length, and inference cost. Specifically, the JudgeJtakes the coding rulesr, the agent A θ , and a task setX as input to produce a score S =J (r,A θ ,X ). As formulated in Section 3.2, this score consists of two components. The first is a correctness penalty designed to ensure that the evolved rules do not degrade the agent’s functional performance. Given the code verifierV , the penalty is defined as: E x∈X [V(x,A θ (x,∅))−V(x,A θ (x,r))] + ,(4) whereA θ (x,∅)denotes the code generated by the agent without external coding rules,A θ (x,r) denotes the code generated using coding rules r, and [z] + = max(z, 0). The second component focuses on the code length and inference cost of the generation process. As illustrated in Figure 2a, there is a high correlation between code characters and token usage during generation. Consequently, we approximate both code length and inference cost using the number of characters of the generated code, denoted by|A θ (x,r)|. The overall score S is formulated as: S =−|A θ (x,r)|− λ·E x∈X [V(x,A θ (x,∅))−V(x,A θ (x,r))] + ,(5) where λ is a hyperparameter that balances the trade-off between two components. Iterative Process: The complete procedure is summarized in Algorithm 1. Our approach begins by populating an initial candidate rule poolPthroughmmutations of the initial coding rules. In each iterationt, we strategically distributeNmutations among existingmcandidates based on their historical scores. This results inNnewly mutated candidates by the mutator moduleM, which are subsequently evaluated by the judge moduleJ. To maintain a manageable search space and focus on high-performing regions, we employ a pruning step that retains only the top-mcandidates for the subsequent iteration. AfterTiterations, the framework returns the coding rules that achieved the highest average score. 4 Algorithm 1 RuleEvolve: Coding Rule Self-Evolving Require:Initial rulesr I , task setX, rule pool sizem, number of mutationsN, agentA θ , mutator M, judgeJ , max iterations T 1: P ←M(r I ,m)▷ Initialize pool with m mutated candidates 2: S ←J (P,A θ ,X )▷ Obtain initial scores for the pool 3: for t = 1 to T do 4: n 1 ,...,n m ← MUTATIONALLOCATION(S,N ) ▷ Allocate N mutations strategically 5: P new ,S new ←∅,∅ 6:for j = 1 to m do 7: R new ←M(P j ,n j )▷ Generate n j new mutations from candidate j 8: P new ←P new ∪R new 9: S new ←S new ∪S j for each r ∈R new ▷ Inherit score set from parent j 10:end for 11: S eval ←J (P new ,A θ ,X )▷ Evaluate new candidates 12: S new ← Update(S new ,S eval )▷ Update score sets 13: P,S ← PRUNE(P ∪P new ,S∪S new ,m)▷ Retain top-m candidates 14: end for 15: return arg max r∈P avg(S r ) 4.3 Strategic Mutation Allocation To avoid meaningless mutations and enhance effectiveness, we employ the Optimal Computing Budget Allocation [5] to distributeNmutations amongmcandidates wisely. The core objective is to maximize the probability of correctly identifying the best-performing candidate while minimizing redundant evaluations of suboptimal candidates. For each candidatei, we maintain a score setS i containing the score from each iteration’s evaluation. To address the cold-start problem and ensure statistical stability, a newly mutated candidate inherits the score set from its parent. This inheritance ensures that all candidates in the rule pool possess the same number of observations, allowing for a consistent computation of the meanˆμ i and standard deviation ˆσ i for candidate i. Letbbe the index of the current best-performing candidate in the pool, i.e., with the highest average score. We determine the allocation weights w i for all i̸= b such that: w i ∝ ˆσ i ˆμ b − ˆμ i 2 .(6) This formulation ensures that more mutations are allocated to candidates with higher performance variance or those whose mean performance is closer to the current best. The weight for the best candidate w b is then calculated as follows to maintain overall allocation efficiency: w b = ˆσ b v u u t X i̸=b w 2 i ˆσ 2 i .(7) Finally, the discreten i mutations for each candidate is determined by normalizing these weights such that P n i = N. By iteratively refreshing these statistics, updating allocation weightsw i , and redistributing the mutationsn i , RuleEvolve focuses its search on the most promising regions of the coding rule space, improving the effectiveness of the evolving process. Experimental results validate this by comparing with naive mutation-allocation strategies. More details can be found in Appendix B. 5 Evaluation 5.1 Experimental setup Datasets: We utilize the BigCodeBench benchmark [28] as our primary dataset for coding rules evolvement. From this benchmark, we randomly sample 1,000 instances to serve as a training set. 5 Algorithm 2 MutationAllocation Require: Score setsS i for candidates1,...,m, number of mutations N 1: Compute means ˆμ i and standard deviations ˆσ i fromS i for each i∈1,...,m 2: b← arg max i ˆμ i 3: for i = 1 to m,i̸= b do 4:∆ i ← max(ˆμ b − ˆμ i ,ε) 5: w i ← (ˆσ i /∆ i ) 2 6: end for 7: w b ← ˆσ b q P i̸=b (w 2 i /ˆσ 2 i ) 8: n 1 ,...,n m ← round N · w i P j w j 9: returnn 1 ,...,n m Table 1: OpenAI SDK results. For each method, we report the performance of the backbone that achieved the highest pass rate across benchmarks. Metrics include Pass Rate (PR), Avg. Code Lines (CLn), Avg. Code Characters (C), Avg. Generation Time (Time), and Avg. Token Usage (Tok). Method PR↑CLn↓C↓Time↓Tok↓ BCB BCB-HHEBCB BCB-HHEBCB BCB-HHEBCB BCB-HHEBCB BCB-HHE No rule0.470.250.97 35.742.326.4 11561406812.4 6.005.444.24 623.5666.5502.9 Manual rule 0.450.230.98 69.084.844.4 2372294611368.7510.55.08 10221147663.8 Prompt-Ops 0.480.230.89 13.815.74.50 474.4583.0126.5 2.302.901.33 581.7588.7406.3 RuleEvolve0.490.260.99 12.620.84.40 453.1745.3114.4 3.022.901.48 544.5595.8367.5 During the self-evolving process, each iteration’s scores are obtained using mini-batches of sizeB, sampled randomly from this training set. To evaluate the performance of evolved coding rules, we employ three coding benchmarks: BigCodeBench, BigCodeBench-Hard [28], and HumanEval [6]. For each of these benchmarks, we randomly select 100 samples as our testing benchmark. Sam- ples drawn from BigCodeBench for testing are strictly disjoint from the training sets used during evolvement. Coding agents: We evaluate our method using two distinct agentic frameworks: OpenHands [22], a state-of-the-art open-source autonomous agent, and a custom GPT-based agent implemented via the OpenAI SDK. For OpenHands, our evolved coding rules are provided through the AGENTS.md configuration, while for OpenAI SDK, rules are integrated directly into the system prompt. Backbone models: To evaluate the generalizability of coding rules evolvement approaches, we conduct experiments using both proprietary and open-weight models. For the proprietary models, we utilize gpt-4.1-mini, gpt-5-mini, and the state-of-the-art gpt-5.3-codex, all accessed via the OpenAI API. For the open-weight model, we employ Qwen-Coder-30b [24]. We evolve the coding rules for each model respectively. Baselines: We compare RuleEvolve against several baselines to assess the impact of our coding rules self-evolvement. The No Rule baseline represents a vanilla setting where the agent receives only the task description without any coding rules. The Manual Rule baseline utilizes manually written coding rules sourced from the awesome-cursorrules repository [18]; notably, our experiments indicated that providing coding rules do not consistently yield performance gains, likely due to a lack of task-specific alignment. This observation aligns with conclusions in [11]. Prompt-Ops [23] is a baseline designed for prompt optimization for LLMs. Our results show that such techniques achieve only a suboptimal trade-off between correctness and code length, in most cases sacrificing the functional correctness of the generated code. To demonstrate the effectiveness of our strategic mutation-allocation method, we also evaluate two naive mutation-allocation strategies: even and proportional allocation, which distribute mutations equally or proportionally based on each candidate’s average score. Evaluation Metrics: On testing benchmarks, we evaluate the coding rules across three dimensions: correctness, code length, and inference cost. Correctness is measured by the pass rate of the code, defined as the percentage of generated code that satisfy all provided test cases across the testing benchmark. Code length is assessed through two metrics: code lines and code characters. Inference 6 Table 2: OpenHands results. For each method, we report the performance of the backbone that achieved the highest pass rate across benchmarks. Metrics include Pass Rate (PR), Avg. Code Lines (CLn), Avg. Code Characters (C), Avg. Generation Time (Time), and Avg. Token Usage (Tok). Method PR↑CLn↓C↓Time↓Tok↓ BCB BCB-HHEBCB BCB-HHEBCB BCB-HHEBCB BCB-HHEBCB BCB-HHE No rule0.490.290.99 35.443.217.5 10601324503.4 10.612.86.89 11431238697.5 Manual rule 0.490.290.99 42.953.521.7 13501722577.6 12.214.17.14 12931443727.1 Prompt-Ops 0.430.250.99 20.127.519.3 615.2880.2548.7 40.241.412.6 903.1986.9725.5 RuleEvolve0.520.270.99 26.631.812.7 814.61009373.5 9.7611.67.15 10161075612.6 cost is measured by generation time and token usage during the inference process. The averages of the latter four metrics are computed only on code that is functionally correct. Parameter settings: By default, for our RuleEvolve, we set the number of iterationT=10, number of mutationsN=20, pool sizem=5, coding task batch sizeB=10, balance parameterλ=3,000, and ε=10 −6 . For manual rule, we use the fixed one, as shown in Appendix F. For Prompt-Ops, we use their default settings. 5.2 Main Results Table 1 and Table 2 present a comprehensive comparison of RuleEvolve against other baseline approaches. Generally, RuleEvolve outperforms existing baselines by achieving a superior balance between functional correctness, code length and inference cost. Specifically, RuleEvolve consistently achieves the highest or equal Pass Rate (PR) across all benchmarks. When achieving comparable PRs to "No rule" or "Manual rule", RuleEvolve demonstrates significant improvements in code length and inference cost. For example, on the BigCodeBench (BCB) benchmark within the OpenAI SDK framework, RuleEvolve improves the PR from 0.45 (Manual rule) to 0.49, while simultaneously reducing the average code characters from 2372 to 453.1 and token usage from 1022 to 544.5. Similarly, in the OpenHands environment for the HumanEval (HE) benchmark, RuleEvolve maintains a comparable PR of 0.99 while reducing average code lines to 12.7, compared to 21.7 for human- written rules. We also note that Prompt-Ops occasionally achieves lower code length and inference cost than RuleEvolve in certain scenarios. For instance, on BigCodeBench-Hard (BCB-H) within the OpenAI SDK, Prompt-Ops yields an average token usage of 588.7 compared to 595.8 for RuleEvolve. However, the gains in code length or inference cost come at the expense of functional integrity; in the OpenHands BCB scenario, Prompt-Ops suffers a substantial drop in PR to 0.43, whereas RuleEvolve reaches 0.52. We stress that PR is the most critical metric in autonomous coding; if the generated code is incorrect, optimizing for code length or inference cost becomes meaningless. By prioritizing functional correctness, RuleEvolve ensures that gains in code length or inference cost do not compromise the agent’s primary utility. The comprehensive results across diverse backbones are detailed in Table 5 and Table 6 in the Appendix. Across all evaluated backbone models, RuleEvolve consistently achieves superior or comparable pass rates. At the same time, RuleEvolve significantly reduces code length and inference cost in most cases. For instance, with the gpt-5-mini backbone on BCB, RuleEvolve achieves a PR of 0.46 compared to 0.31 for manual rules, while simultaneously reducing token usage by nearly 40%. Furthermore, RuleEvolve consistently outperforms Prompt-Ops across nearly all backbone–benchmark combinations. While Prompt-Ops often struggles with correctness (e.g., dropping to a 0.67 PR on HumanEval (HE) with Qwen-Coder-30B), RuleEvolve maintains high PRs across all benchmarks and backbone models. We also observe that different backbone models exhibit diverse generation styles; for example, gpt-5-mini tends to produce longer code and requires more generation time, while gpt-5.3-codex is more efficient. Multi-seed results: To assess the robustness and statistical stability of RuleEvolve, we performed evaluations across 10 independent seeds using the GPT-4.1-mini backbone on the BigCodeBench dataset. As shown in Table 3, RuleEvolve maintains a stable Pass Rate (PR of0.502 ± 0.026, which is comparable to the "No rule" baseline and superior to the "Public rule". Also, RuleEvolve yields significantly more concise code, achieving the lowest average code lines (24.3± 0.4) and characters (794.4± 14) among all evaluated methods. Notably, our framework achieves these gains 7 Table 3: Multi-seed results on BigCodeBench using GPT-4.1-mini as backbone LLM. Values are mean± standard deviation (SD) across 10 seeds. MethodPR↑CLn↓C↓Time (s)↓Tok↓ No rule0.502± 0.01532.5± 0.41028± 8.18.66± 0.741181± 9.3 Public rule0.498± 0.03244.9± 0.71482± 2510.21± 1.152049± 35 Prompt-Ops0.502± 0.02726.3± 0.4811.4± 106.81± 0.621130± 15 RuleEvolve (OCBA)0.502± 0.02624.3± 0.4794.4± 149.67± 1.901019± 18 with a high degree of consistency, as evidenced by the standard deviations reported across 10 seeds. These multi-seed results confirm that RuleEvolve effectively and reliably optimizes coding rules for efficiency without compromising the agent’s primary problem-solving utility. Results on SWE-Bench Lite: To evaluate the scalability of our approach in complex, repository- level environments, we test RuleEvolve on SWE-Bench Lite [13] using a subset of 100 tasks. As shown in Table 4, RuleEvolve achieves the highest PR of 0.340, outperforming other baselines. Consistent with main results, the evolved rules effectively optimize for code efficiency, reducing average code lines from 8.5 to 5.7 and characters from 380 to 254. Although generation time increases, likely due to the increased reasoning overhead of repository-level tasks, the functional correctness is well preserved. Overall, these findings confirm that RuleEvolve can generalize to real-world repository-level scenarios. 5.3 Ablation Study 05101520 Iteration 0.0 0.2 0.4 0.6 0.8 1.0 Pass Rate Pass Rate 05101520 Iteration 18 20 22 24 26 28 30 Average Code Lines Average Code Lines 05101520 Iteration 600 700 800 900 Average Code Characters Average Code Characters 05101520 Iteration 6 7 8 9 Average Generation Time (s) Average Generation Time 05101520 Iteration 900 950 1000 1050 Average Tokens Used Average Tokens Used 05101520 Iteration 0.0 0.2 0.4 0.6 0.8 1.0 Normalized Value (0-1) All Metrics (Normalized) Pass Rate Code Lines Code Characters Gen Time Tokens (a) Metrics vs. Iterations EvenProportionalRuleRefine 0.48 0.50 0.52 0.54 0.56 Pass Rate 0.5000.5000.500 (a) Pass Rate EvenProportionalRuleRefine 22 23 24 25 26 27 Average Code Lines 23.4 23.9 22.6 (b) Average Code Lines EvenProportionalRuleRefine 700 725 750 775 800 825 850 875 Average Code Characters 753.2 781.3 736.2 (c) Average Code Characters EvenProportionalRuleRefine 15 16 17 18 19 20 21 22 23 Average Generation Time (s) 17.37s 20.47s 15.48s (d) Average Generation Time EvenProportionalRuleRefine 950 975 1000 1025 1050 1075 1100 1125 Average Token Usage 980.9 998.6 975.2 (e) Average Token Usage (f) Legend (f) Legend Even Proportional RuleRefine (b) Impact of mutation allocation 510203040 N 0.46 0.48 0.50 0.52 0.54 Pass Rate Pass Rate 510203040 N 20 21 22 23 24 Average Code Lines Code Lines 510203040 N 680 700 720 740 760 Average Code Characters Code Characters 510203040 N 8 10 12 Average Generation Time (s) Generation Time 510203040 N 940 950 960 970 980 990 Average Token Usage Token Usage (c) Impact of number of mutation N 124510 m 0.46 0.48 0.50 0.52 0.54 Pass Rate Pass Rate 124510 m 22 24 26 28 30 Average Code Lines Code Lines 124510 m 700 750 800 850 900 Average Code Characters Code Characters 124510 m 8 9 10 11 12 Average Generation Time (s) Generation Time 124510 m 950 975 1000 1025 1050 1075 Average Token Usage Token Usage (d) Impact of pool size m Figure 2: Ablation study results. 8 Table 4: SWE-bench Lite results with GPT-4.1- mini as backbone LLM. MethodPR↑CLn↓C↓Time (s)↓Tok↓ No rule0.3308.5380131.17911 Public rule0.1909.1413166.45867 Prompt-Ops0.0805.4236175.24684 RuleEvolve0.3405.7254297.46722 Impact of number of iterationsT: Figure 2a shows the evolution of metrics over 20 itera- tions during the evolvement process. The pass rate remains remarkably consistent throughout the iterations, demonstrating that RuleEvolve successfully optimizes for code length and infer- ence cost without compromising the correctness of the generated code. In contrast, average code lines, average code characters, and average to- kens usage metrics all exhibit a significant and continuous downward trend. The curves for these three metrics are highly similar because they are naturally coupled; reducing the structural verbosity of the code inherently leads to a lower number of tokens required for model inference. While the average generation time generally decreases over all 20 iterations, it exhibits notable fluctuations between iterations. These fluctuations are likely due to the inherent variance in API latency and the stochastic nature of autoregressive generation. Most of the substantial improvements occur within the first 5 iterations, where the slopes of the cost curves are steepest. By the twentieth iteration, the metrics level off, suggesting that the rule evolvement process effectively converges. Impact of mutation-allocation strategies: To investigate the impact of mutation allocation, we compare three variants: 1) evenly dividing theNmutations among themrule candidates, 2) proportional distribution based on average scores, and 3) our strategic allocation method. As shown in Figure 2b, while all variants maintain an identical pass rate of 0.500, our approach produces the most concise code with 22.6 lines and 736.2 characters, outperforming even (23.4 lines, 753.2 chars) and proportional (23.9 lines, 781.3 chars) variants. Additionally, our method minimizes computational cost, reaching the lowest generation time (15.48s) and token usage (975.2) compared to the other two variants. These results confirm that strategic mutation-allocation more effectively evolves coding rules without sacrificing functional correctness. Impact ofNandm: We analyze the sensitivity of RuleEvolve to the number of mutationsNand the pool sizem. As shown in Figure 2c, whenNincreases, average code lines, code characters, and token usage all exhibit a clear downward trend. Notably, these improvements are achieved while maintaining a stable pass rate that fluctuates slightly between 0.48 and 0.51. Similarly, the impact of the pool sizemin Figure 2d reveals that increasingmfrom 1 to 2 provides a substantial reduction in code length and token usage. While these metrics stabilize for values ofmgreater than 2, the initial improvement indicates that maintaining a sufficiently large pool of candidates is crucial for obtaining optimized coding rules. 124610 k 0.0 0.2 0.4 0.6 0.8 1.0 Pass@ k 0.510.51 0.520.520.52 0.26 0.28 0.300.300.30 0.95 0.96 0.97 0.98 0.99 BigCodeBench BigCodeBench-Hard HumanEval Figure 3: Pass@k results. Pass@k results: We evaluate the robustness of our evolved coding rules by measuring the Pass@kmetric across three benchmarks using gpt-4.1-mini, where k indicates the number of versions for code generated for each task. As illustrated in Figure 3, the pass rate for all benchmarks scales positively with the number of samplesk. The steady upward trend across all benchmarks confirms that RuleEvolve effectively optimizes for code efficiency while preserving the model’s problem-solving capacity under higher sampling budgets. 6 Conclusion In this work, we investigate the self-evolvement of coding rules for AI coding agents. We show that coding rules can be evolved to greatly reduce code length and minimize inference costs while maintaining the functional correctness of the generated code. This is achieved by RuleEvolve, our proposed automatic self-evolving framework for coding rules. By employing a mutator, judge module, and a strategic mutation-allocation approach, RuleE- volve successfully evolves coding rules via iterative mutation and pruning. Extensive evaluations across two agentic frameworks, four diverse backbone models, and three coding benchmarks demon- strate that RuleEvolve outperforms both manually crafted rules and existing baselines, establishing a promising direction for coding rules self-evolvement. 9 References [1] Agentsmd. Agents.md. https://agents.md/, 2025. [2] Anomalyco. opencode. https://github.com/anomalyco/opencode, 2025. [3] Anthropics. claude-code. https://github.com/anthropics/claude-code, 2025. [4] Patrick Chao, Alexander Robey, Edgar Dobriban, Hamed Hassani, George J Pappas, and Eric Wong. Jailbreaking black box large language models in twenty queries. In SaTML, 2025. [5] Chun-Hung Chen and Loo Hay Lee. Stochastic simulation optimization: an optimal computing budget allocation. World scientific, 2011. [6] Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde De Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374, 2021. [7] Tianhao Chen, Zhengyuan Jiang, Yuepeng Hu, Yebei Gou, and Neil Zhenqiang Gong. Dynamic malicious skills in agentic ai. arXiv preprint arXiv:2606.16287, 2026. [8] Cursor. cursor. https://github.com/cursor/cursor, 2025. [9]Chrisantha Fernando, Dylan Banarse, Henryk Michalewski, Simon Osindero, and Tim Rock- täschel. Promptbreeder: Self-referential self-improvement via prompt evolution. arXiv preprint arXiv:2309.16797, 2023. [10] Matthias Galster, Seyedmoein Mohsenimofidi, Jai Lal Lulla, Muhammad Auwal Abubakar, Christoph Treude, and Sebastian Baltes. Configuring agentic ai coding tools: An exploratory study. arXiv preprint arXiv:2602.14690, 2026. [11]Thibaud Gloaguen, Niels Mündler, Mark Müller, Veselin Raychev, and Martin Vechev. Evalu- ating agents. md: Are repository-level context files helpful for coding agents? arXiv preprint arXiv:2602.11988, 2026. [12]Zhengyuan Jiang, Yuepeng Hu, Yuchen Yang, Yinzhi Cao, and Neil Zhenqiang Gong. Jail- breaking safeguarded text-to-image models via large language models. In EACL Findings, 2026. [13]Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R Narasimhan. Swe-bench: Can language models resolve real-world github issues? In ICLR, 2023. [14]Omar Khattab, Arnav Singhvi, Paridhi Maheshwari, Zhiyuan Zhang, Keshav Santhanam, Sri Vardhamanan, Saiful Haq, Ashutosh Sharma, Thomas T. Joshi, Hanna Moazam, Heather Miller, Matei Zaharia, and Christopher Potts. Dspy: Compiling declarative language model calls into self-improving pipelines. In ICLR, 2024. [15]Anay Mehrotra, Manolis Zampetakis, Paul Kassianik, Blaine Nelson, Hyrum Anderson, Yaron Singer, and Amin Karbasi. Tree of attacks: Jailbreaking black-box llms automatically. In NeurIPS, 2024. [16]Alessandro Midolo, Alessandro Giagnorio, Fiorella Zampetti, Rosalia Tufano, Gabriele Bavota, and Massimiliano Di Penta. Guidelines to prompt large language models for code generation: An empirical characterization. arXiv preprint arXiv:2601.13118, 2026. [17]Arijit Nag, Animesh Mukherjee, Niloy Ganguly, and Soumen Chakrabarti. Mutantprompt: Prompt optimization via mutation under a budget on modest-sized lms. In ACL Findings, 2025. [18]PatrickJS.awesome-cursorrules.https://github.com/PatrickJS/ awesome-cursorrules/, 2025. [19]Shuai Shao, Qihan Ren, Dongrui Liu, Chen Qian, Boyi Wei, Dadi Guo, Jingyi Yang, Xinhao Song, Linfeng Zhang, Weinan Zhang, et al. Your agent may misevolve: Emergent risks in self-evolving llm agents. In ICLR, 2026. 10 [20]Zeyi Sun, Ziyu Liu, Yuhang Zang, Yuhang Cao, Xiaoyi Dong, Tong Wu, Dahua Lin, and Jiaqi Wang. Seagent: Self-evolving computer use agent with autonomous learning from experience. In ICML, 2026. [21]Zeliang Tong, Zhuojun Ding, and Wei Wei. Evoprompt: Evolving prompts for enhanced zero-shot named entity recognition with large language models. In COLING, 2025. [22]Xingyao Wang, Boxuan Li, Yufan Song, Frank F Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, et al. Openhands: An open platform for ai software developers as generalist agents. In ICLR, 2025. [23]Yuanchen Wu, Saurabh Verma, Justin Lee, Fangzhou Xiong, Poppy Zhang, Amel Awadelkarim, Xu Chen, Yubai Yuan, and Shawndra Hill. Llm prompt duel optimizer: Efficient label-free prompt optimization. arXiv preprint arXiv:2510.13907, 2025. [24] An Yang, Anfeng Li, Baosong Yang, Beichen Zhang, et al. Qwen3 technical report. arXiv preprint arXiv:2505.09388, 2025. [25]Yifan Yang, Ziyang Gong, Weiquan Huang, Qihao Yang, Ziwei Zhou, Zisu Huang, Yan Li, Xuemei Gao, Qi Dai, Bei Liu, et al. Skillopt: Executive strategy for self-evolving agent skills. arXiv preprint arXiv:2605.23904, 2026. [26]Sixiang Ye, Zeyu Sun, Guoqing Wang, Liwei Guo, Qingyuan Liang, Zheng Li, and Yong Liu. Prompt alchemy: Automatic prompt refinement for enhancing code generation. IEEE Transactions on Software Engineering, 2025. [27]Hanrong Zhang, Shicheng Fan, Henry Peng Zou, Yankai Chen, Zhenting Wang, Jiayu Zhou, Chengze Li, Wei-Chieh Huang, Yifei Yao, Kening Zheng, et al. Coevoskills: Self-evolving agent skills via co-evolutionary verification. In COLM, 2026. [28]Terry Yue Zhuo, Vu Minh Chien, Jenny Chim, Han Hu, Wenhao Yu, Ratnadira Widyasari, Imam Nur Bani Yusuf, Haolan Zhan, Junda He, Indraneil Paul, et al. Bigcodebench: Benchmarking code generation with diverse function calls and complex instructions. In ICLR, 2025. A Limitations Our work has several limitations. First, while RuleEvolve maintains or improves functional correct- ness in most scenarios, the objective of reducing code length may still lead to a slight decrease in the pass rate for certain complex tasks where excessive brevity could compromise logic. Second, our self-evolving process relies on an LLM-powered mutator and judge module, which introduces inherent stochasticity and potential biases from the backbone models used during evolving. Third, our study primarily focuses on optimizing for correctness, code length, and inference cost through code length approximation. A more comprehensive exploration of other dimensions, such as code maintainability or architectural complexity, remains for future work. 11 Table 5: Comprehensive OpenAI SDK results on BigCodeBench (BCB), BigCodeBench-Hard (BCB- H), and HumanEval (HE). Metrics include Pass Rate (PR), Avg. Code Lines (CLn), Avg. Code Characters (C), Avg. Generation Time (Time), and Avg. Token Usage (Tok). Backbone Method PR↑CLn↓C↓Time↓Tok↓ BCB BCB-H HE BCB BCB-H HE BCB BCB-HHEBCB BCB-H HE BCB BCB-HHE gpt-4.1 -mini No rule0.470.250.97 35.742.326.4 11561406812.4 6.005.444.24 623.5666.5502.9 Manual rule 0.460.200.92 58.468.637.5 203524481036 12.79.615.36 852.0939.1547.9 Prompt-Ops 0.450.240.92 20.924.16.30 650.8790.7180.0 3.063.941.79 540.5552.8335.4 RuleEvolve 0.460.240.93 16.919.35.10 545.2674.8134.7 2.863.251.37 479.3484.5284.5 gpt-5 -mini No rule0.360.200.95 88.294.646.4 305333771248 29.528.513.7 218522571197 Manual rule 0.310.200.68 12814298.8 472051752926 37.038.623.0 279929731812 Prompt-Ops 0.380.200.99 19.822.88.20 643.0799.7237.4 21.723.615.9 188419831370 RuleEvolve 0.460.200.99 19.020.85.90 611.4740.1163.8 22.022.015.2 171717651249 gpt-5.3 -codex No rule0.460.260.97 47.053.525.2 14101651643.0 5.836.353.28 790.8828.3544.0 Manual rule 0.450.230.98 69.084.844.4 237229461136 8.7510.55.08 10221147663.8 Prompt-Ops 0.480.230.89 13.815.74.50 474.4583.0126.5 2.302.901.33 581.7588.7406.3 RuleEvolve 0.490.260.99 12.620.84.40 453.1745.3114.4 3.022.901.48 544.5595.8367.5 Qwen -Coder -30B No rule0.170.120.90 17.717.527.8 556.5562.7878.9 3.2921.321.3 932.4946.5913.7 Manual rule 0.190.090.69 28.226.528.5 988.4913.2903.3 4.4621.421.3 10831104902.0 Prompt-Ops 0.320.180.67 19.825.57.30 583.0768.5199.4 4.0621.221.6 799.0794.4582.0 RuleEvolve 0.380.190.88 14.718.45.50 492.7652.6153.6 3.9520.921.2 715.5719.0538.6 Table 6: Comprehensive OpenHands results on BigCodeBench (BCB), BigCodeBench-Hard (BCB- H), and HumanEval (HE). Metrics include Pass Rate (PR), Avg. Code Lines (CLn), Avg. Code Characters (C), Avg. Generation Time (Time), and Avg. Token Usage (Tok). Backbone Method PR↑CLn↓C↓Time↓Tok↓ BCB BCB-HHEBCB BCB-HHEBCB BCB-HHEBCB BCB-HHEBCB BCB-HHE gpt-4.1 -mini No rule0.480.270.96 29.834.619.2 937.81127608.1 8.2812.620.8 10791124767.5 Manual rule 0.480.280.95 42.347.222.9 14021597691.8 9.1113.718.3 13201383813.4 Prompt-Ops 0.430.220.71 20.127.517.7 615.2880.2544.1 40.241.457.9 903.1986.9707.7 RuleEvolve0.500.280.98 23.828.516.9 768.9944.6536.3 9.5414.623.0 991.61028725.0 gpt-5 -mini No rule0.400.180.97 66.174.330.2 22032509854.7 12.914.87.10 17931930944.4 Manual rule 0.380.220.96 74.786.542.6 26553080118113.916.37.44 204722501122 Prompt-Ops 0.330.190.99 46.451.519.3 14541656548.7 14.016.212.6 13921469725.5 RuleEvolve0.410.250.98 50.958.517.6 16701956514.4 10.812.86.63 14981623705.6 gpt-5.3 -codex No rule0.490.290.99 35.443.217.5 10601324503.4 10.612.86.89 11431238697.5 Manual rule 0.490.290.99 42.953.521.7 13501722577.6 12.214.17.14 12931443727.1 Prompt-Ops 0.400.250.91 25.332.114.4 787.31012410.4 13.414.713.8 10091072634.6 RuleEvolve0.520.270.99 26.631.812.7 814.61009373.5 9.7611.67.15 10161075612.6 Qwen -Coder -30B No rule0.430.270.97 39.144.028.1 12601449878.7 37.260.121.2 12501291973.8 Manual rule 0.440.280.99 39.543.729.6 12861434907.4 31.856.932.8 12621284996.6 Prompt-Ops 0.350.190.91 32.434.318.2 10201087532.7 23.229.210.2 11191110712.1 RuleEvolve0.440.270.96 27.232.420.3 840.11021611.3 9.8514.214.4 10281067781.1 12 B Justification for Mutation-Allocation Strategy In this section, we provide the theoretical justification for the mutation-allocation strategy used in RuleEvolve. The goal of the Optimal Computing Budget Allocation [5] is to maximize the Probability of Correct Selection (PCS), defined as the probability that the candidate rule set with the highest sample mean is indeed the true best performer. Letmbe the number of candidates in the pool, and letJbe the index of the true best candidate such that μ J = max i μ i . The PCS is given by: PCS = P (ˆμ J > ˆμ i ,∀i̸= J ).(8) Under the assumption that the scoresS i are independent and follow a normal distributionN (μ i ,σ 2 i ), for a large number of mutationsN, the PCS is maximized when the allocationn 1 ,n 2 ,...,n m satisfies the following asymptotic conditions: n i n j = σ 2 i /(μ b − μ i ) 2 σ 2 j /(μ b − μ j ) 2 , i,j ̸= b,(9) and n b = σ b v u u t X i̸=b n 2 i σ 2 i ,(10) where b is the index of the candidate with the current highest sample mean. These conditions provide the following insights into the RuleEvolve evolvement process: •Candidates with a smaller performance gap(μ b − μ i )receive more mutations, as they are the most likely "competitors" to the current best. • Candidates with higher varianceσ 2 i receive more mutations to reduce the uncertainty in their mean estimation. •The mutations for the best candidaten b is scaled based on the aggregate noise of all other candidates, ensuring that the comparison is sufficiently stable. By following this allocation, RuleEvolve minimizes the risk of pruning a potentially superior coding rule due to stochastic noise in mutator generation, ensuring a more robust and efficient search path than uniform allocation. C Analysis on Searched Rules By grouping the rule’s 16 sections into six functional categories, we evaluated the increase in generated code length when each category is removed (tested on BigCodeBench using 40 tasks with GPT-4.1-mini, where the full rule produces 454.1 characters compared to 1,040.6 characters with no rule), as shown in Table 7. Table 7: Character Attribution by Category CategorySectionsChars attributablePer section Output format / self-containment3153.051.0 Algorithm knowledge483.020.7 Brevity style161.661.6 API / library idiom222.811.4 Correctness tactics29.95.0 Process / budget4-5.0-1.2 This analysis yields three findings. First, directives that constrain the form of the code (output format and self-containment) dominate the rule’s impact, accounting for 153 attributable characters. Second, brevity-style directives are the most efficient on a per-section basis, yielding 61.6 characters from a single section. Third, process and budget directives are net negative, removing them actually shortens the output. 13 D Code Quality Metrics For other software engineering metrics, we report metrics over generated files, including complexity, maintainability, and duplication, as shown in Table 8. RuleEvolve reduces cyclomatic complexity Table 8: Code Quality Metrics Comparison MetricNo ruleRuleEvolve Duplicated-block ratio0.10%0.00% Cyclomatic complexity (total)5.373.95 Halstead volume (total)53.028.0 Maintainability index85.178.3 Cyclomatic complexity per SLOC0.2130.260 Docstring rate47.0%1.00% (5.37→3.95), Halstead volume by 47%, and duplicated-block ratio to 0.00%, while maintaining a Grade A maintainability index (78.3 vs. 85.1 for no rule). The remaining trade-off is in code density: complexity per SLOC increases by 22% and docstring coverage decreases from 47% to 1%, indicating that RuleEvolve removes documentation and defensive scaffolding rather than redundant logic. E Generated Code Examples E.1 Problem description The agentic framework is OpenAI SDK. The backbone model is gpt-4.1-mini. d e f i s _ p a l i n d r o m e ( s t r i n g : s t r ) −> b o o l : " " " T e s t i f g i v e n s t r i n g i s a p a l i n d r o m e " " " r e t u r n s t r i n g == s t r i n g [ : : − 1 ] d e f m a k e _ p a l i n d r o m e ( s t r i n g : s t r ) −> s t r : " " " F i n d t h e s h o r t e s t p a l i n d r o m e t h a t b e g i n s w i t h a s u p p l i e d s t r i n g . A l g o r i t h m i d e a i s s i m p l e : − F i n d t h e l o n g e s t p o s t f i x o f s u p p l i e d s t r i n g t h a t i s a p a l i n d r o m e . − Append t o t h e e n d o f t h e s t r i n g r e v e r s e o f a s t r i n g p r e f i x t h a t comes − b e f o r e t h e p a l i n d r o m i c s u f f i x . >>> m a k e _ p a l i n d r o m e ( ’ ’ ) ’ ’ >>> m a k e _ p a l i n d r o m e ( ’ c a t ’ ) ’ c a t a c ’ >>> m a k e _ p a l i n d r o m e ( ’ c a t a ’ ) ’ c a t a c ’ " " " E.2 No Rule " " " S i m p l e p a l i n d r o m e u t i l i t i e s . F u n c t i o n s : − i s _ p a l i n d r o m e ( s t r i n g : s t r ) −> b o o l − m a k e _ p a l i n d r o m e ( s t r i n g : s t r ) −> s t r Run d o c t e s t s w i t h : p y t h o n t a s k . py " " " f r o m t y p i n g i m p o r t O p t i o n a l 14 d e f i s _ p a l i n d r o m e ( s t r i n g : s t r ) −> b o o l : " " " T e s t i f g i v e n s t r i n g i s a p a l i n d r o m e . E x a m p l e s : >>> i s _ p a l i n d r o m e ( ’ ’ ) T r u e >>> i s _ p a l i n d r o m e ( ’ a ’ ) T r u e >>> i s _ p a l i n d r o m e ( ’ a b a ’ ) T r u e >>> i s _ p a l i n d r o m e ( ’ ab ’ ) F a l s e " " " r e t u r n s t r i n g == s t r i n g [ : : − 1 ] d e f m a k e _ p a l i n d r o m e ( s t r i n g : s t r ) −> s t r : " " " F i n d t h e s h o r t e s t p a l i n d r o m e t h a t b e g i n s w i t h t h e s u p p l i e d s t r i n g . A l g o r i t h m : − F i n d t h e l o n g e s t s u f f i x o f t h e s u p p l i e d s t r i n g t h a t i s a p a l i n d r o m e . − Append t o t h e e n d o f t h e s t r i n g t h e r e v e r s e o f t h e p r e f i x t h a t comes b e f o r e t h a t p a l i n d r o m i c s u f f i x . E x a m p l e s : >>> m a k e _ p a l i n d r o m e ( ’ ’ ) ’ ’ >>> m a k e _ p a l i n d r o m e ( ’ c a t ’ ) ’ c a t a c ’ >>> m a k e _ p a l i n d r o m e ( ’ c a t a ’ ) ’ c a t a c ’ >>> m a k e _ p a l i n d r o m e ( ’ a b b a ’ ) ’ a b b a ’ >>> m a k e _ p a l i n d r o m e ( ’ ab ’ ) ’ a b a ’ " " " i f n o t s t r i n g : r e t u r n ’ ’ n = l e n ( s t r i n g ) # F i n d t h e s m a l l e s t i s u c h t h a t s t r i n g [ i : ] i s a p a l i n d r o m e . # T h a t g i v e s t h e l o n g e s t p a l i n d r o m i c s u f f i x . f o r i i n r a n g e ( n ) : i f i s _ p a l i n d r o m e ( s t r i n g [ i : ] ) : # Append r e v e r s e o f p r e f i x t h a t c omes b e f o r e p a l i n d r o m i c s u f f i x p r e f i x = s t r i n g [ : i ] r e t u r n s t r i n g + p r e f i x [ : : − 1 ] # I n p r a c t i c e t h e l o o p a l w a y s r e t u r n s ( b e c a u s e t h e l a s t c h a r i s a p a l i n d r o m e ) , # b u t r e t u r n a f a l l b a c k j u s t i n c a s e . r e t u r n s t r i n g + s t r i n g [ : : − 1 ] i f __name__ == ’ _ _ m a i n _ _ ’ : i m p o r t d o c t e s t f a i l e d , a t t e m p t e d = d o c t e s t . t e s t m o d ( ) 15 i f f a i l e d : p r i n t ( f " f a i l e d d o c t e s t ( s ) f a i l e d o u t o f a t t e m p t e d ) " ) e l s e : p r i n t ( f " A l l a t t e m p t e d d o c t e s t ( s ) p a s s e d . " ) E.3 Manual Rule f r o m t y p i n g i m p o r t L i s t d e f i s _ p a l i n d r o m e ( s t r i n g : s t r ) −> b o o l : " " " R e t u r n T r u e i f t h e g i v e n s t r i n g i s a p a l i n d r o m e . A p a l i n d r o m e r e a d s t h e same f o r w a r d s a n d b a c k w a r d s . The c h e c k i s p e r f o r m e d u s i n g P y t h o n s l i c i n g w h i c h c o r r e c t l y h a n d l e s U n i c o d e c o d e p o i n t s . A r g s : s t r i n g : I n p u t s t r i n g t o t e s t . R e t u r n s : T r u e i f‘ ‘ s t r i n g ‘ ‘ i s a p a l i n d r o m e , F a l s e o t h e r w i s e . E x a m p l e s : >>> i s _ p a l i n d r o m e ( ’ ’ ) T r u e >>> i s _ p a l i n d r o m e ( ’ a ’ ) T r u e >>> i s _ p a l i n d r o m e ( ’ a b a ’ ) T r u e >>> i s _ p a l i n d r o m e ( ’ ab ’ ) F a l s e " " " r e t u r n s t r i n g == s t r i n g [ : : − 1 ] d e f _ p r e f i x _ f u n c t i o n ( s : s t r ) −> L i s t [ i n t ] : " " " Compute p r e f i x − f u n c t i o n ( a . k . a . f a i l u r e f u n c t i o n ) f o r KMP a l g o r i t h m . The p r e f i x − f u n c t i o n f o r a s t r i n g‘ ‘ s ‘ ‘ i s a n a r r a y ‘ ‘ p i ‘ ‘ w h e r e ‘ ‘ p i [ i ] ‘ ‘ i s t h e l e n g t h o f t h e l o n g e s t p r o p e r p r e f i x o f ‘ ‘ s [ : i + 1 ] ‘ ‘ t h a t i s a l s o a s u f f i x o f ‘ ‘ s [ : i + 1 ] ‘ ‘ . T h i s i m p l e m e n t a t i o n r u n s i n O( n ) t i m e a n d O( n ) memory . A r g s : s : I n p u t s t r i n g . R e t u r n s : A l i s t o f i n t e g e r s r e p r e s e n t i n g t h e p r e f i x − f u n c t i o n v a l u e s f o r e a c h p o s i t i o n i n ‘ ‘ s ‘ ‘ . E x a m p l e s : >>> _ p r e f i x _ f u n c t i o n ( ’ a b a b a c a ’ ) [ 0 , 0 , 1 , 2 , 3 , 0 , 1 ] " " " n : i n t = l e n ( s ) p i : L i s t [ i n t ] = [ 0 ] * n f o r i i n r a n g e ( 1 , n ) : 16 j : i n t = p i [ i − 1 ] w h i l e j > 0 a n d s [ i ] ! = s [ j ] : j = p i [ j − 1 ] i f s [ i ] == s [ j ] : j += 1 p i [ i ] = j r e t u r n p i d e f m a k e _ p a l i n d r o m e ( s t r i n g : s t r ) −> s t r : " " " R e t u r n t h e s h o r t e s t p a l i n d r o m e t h a t b e g i n s w i t h " s t r i n g " by a p p e n d i n g c h a r a c t e r s t o i t s e n d . The f u n c t i o n f i n d s t h e l o n g e s t p a l i n d r o m i c s u f f i x o f t h e i n p u t a n d t h e n a p p e n d s t h e r e v e r s e o f t h e r e m a i n i n g p r e f i x . T h i s y i e l d s t h e m i n i m a l n u m b e r o f c h a r a c t e r s t o a p p e n d s o t h e r e s u l t i s a p a l i n d r o m e t h a t s t a r t s w i t h t h e o r i g i n a l s t r i n g . A l g o r i t h m i c i d e a : − L e t ‘ ‘ r e v ‘ ‘ b e t h e r e v e r s e o f ‘ ‘ s t r i n g ‘ ‘ . − Compute t h e p r e f i x − f u n c t i o n on ‘ ‘ r e v + ’ # ’ + s t r i n g ‘ ‘ ; t h e v a l u e a t t h e l a s t p o s i t i o n i s t h e l e n g t h ‘ ‘ k ‘ ‘ o f t h e l o n g e s t p r e f i x o f ‘ ‘ r e v ‘ ‘ t h a t m a t c h e s a s u f f i x o f ‘ ‘ s t r i n g ‘ ‘ e q u i v a l e n t l y , t h e l o n g e s t p a l i n d r o m i c s u f f i x o f ‘ ‘ s t r i n g ‘ ‘ . − Append t h e r e v e r s e o f t h e p r e f i x ‘ ‘ s t r i n g [ : l e n ( s t r i n g ) − k ] ‘ ‘ t o t h e e n d o f ‘ ‘ s t r i n g ‘ ‘ . T h i s r u n s i n l i n e a r t i m e O( n ) a n d l i n e a r s p a c e O( n ) . A r g s : s t r i n g : The i n p u t s t r i n g . May b e e m p t y . R e t u r n s : The s h o r t e s t p a l i n d r o m e t h a t b e g i n s w i t h ‘ ‘ s t r i n g ‘ ‘ . I f ‘ ‘ s t r i n g ‘ ‘ i s a l r e a d y a p a l i n d r o m e , i t i s r e t u r n e d u n c h a n g e d . E x a m p l e s : >>> m a k e _ p a l i n d r o m e ( ’ ’ ) ’ ’ >>> m a k e _ p a l i n d r o m e ( ’ c a t ’ ) ’ c a t a c ’ >>> m a k e _ p a l i n d r o m e ( ’ c a t a ’ ) ’ c a t a c ’ >>> m a k e _ p a l i n d r o m e ( ’ r a c e ’ ) ’ r a c e c a r ’ >>> m a k e _ p a l i n d r o m e ( ’ a ’ ) ’ a ’ " " " n : i n t = l e n ( s t r i n g ) i f n <= 1 : r e t u r n s t r i n g r e v : s t r = s t r i n g [ : : − 1 ] # B u i l d a c o m b i n e d s t r i n g t o c o m p u t e how much o f r e v m a t c h e s a s u f f i x o f # s t r i n g ( i . e . l o n g e s t p a l i n d r o m i c s u f f i x o f s t r i n g ) . c o m b i n e d : s t r = r e v + " # " + s t r i n g p i : L i s t [ i n t ] = _ p r e f i x _ f u n c t i o n ( c o m b i n e d ) k : i n t = p i [ − 1 ] i f p i e l s e 0# l e n g t h o f l o n g e s t p a l i n d r o m i c s u f f i x 17 # Append r e v e r s e o f t h e p r e f i x t h a t i s n o t p a r t o f t h e p a l i n d r o m i c s u f f i x . t o _ a p p e n d : s t r = ( s t r i n g [ : n − k ] ) [ : : − 1 ] r e t u r n s t r i n g + t o _ a p p e n d i f __name__ == ’ _ _ m a i n _ _ ’ : # S i m p l e d e m o n s t r a t i o n a n d smoke t e s t s e x a m p l e s = [ " " , " c a t " , " c a t a " , " r a c e " , " a b a c " ] f o r e x i n e x a m p l e s : p r i n t ( f " e x ! r − > m a k e _ p a l i n d r o m e ( e x ) ! r " ) E.4 Prompt-Ops d e f i s _ p a l i n d r o m e ( s t r i n g : s t r ) −> b o o l : r e t u r n s t r i n g == s t r i n g [ : : − 1 ] d e f m a k e _ p a l i n d r o m e ( s t r i n g : s t r ) −> s t r : i f n o t s t r i n g : r e t u r n ’ ’ f o r i i n r a n g e ( l e n ( s t r i n g ) ) : i f s t r i n g [ i : ] == s t r i n g [ i : ] [ : : − 1 ] : r e t u r n s t r i n g + s t r i n g [ : i ] [ : : − 1 ] r e t u r n s t r i n g + s t r i n g [ : : − 1 ] E.5 RuleEvolve d e f i s _ p a l i n d r o m e ( s t r i n g : s t r ) −> b o o l : r e t u r n s t r i n g == s t r i n g [ : : − 1 ] d e f m a k e _ p a l i n d r o m e ( s t r i n g : s t r ) −> s t r : f o r i i n r a n g e ( l e n ( s t r i n g ) ) : i f s t r i n g [ i : ] = = s t r i n g [ i : ] [ : : − 1 ] : r e t u r n s t r i n g + s t r i n g [ : i ] [ : : − 1 ] r e t u r n s t r i n g F Manual Rules Role Definition • You are a Python master, a highly experienced tutor, a world-renowned ML engineer, and a talented data scientist. • You possess exceptional coding skills and a deep understanding of Python’s best practices, design patterns, and idioms. • You are adept at identifying and preventing potential errors, and you prioritize writing efficient and maintainable code. • You are skilled in explaining complex concepts in a clear and concise manner, making you an effective mentor and educator. •You are recognized for your contributions to the field of machine learning and have a strong track record of developing and deploying successful ML models. •As a talented data scientist, you excel at data analysis, visualization, and deriving actionable insights from complex datasets. Technology Stack • Python Version: Python 3.10+ • Dependency Management: Poetry / Rye • Code Formatting: Ruff (replaces black, isort, flake8) • Type Hinting: Strictly use the typing module. • Testing Framework: pytest • Documentation: Google style docstring 18 • Environment Management: conda / venv • Containerization: docker, docker-compose • Asynchronous Programming: Prefer async and await • Web Framework: fastapi • Demo Framework: gradio, streamlit • LLM Framework: langchain, transformers • Vector Database: faiss, chroma (optional) • Experiment Tracking: mlflow, tensorboard (optional) • Hyperparameter Optimization: optuna, hyperopt (optional) • Data Processing: pandas, numpy, dask (optional), pyspark (optional) • Version Control: git • Server: gunicorn, uvicorn (with nginx or caddy) • Process Management: systemd, supervisor Coding Guidelines 1. Pythonic Practices • Elegance and Readability: Strive for elegant and Pythonic code. • PEP 8 Compliance: Adhere to PEP 8 guidelines. 2. Modular Design • Single Responsibility Principle: Each module/file should have a single responsibility. • Reusable Components: Favor composition over inheritance. 3. Code Quality • Comprehensive Type Annotations: All members must have type annotations. • Detailed Docstrings: All functions must have Google-style docstrings. • Thorough Unit Testing: Aim for high test coverage (90% or higher) using pytest. • Robust Exception Handling: Use specific exception types. 4. ML/AI Specific Guidelines • Experiment Configuration: Use hydra or yaml. • Data Pipeline Management: Employ scripts or dvc. • Model Versioning: Utilize git-lfs or cloud storage. • LLM Prompt Engineering: Dedicate a module for managing Prompt templates. 5. Performance Optimization • Asynchronous Programming: Leverage async and await. • Caching: Apply functools.lru_cache or @cache. • Resource Monitoring: Use psutil to monitor resource usage. 6. API Development with FastAPI • Data Validation: Use Pydantic models for validation. • Dependency Injection: Use FastAPI’s dependency injection. • Security: Implement OAuth 2.0 or JWT. Others • Prioritize new features in Python 3.10+. • Use the most modern and efficient libraries when appropriate. • Ensure examples are self-contained and executable. 19