Papers
Topics
Authors
Recent
Search
2000 character limit reached

Self-Evolving Coding Agents via Harness-Policy Optimization

Published 16 Oct 2026 in cs.CL and cs.AI | (2610.22791v1)

Abstract: LLM agents have shown promising potential in coding tasks, and their performance is jointly determined by the policy model and the harness that mediates their interaction with the environment. Indeed, harness and policy are mutually reinforcing and evolving only one component is suboptimal---a harness tuned for one checkpoint may not target the failure modes of an updated policy, while policy learning remains limited to the trajectories elicited by a fixed harness. In light of this, we propose Self-HPO, a recursive self-improving framework for coding agents that alternates harness and policy optimization, using the evolving policy as its own harness proposer. Specifically, in each round, the current policy first analyzes its own failures and proposes new harness candidates (H-step). The policy is then updated through reinforcement learning (RL) under the selected harness (P-step), and hard tasks identified during training form the next harness search set, keeping harness optimization targeted to the policy's evolving failure modes. Across three coding benchmarks, Self-HPO consistently outperforms harness-only and policy-only baselines, improving Qwen3.5-35B-A3B's average resolve rate from 57.8% to 64.8%, with gains generalizing to out-of-distribution settings. Further analysis shows that both optimized components retain gains even when paired with their base counterparts, while their joint gain exceeds the sum of their individual gains. Self-HPO also improves reliability (Pass@1) and expands the capability frontier (Pass@k) over the base agent. Additionally, we show that with a stronger external model (e.g., Opus 4.8) as the harness proposer, the same framework yields a further performance boost.

Summary

  • The paper presents Self-HOPO, which optimizes both harness and policy, proving usefulness of a fixed harness.
  • Self-HPO results in a 7% increase in the average resolve rate across coding benchmarks compared to policy- and harness-only baselines.
  • Evolution of harness search set based on policy failures significantly affects the performance, demonstrating the mechanism's effectiveness beyond simple prompting

The paper studies coding agents as coupled systems rather than as LLMs operating under a fixed execution scaffold. Its central claim is that policy optimization and harness optimization are mutually dependent: a harness determines which behaviors a policy can express, while policy training changes the failure distribution that the harness should address. The proposed method, Self-Harness-Policy Optimization (Self-HPO), therefore alternates between optimizing the harness and optimizing the policy, with the evolving policy itself serving as the harness proposer (2610.22791).

Problem formulation

A coding agent is represented as a pair (H,P)(H,P), where PP is the LLM policy and HH controls the interaction protocol: context construction, shell-tool execution, feedback injection, submission handling, and termination. For a task xx, the pair generates a trajectory τ\tau that is evaluated by an executable verifier. The optimization objective is the expected binary resolve rate over a training distribution.

This formulation distinguishes two mechanisms that are often conflated. Policy optimization changes the model parameters but is constrained by the trajectories produced by the current harness. Harness optimization can alter prompts, runtime logic, feedback, or termination conditions, but cannot expand the model's intrinsic behavior unless those changes expose capabilities already latent in the policy. Optimizing either component in isolation is therefore potentially misaligned with the other.

Self-HPO addresses this coupling with alternating H-steps and P-steps:

  1. H-step: freeze the current policy, diagnose its failures, generate harness candidates, and retain the candidate with the highest resolve rate on a search set.
  2. P-step: freeze the selected harness and update the policy using RL with executable outcome rewards.
  3. Search-set update: identify tasks that remain unsolved across the P-step's rollouts and use them as the diagnostic set for the next H-step.

The method uses Qwen3.5-35B-A3B as the base policy and mini-SWE-agent as the seed harness. In the primary experiments, each H-step evaluates six candidates, each P-step performs 50 RL updates, and the full procedure runs for two alternating rounds.

Self-HPO algorithm

The H-step is failure-conditioned rather than a generic prompt search. The current policy receives trajectories from failed tasks and proposes a modification to the current best harness. Candidate modifications may change either language-level instructions or executable control logic. All candidates are evaluated on the same search set, and the best candidate is retained.

The search set is initially a random subset of 300 training tasks. After the first P-step, it is replaced by tasks that were never resolved in any rollout during policy training. This design makes the harness optimizer track the policy's evolving failure modes rather than repeatedly optimizing against a static diagnostic sample.

The P-step uses GRPO with Balanced Adaptive Rollout. BAR samples additional rollouts until it can construct reward-balanced groups, mitigating the zero-variance groups that arise when all sampled trajectories receive reward zero. The policy is trained under the optimized harness, and the resulting hard-task set becomes both a source of failure evidence and a targeting mechanism for the next H-step.

The recursive structure is important: after policy training, the updated policy is not merely a better solver; it is also the next harness proposer. Thus, policy optimization changes both the task-solving distribution and the mechanism used to modify the harness.

Figure 1

Figure 1: Self-HPO alternates failure-conditioned harness search with RL policy optimization and uses unresolved training tasks to define the next search set.

Experimental design

The evaluation uses 2,484 training tasks assembled from SWE-rebench, SWE-rebench V2, and Scale-SWE. Performance is measured by resolve rate on three benchmarks:

The self-improving comparison includes the base agent, RLVR, which optimizes only the policy, and Self-Harness, which optimizes only the harness. A second setup uses Opus 4.8 as an external harness proposer and compares SFT, Meta-Harness, and HPO. Results are averages over three evaluation runs.

Main results

Self-HPO consistently outperforms both single-component baselines. In the self-proposer setting, the average resolve rate rises from 57.8% for the base agent to 64.8% with Self-HPO. On SWE-Bench Verified, Self-HPO reaches 69.5%, compared with 67.5% for RLVR and 65.2% for Self-Harness.

Method SWE-Verified SWE-Multi SWE-Pro Average
Base 61.0% 54.2% 58.3% 57.8%
RLVR 67.5% 56.3% 61.8% 61.9%
Self-Harness 65.2% 54.3% 60.7% 60.1%
Self-HPO 69.5% 59.7% 65.2% 64.8%
HPO with Opus 4.8 proposer 71.6% 61.4% 66.0% 66.3%

The gains transfer beyond the Python-heavy training distribution. Relative to the base agent, Self-HPO improves SWE-Bench Multilingual by 5.5 percentage points and SWE-Bench Pro by 6.9 points. On SWE-Multi, Self-Harness improves over the base by only 0.1 point, whereas Self-HPO improves by 5.5 points. This contrast indicates that policy adaptation is necessary for the harness improvements to generalize across programming languages and repository distributions.

The external-proposer experiment establishes a stronger but more expensive variant. HPO with Opus 4.8 reaches 71.6% on SWE-Bench Verified and 66.3% on average, exceeding Self-HPO by 2.1 and 1.5 points, respectively. The result shows that external proposal quality remains relevant, but the self-proposer is not required for the alternating optimization principle to be effective.

Figure 2

Figure 2: Alternating harness and policy updates produce continued improvements, whereas harness-only or policy-only optimization saturates earlier.

The optimization trajectories support the proposed mechanism. Self-HPO and Self-Harness share the first harness update and reach the same intermediate performance. After Self-HPO updates the policy, its second harness search starts from a stronger policy and produces further gains. By contrast, an additional harness-only update can reduce performance; on SWE-Multi, Self-Harness falls from 55.0% to 54.3%. The implication is that harness search is not monotonically beneficial when its solver remains fixed.

Ablation results

The ablations isolate three design choices.

First, RL is more effective than supervised alternatives in the P-step. Replacing RL with SFT reduces the HPO result on SWE-Bench Verified from 71.6% to 67.2%, a 4.4-point decline. Replacing RL with rejection-sampling fine-tuning yields 70.5%, still 1.1 points below RL. The difference supports the use of online policy optimization under the harness rather than merely distilling successful trajectories.

Second, evolving the harness search set matters. Keeping the initial search set fixed reduces performance from 71.6% to 70.1%. The result directly supports the paper's assumption that the most informative failures change as the policy improves. It also indicates that failure-driven task selection contributes independently of the H-step/P-step alternation.

Third, the self-proposer incurs a measurable cost relative to Opus 4.8. Substituting the current policy for the external proposer lowers the Verified score by 2.1 points. Nevertheless, the self-proposer result remains above both single-component baselines, demonstrating that the method does not depend on a separately trained or proprietary proposer.

Complementarity of harness and policy improvements

The paper's factorized evaluation combines intermediate harnesses and policies in all pairings. The base pair (H0,P0)(H_0,P_0) obtains 61.0% on SWE-Bench Verified. Applying the optimized harness H2H_2 to the base policy raises performance to 64.5%, while applying the final policy P2P_2 to the seed harness raises it to 64.4%. The full pair (H2,P2)(H_2,P_2) reaches 69.5%.

Consequently, the joint gain is 8.5 points, whereas the isolated gains sum to only 6.9 points. The combined improvement exceeds the additive sum of the individual improvements by 1.6 points. This is evidence of interaction rather than simple accumulation: the policy benefits from behaviors elicited by the optimized harness, and the optimized harness remains effective because it is adapted to the policy's updated capabilities.

The result also weakens a possible interpretation of Self-HPO as merely policy RL with incidental prompt engineering. Both components retain transfer value when paired with their base counterparts, and their strongest performance occurs only when they are co-adapted.

Reliability and capability frontier

The analysis evaluates eight samples per task to distinguish first-sample reliability from the broader probability that at least one attempt succeeds. Self-HPO improves pass@1 at every reported sampling budget and raises pass@8 from 80.0% to 84.8%, a 4.8-point increase.

Figure 3

Figure 3

Figure 3

Figure 3: Self-HPO remains above the base agent across sampling budgets from pass@1 through pass@8.

The pass@1 breakdown is nonuniform. Relative to the base agent, Self-HPO improves Medium tasks by 17.2 points, Easy tasks by 12.9 points, and Hard tasks by 6.1 points. However, performance on tasks already resolved by the base agent declines by 2.2 points. The method therefore improves consistency on partially solved tasks and expands performance on difficult tasks, but does not dominate uniformly on every task stratum.

This distinction is important. The increase in pass@8 suggests that Self-HPO expands the set of tasks for which the policy can produce a successful solution under repeated sampling. The pass@1 improvements on Medium and Easy tasks indicate greater reliability. The decline on the Resolved category shows that the optimization may introduce regressions even while improving aggregate performance.

During the final P-step, the fraction of zero-success rollout groups falls to 6.5% over the last ten updates, compared with roughly 11–17% for the final 50 updates of RLVR. Under binary rewards, a zero-success group supplies no within-group contrast for GRPO. The optimized harness therefore appears to improve policy learning partly by making successful trajectories more observable to the RL procedure, not solely by directly increasing evaluation-time success.

Harness evolution and intervention mechanisms

The evolved harness does not replace the seed agent's core ReAct loop. It subclasses the seed implementation and overrides the step function with four targeted interventions:

  • A budget valve warns the policy near the step or time limit and requests a focused best-effort submission.
  • An empty-patch guard rejects a submission with no diff and gives the policy another turn.
  • A contract-grounding intervention delays the first valid-looking submission to prompt verification of API names, signatures, and repository conventions.
  • A patch fallback replaces a malformed submission with the sandbox's Git diff when the diff fails an apply check.

These interventions target failures in execution and submission rather than requiring new domain knowledge. In the qualitative case study, the final policy edits the correct Sphinx source file and passes the relevant tests under both harnesses. Under the seed harness, it submits a prose summary instead of a patch, producing no evaluated code change. Under the evolved harness, the empty submission is intercepted; the policy then generates and submits the Git diff, resolving the task.

Figure 4

Figure 4: Harness evolution improves the best-so-far score by adding targeted submission and execution controls around the existing agent loop.

The case study provides a concrete interpretation of the aggregate gains: the harness can convert an already successful internal trajectory into a valid benchmark submission. It does not establish that every improvement has this character, but it demonstrates how runtime intervention can recover failures that policy-only training may not reliably eliminate.

Limitations and open questions

The experiments use one base model, one seed harness, one primary coding-agent architecture, and two optimization rounds. The conclusions therefore do not establish that the same schedule, candidate budget, or RL configuration is optimal for other policies or environments. Harness search is also evaluated through a small candidate budget of six candidates per H-step, and each candidate is evaluated once on the search set, leaving sensitivity to search noise insufficiently characterized.

The method assumes that executable binary verifiers provide an adequate training signal. This assumption is reasonable for SWE-Bench-style patch validation but does not address tasks with incomplete tests, nondeterministic environments, or semantic regressions not captured by the verifier. The search-set rule also defines hardness as failure in every rollout during a P-step; this may conflate genuine capability gaps with sampling failures or harness-induced failures.

The external-proposer comparison shows that a stronger model improves results, so the self-proposer should not be interpreted as equivalent to external harness engineering. The paper also reports an aggregate improvement despite a 2.2-point regression on base-resolved tasks. Open questions include whether search-set selection can be made robust to noisy difficulty estimates, how co-evolution behaves over substantially more rounds, and whether the observed component complementarity persists under independent task distributions and stronger policy baselines.

Conclusion

Self-HPO presents harness and policy optimization as an alternating, failure-conditioned process. The evolving policy proposes harness revisions, learns through RL under the selected harness, and identifies the hard tasks that guide the next search round. On three coding benchmarks, the method raises average resolve rate from 57.8% to 64.8% and outperforms both harness-only and policy-only optimization, with gains transferring to multilingual and broader repository-level tasks. Its strongest evidence concerns complementarity: optimized harnesses and policies each retain independent value, while their combination produces a super-additive improvement. The results establish recursive harness-policy co-adaptation as a practical design axis for coding agents, subject to the stated dependence on verifiable rewards, task-selection quality, and the limited experimental scale.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Explain it Like I'm 14

1. ¿De qué trata el artículo?

El artículo presenta un método llamado Self-HPO, diseñado para mejorar agentes de inteligencia artificial que programan.

Un agente de programación tiene dos partes principales:

  • El modelo o “política”: el cerebro que lee el problema, escribe código y decide qué hacer.
  • El “arnés” o *harness*: el sistema que rodea al modelo. Decide qué información recibe, qué herramientas puede usar, cómo se ejecutan sus comandos, qué errores se le muestran y cuándo termina el intento.

Los autores dicen que mejorar solo una de estas partes no es suficiente. Por eso, Self-HPO mejora el modelo y el arnés al mismo tiempo, en varias rondas.

Una comparación sencilla sería esta: el modelo es como un estudiante que resuelve problemas y el arnés es como su profesor, sus instrucciones, sus herramientas y las reglas del examen. Para obtener mejores resultados, hay que mejorar tanto al estudiante como al entorno en el que trabaja.

2. ¿Qué preguntas intenta responder?

El estudio busca saber principalmente:

  1. ¿Es mejor mejorar el modelo y el arnés juntos que mejorar solo uno de ellos?
  2. ¿Puede el propio modelo descubrir por qué falla y proponer cambios útiles en su arnés?
  3. ¿Puede este sistema seguir mejorando cuando los problemas difíciles cambian?
  4. ¿Las mejoras funcionan también en tareas y lenguajes de programación diferentes de los usados durante el entrenamiento?
  5. ¿El agente se vuelve más confiable, es decir, tiene más probabilidades de acertar en un solo intento?

3. ¿Cómo realizaron la investigación?

El ciclo Self-HPO

Self-HPO funciona mediante dos pasos que se repiten.

Paso H: mejorar el arnés

Primero, el modelo revisa algunos problemas que no pudo resolver. Examina sus errores y propone cambios en el arnés.

Por ejemplo, podría descubrir que:

  • entrega un parche vacío;
  • olvida incluir archivos nuevos;
  • se queda sin tiempo antes de enviar una respuesta;
  • usa nombres de funciones que no existen;
  • produce un cambio de código que no se puede aplicar correctamente.

Después, se prueban varias versiones nuevas del arnés. Se conserva la versión que resuelve más problemas.

Paso P: mejorar el modelo

Luego, se mantiene fijo el nuevo arnés y se entrena el modelo para que programe mejor.

Para ello usan aprendizaje por refuerzo. Esto significa que el modelo intenta resolver problemas y recibe una recompensa cuando su solución funciona. Si el código pasa las pruebas automáticas, obtiene una señal positiva; si falla, no la obtiene.

Es parecido a entrenar a alguien con ejercicios: cada respuesta correcta indica qué estrategias conviene repetir.

Elegir nuevos problemas difíciles

Después del entrenamiento, los investigadores buscan los problemas que el agente todavía no pudo resolver. Esos problemas se convierten en el objetivo de la siguiente ronda de mejora del arnés.

Así, el proceso sigue este ciclo:

  1. El agente estudia sus fallos.
  2. Propone un arnés mejor.
  3. Aprende con ese arnés.
  4. Se identifican sus nuevos problemas difíciles.
  5. El ciclo comienza de nuevo.

Modelos y pruebas utilizadas

Los autores usaron:

  • Qwen3.5-35B-A3B como modelo de programación.
  • mini-SWE-agent como arnés inicial.
  • 2.484 tareas de programación para entrenar y mejorar el sistema.

Evaluaron el método en tres pruebas:

Prueba Qué mide
SWE-Bench Verified Problemas reales de GitHub revisados por personas
SWE-Bench Multilingual Problemas en varios lenguajes de programación
SWE-Bench Pro Tareas de programación más largas y variadas

La medida principal fue la tasa de resolución: el porcentaje de problemas cuya solución pasa correctamente las pruebas automáticas.

También usaron:

  • pass@1: probabilidad de resolver el problema en un solo intento.
  • pass@k: probabilidad de resolverlo teniendo hasta k intentos.

4. ¿Cuáles fueron los resultados principales?

Mejoró más que los métodos que solo cambian una parte

El sistema inicial obtuvo una tasa media de resolución del 57,8 % en las tres pruebas.

Después de aplicar Self-HPO, la tasa subió al 64,8 %.

En la prueba principal, SWE-Bench Verified, los resultados fueron:

Método Tasa de resolución
Sistema inicial 61,0 %
Mejorar solo el modelo 67,5 %
Mejorar solo el arnés 65,2 %
Self-HPO: mejorar ambos 69,5 %

Esto muestra que combinar las dos mejoras fue más eficaz que usar cualquiera por separado.

Las mejoras también funcionaron fuera del entrenamiento

El sistema fue entrenado principalmente con tareas de proyectos en Python. Sin embargo, también mejoró en pruebas con otros lenguajes y tipos de problemas.

Self-HPO obtuvo:

  • 59,7 % en SWE-Bench Multilingual.
  • 65,2 % en SWE-Bench Pro.

Esto es importante porque significa que no solo memorizó soluciones para los problemas de entrenamiento. Aprendió estrategias que podían servir en situaciones nuevas.

El arnés aprendió a evitar errores concretos

Una versión mejorada del arnés añadió controles como:

  • avisar al modelo cuando quedaba poco tiempo;
  • impedir que enviara un parche vacío;
  • recordarle que comprobara los nombres de las funciones y las reglas del programa;
  • usar automáticamente la diferencia real de cambios del repositorio si el parche enviado era incorrecto.

Estos cambios no hicieron que el modelo fuera más inteligente directamente. Más bien, ayudaron a que usara mejor sus capacidades y evitara errores de procedimiento.

El modelo y el arnés se ayudan mutuamente

Los investigadores probaron cada componente por separado:

  • El arnés mejorado funcionó mejor incluso con el modelo original.
  • El modelo mejorado funcionó mejor incluso con el arnés original.
  • Cuando se combinaron ambos, el resultado fue todavía mejor.

La mejora conjunta fue incluso mayor que la suma de las mejoras individuales. Esto sugiere que el modelo y el arnés se complementan.

Un modelo externo más fuerte ayudó aún más

Los autores también probaron usar un modelo externo más potente, Opus 4.8, para proponer cambios en el arnés.

Con esta ayuda, el sistema llegó a:

  • 71,6 % en SWE-Bench Verified.
  • 66,3 % de promedio en las tres pruebas.

Esto indica que Self-HPO puede funcionar sin un modelo externo, pero un modelo más fuerte puede producir mejoras adicionales.

Mejoró la confiabilidad

Self-HPO no solo aumentó la posibilidad de resolver un problema después de varios intentos. También mejoró la posibilidad de acertar en el primer intento.

Con hasta ocho intentos, la tasa pass@8 subió de 80,0 % a 84,8 %.

El mayor progreso apareció en problemas de dificultad media y en algunos problemas difíciles, aunque el rendimiento no mejoró en absolutamente todos los tipos de tareas.

5. ¿Por qué son importantes estos resultados?

El trabajo muestra que un agente de inteligencia artificial no debe verse solo como un modelo de lenguaje. También importa mucho el sistema que lo guía y conecta con el mundo real.

Un modelo puede tener buenas capacidades, pero fallar porque:

  • recibe instrucciones poco claras;
  • no ve información importante;
  • usa mal las herramientas;
  • termina demasiado pronto;
  • envía una solución con un formato incorrecto.

Self-HPO intenta resolver estos problemas de manera continua. El agente aprende de sus errores y modifica tanto sus propias habilidades como las reglas y herramientas que lo rodean.

6. Posibles consecuencias e impacto

Si este enfoque funciona en sistemas más grandes, podría ayudar a crear agentes capaces de:

  • reparar programas con menos supervisión humana;
  • adaptarse a nuevos tipos de proyectos;
  • aprender de errores concretos en lugar de repetirlos;
  • trabajar con diferentes lenguajes de programación;
  • ser más confiables en tareas largas y complicadas.

También podría usarse en otros agentes de inteligencia artificial, como sistemas que navegan por internet, manejan computadoras o utilizan herramientas científicas.

Sin embargo, el método no hace que el agente sea perfecto. Todavía existen fallos, y las pruebas se centran principalmente en programación. Además, entrenar y evaluar estos sistemas requiere muchos recursos informáticos.

Conclusión

El artículo propone una idea central: para mejorar un agente de programación, hay que mejorar tanto su “cerebro” como el sistema que lo guía.

Self-HPO alterna entre:

  1. mejorar el arnés usando los errores del agente;
  2. entrenar el modelo con ese arnés mejorado;
  3. volver a buscar los nuevos errores difíciles.

Los experimentos muestran que esta combinación supera a los métodos que solo mejoran el modelo o solo mejoran el arnés. En resumen, el estudio presenta una forma de hacer que los agentes de programación se adapten y mejoren de manera más continua, usando sus propios fallos como guía.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

The paper leaves the following issues unresolved:

  • Limited model diversity: Experiments use only Qwen3.5-35B-A3B as the trainable policy, so it is unclear whether Self-HPO works for smaller, larger, dense, non-Qwen, or closed-weight models.
  • Limited harness diversity: The method is initialized only from mini-SWE-agent; its effectiveness with substantially different harness architectures, tool interfaces, memory systems, or multi-agent workflows is not established.
  • Unclear contribution of individual harness changes: The paper reports a final harness containing several interventions—budget warnings, empty-patch checks, contract grounding, and patch fallback—but does not isolate their individual effects or test whether the same gains arise from simpler manually designed rules.
  • Small number of optimization rounds: The experiments use only two H/P rounds. It remains unknown whether performance continues improving, plateaus, oscillates, or degrades over many rounds.
  • Unspecified convergence behavior: The stopping criterion is based on hard-task-set stabilization, but the paper does not analyze how often this criterion is reached, whether stabilization reflects genuine convergence, or whether alternative stopping rules produce different results.
  • Sensitivity to the harness-search budget: Only K=6K=6 candidates per H-step is used. The relationship between search budget, performance, computational cost, and diminishing returns is not characterized.
  • Sensitivity to search-set size and composition: The effects of the initial set size, hard-task-set size, task sampling randomness, and thresholds for defining a task as “hard” are not systematically evaluated.
  • Potential selection bias from hard-task mining: The next search set contains tasks with no successful rollout during policy training, which may overemphasize frequently sampled or intrinsically difficult tasks and neglect tasks that are nearly solved or suffer from different failure modes.
  • No comparison with alternative curricula: The evolving hard-task set is compared only with a fixed search set. Comparisons with random refreshes, diversity-based sampling, uncertainty sampling, loss-based curricula, or strategically mixed easy/hard sets are absent.
  • Training–evaluation overlap risks: The training data are assembled from SWE-rebench, SWE-rebench V2, and Scale-SWE, while evaluation uses related SWE-Bench collections. The paper does not establish that repository histories, issues, patches, or near-duplicate tasks do not overlap across training and evaluation.
  • Narrow training-domain coverage: Policy and harness optimization are conducted on Python projects, and the extent to which the reported multilingual gains reflect genuine cross-language transfer rather than shared task or repository properties is unclear.
  • Incomplete out-of-distribution evaluation: Generalization is tested on only two additional SWE-Bench variants. Transfer to private repositories, newly released issues, non-GitHub codebases, security bugs, documentation tasks, or non-software-engineering agent tasks remains unexplored.
  • Verifier dependence: Results rely on binary executable verifiers and resolve rates. The method’s behavior under incomplete, flaky, weak, or adversarial tests—and its effect on patch quality beyond passing tests—is not evaluated.
  • No assessment of patch correctness beyond benchmark tests: Passing the benchmark verifier may not imply maintainability, readability, absence of regressions, or alignment with the intended issue requirements. Human review and broader software-quality metrics are missing.
  • Unclear robustness to reward hacking: Because the policy is optimized against executable outcomes and the harness can alter submission behavior, the paper does not test whether the agent learns brittle verifier-specific strategies or exploits weaknesses in the evaluation environment.
  • Incomplete causal analysis of joint gains: The reported super-additive improvement of the final harness and policy is based on one cross-evaluation table. It does not establish whether the interaction is causal, whether it persists across random seeds and intermediate checkpoints, or which specific harness-policy interactions produce it.
  • Limited baseline coverage: The comparisons omit potentially relevant alternatives such as jointly trained prompt-and-policy methods, multi-harness ensembles, adaptive tool selection, curriculum-based RL, stronger self-improvement systems, and optimized harnesses with multiple independent proposer models.
  • Baseline comparability is not fully demonstrated: The paper does not provide enough detail to verify that all baselines receive equivalent compute, rollout counts, training data, evaluation opportunities, and access to intermediate trajectories.
  • External-proposer comparison is confounded by model strength: The difference between Self-HPO and HPO may reflect the capability gap between Qwen3.5-35B-A3B and Opus 4.8 rather than the value of external proposal itself. Comparisons using matched-capability proposer models are needed.
  • Policy-proposer reliability is not measured: The paper shows that the self-proposer underperforms Opus 4.8 by 2.1 points, but does not analyze proposal quality, failure diagnosis accuracy, edit validity, or how often proposed harness changes are harmful, redundant, or rejected.
  • No study of proposer specialization: It remains unknown whether using a separate policy checkpoint, an ensemble of proposer policies, or a proposer trained specifically for harness editing would outperform reusing the task-solving policy.
  • Training stability is underreported: The paper provides aggregate results over three runs but does not report seed-level trajectories, catastrophic regressions, failed harness edits, policy collapse, or variance across optimization rounds.
  • Insufficient statistical testing: Mean and standard deviation over three evaluation runs are reported, but confidence intervals, significance tests, paired task-level comparisons, and effect sizes are not provided.
  • Compute and latency costs are not quantified: The paper does not report total training FLOPs, number of rollouts, wall-clock time, inference calls, memory use, or the cost of repeated harness evaluation relative to the performance gains.
  • Deployment overhead is unclear: Runtime checks, repeated submissions, fallback logic, and injected messages may increase execution time or tool calls, but their operational overhead and failure impact are not measured.
  • No analysis of harness complexity: The method can modify executable runtime logic, yet the paper does not quantify code size, maintainability, interpretability, test coverage, or the risk that successive evolution introduces hidden dependencies and brittle behavior.
  • Safety and security are unexamined: Self-modifying harnesses may weaken sandbox boundaries, expose sensitive repository information, alter termination safeguards, or introduce unsafe tool behavior. No security audit or constraint mechanism is reported.
  • Dependence on a fixed sandbox and tool protocol: It is unclear whether the evolved harness remains effective when tools, operating systems, repository layouts, time limits, or sandbox implementations change.
  • Limited analysis of failure modes: The qualitative case study focuses on submission and patch-format failures. The method’s effect on reasoning errors, incorrect API assumptions, test interpretation, planning failures, and long-horizon debugging is not systematically analyzed.
  • No evidence that policy learning internalizes harness improvements: The paper argues that the policy “internalizes” elicited behaviors, but does not compare learned representations, behavior under harness removal, or transfer to unseen harnesses in enough depth to establish this claim.
  • Unclear persistence of improvements after continued base-model training: The study evaluates only the final checkpoints and harnesses; it does not investigate whether gains survive further fine-tuning, model updates, quantization, or policy distillation.
  • Pass@kk analysis is narrow: The capability-frontier analysis uses eight attempts on SWE-Bench Verified only. It does not examine how gains scale with larger kk, whether attempts are genuinely diverse, or whether additional sampling merely increases compute.
  • No evaluation of robustness under constrained inference budgets: Since the harness explicitly manages step and time limits, performance under different token, action, latency, and tool-call budgets remains unknown.
  • Potential benchmark saturation is not addressed: The reported gains may depend on current SWE-Bench task distributions and harness conventions; performance on newly collected, contamination-resistant, or independently authored software-engineering tasks is needed.
  • General principles for harness evolution remain unspecified: The paper demonstrates a successful procedure but does not derive which classes of harness edits are broadly useful, when self-proposal is sufficient, or how to predict whether a proposed change will transfer across tasks and environments.

Practical Applications

Immediate Applications

  • Automated software maintenance and pull-request generation — Industry / Software
    • Deploy Self-HPO-style coding agents in CI/CD systems to diagnose GitHub issues, generate patches, run tests, and submit pull requests.
    • The optimized harness can be implemented immediately using runtime controls demonstrated in the paper: warnings near token, time, or step limits; empty-patch detection; API and test-contract checks; patch-application validation; and Git-diff fallback.
    • These safeguards target practical failure modes in which an agent performs useful edits but submits an empty, malformed, incomplete, or unstaged patch.
    • Dependencies: access to executable tests and repository sandboxes; reliable patch verification; strict permission isolation; human review for security-sensitive or production changes. The reported benchmark gains may not directly translate to proprietary repositories or unfamiliar build systems.
  • Reliability layer for existing coding agents — Industry / Software
    • Apply the evolved harness independently to an existing base policy without retraining the model. The cross-evaluation results show that the optimized harness improved the base policy from approximately 61.0% to 64.5% on SWE-Bench Verified.
    • This supports a drop-in “agent reliability middleware” product that wraps coding agents with submission validation, budget management, contract grounding, and recovery behavior.
    • Dependencies: compatibility between the harness and the agent’s tool APIs, repository conventions, and submission format. Harness rules must be tested to ensure that additional checks do not unnecessarily interrupt valid workflows.
  • Policy-only model improvement under an existing agent interface — Industry / Model development
    • Organizations can reuse the P-step independently: collect on-policy coding trajectories, score them with executable tests, and apply verifiable-reward reinforcement learning such as GRPO with balanced rollout sampling.
    • This is useful when the existing harness is stable but the model requires better consistency on medium-difficulty or recurring engineering tasks.
    • Dependencies: substantial GPU and rollout infrastructure; high-quality executable verifiers; sufficiently diverse training repositories; safeguards against reward hacking and overfitting to benchmark tests.
  • Failure-driven debugging of agent workflows — Industry / MLOps
    • Log unsuccessful trajectories, classify persistent failures, and use them to prioritize improvements to prompts, tool routing, termination conditions, and recovery logic.
    • The paper’s evolving hard-task set provides a concrete workflow: after every policy update, identify tasks never solved in any rollout and use them as the next harness-search set.
    • This can produce an observability dashboard showing failure categories such as timeout, empty patch, invalid API use, failed patch application, or premature termination.
    • Dependencies: accurate failure logging and reproducible evaluations. “Unsolved” must be distinguished from infrastructure failures, flaky tests, and insufficient task permissions.
  • Automated regression testing for agent versions — Industry / Software quality
    • Maintain a dynamic suite of difficult repository-level tasks as a regression benchmark for each change to the policy, harness, tools, or model provider.
    • The paper suggests evaluating the full harness–policy pair rather than testing the model alone, because improvements can depend on their interaction.
    • Dependencies: stable task snapshots, deterministic or statistically controlled evaluation, and protection against optimizing only for the internal regression set.
  • Benchmarking and research infrastructure for agent co-optimization — Academia
    • Use the open-source implementation and released models or checkpoints to reproduce alternating harness and policy optimization.
    • Researchers can compare policy-only, harness-only, and joint optimization using metrics such as resolve rate, pass@1, pass@k, cross-component transfer, and out-of-distribution performance.
    • The factorized evaluation in the paper provides a practical experimental design: test optimized and base policies crossed with optimized and base harnesses.
    • Dependencies: availability of the referenced model versions, sufficient compute, executable benchmark environments, and careful handling of benchmark contamination.
  • Domain-specific coding assistants for organizations — Industry / Enterprise IT
    • Adapt the method to internal repositories, coding standards, test suites, and deployment policies. The harness can enforce organization-specific requirements such as mandatory tests, license checks, security scans, code-owner approval, and changelog generation.
    • The policy can be trained on verified internal tasks while the harness adapts to recurring organizational failure modes.
    • Dependencies: permission to use internal code for training, privacy controls, secure execution, representative task data, and human approval before code reaches production.
  • Practical developer workflow assistance — Daily work
    • Developers can use an agent that automatically checks whether new files are tracked, validates API signatures against tests, warns when the execution budget is nearly exhausted, and preserves the final Git diff as a fallback.
    • This is particularly useful for issue triage, test repair, dependency upgrades, and small refactoring tasks where incomplete submissions are common.
    • Dependencies: local repository access, sandboxed command execution, and transparent presentation of agent actions so developers can verify changes.
  • Policy guidance for procurement and deployment — Policy / Organizational governance
    • Treat agent performance as a property of the complete system—model, prompt, tools, runtime, verifier, and termination policy—rather than as a property of the model checkpoint alone.
    • Procurement evaluations can therefore require reproducible testing of the deployed harness–policy configuration, including out-of-distribution repositories and reliability metrics.
    • Dependencies: standardized evaluation protocols and disclosure of harness changes. Vendor-reported model scores may not be comparable if interfaces or tool environments differ.

Long-Term Applications

  • Self-improving general-purpose computer-use agents — Software / Robotics / Automation
    • Extend Self-HPO beyond coding to web navigation, desktop automation, IT operations, and robotic control. The analogous harness would manage observations, tool calls, action execution, feedback, recovery, and episode termination.
    • Hard tasks identified during reinforcement learning could drive future improvements to the agent’s interaction protocol, action validators, and recovery routines.
    • Dependencies: reliable task verifiers for non-coding environments, safe action execution, simulation or sandboxing, and mechanisms to prevent self-modification from bypassing safety constraints. Coding tasks benefit from strong binary tests; many real-world tasks lack equivalent verifiers.
  • Adaptive software-engineering agents across programming languages — Industry / Software
    • Build multilingual or language-agnostic coding agents whose harness learns language-specific checks, build commands, test conventions, and repository structures.
    • The reported transfer from Python training tasks to SWE-Bench Multilingual and SWE-Bench Pro suggests that some workflow improvements may generalize beyond the training language.
    • Dependencies: broader validation across languages, repositories, build systems, and long-horizon tasks. The observed transfer does not establish universal language independence.
  • Continuous-learning enterprise coding platforms — Industry / MLOps
    • Operate a persistent feedback loop in which production failures, rejected pull requests, flaky tests, and human corrections become new hard-task candidates for harness and policy updates.
    • A future platform could automatically propose harness revisions, evaluate them in isolated environments, train a new policy version, and promote only configurations that pass safety and quality gates.
    • Dependencies: prevention of catastrophic forgetting, versioned data and harnesses, rollback mechanisms, drift detection, secure continual-learning pipelines, and governance over automated model updates.
  • Agent capability marketplaces and modular harness libraries — Industry / Software ecosystem
    • Package harness improvements as reusable modules: budget management, patch validation, test-contract grounding, repository navigation, security scanning, or domain-specific deployment checks.
    • Since the study shows that the optimized harness and policy each retain benefits when paired with their base counterpart, organizations could upgrade either component independently before adopting the complete pair.
    • Dependencies: stable interfaces between policies and harnesses, compatibility testing, composability, and protection against conflicting runtime interventions.
  • Automated curriculum generation for reinforcement learning — Academia / Education technology
    • Use persistent failures to construct curricula that focus training on tasks at the frontier of current competence rather than repeatedly sampling already-solved examples.
    • In education technology, the same principle could support adaptive tutoring agents that identify concepts a learner repeatedly misses and modify both instructional strategy and underlying response policy.
    • Dependencies: domain-appropriate verifiers or teacher judgments, protection against narrow curriculum overfitting, and validated learning outcomes. The paper directly evaluates coding tasks, not human learning.
  • Safety-oriented co-evolution of agent policies and interfaces — Policy / AI safety
    • Adapt the alternating framework to optimize not only task success but also safety constraints: permission boundaries, confirmation requirements, audit logs, sensitive-data handling, and refusal behavior.
    • Harness proposals could be required to pass adversarial tests before deployment, while policy training could use explicit penalties for unsafe actions.
    • Dependencies: formally specified safety objectives, independent evaluators, red-team data, immutable safeguards, and separation between the component proposing changes and the component approving them. Self-proposal alone should not be treated as a safety guarantee.
  • Autonomous incident response and infrastructure repair — Industry / Cloud / Cybersecurity
    • Apply the approach to agents that diagnose failing services, propose configuration or code repairs, run tests in replicas, and prepare staged remediation plans.
    • Harness evolution could learn when to request additional logs, halt before risky commands, roll back changes, or escalate to an operator.
    • Dependencies: high-fidelity staging environments, robust observability, strict least-privilege access, rollback support, and verifiers that measure service recovery without introducing security regressions.
  • Long-horizon robotics and embodied agents — Robotics
    • A robotic agent could co-evolve its action policy and execution harness, including sensor-selection logic, planning horizons, failure recovery, and termination conditions.
    • Hard-task mining could focus later training on situations involving manipulation errors, occlusion, unexpected object states, or limited battery.
    • Dependencies: realistic simulators and physical validation, safety-certified action constraints, expensive data collection, sim-to-real transfer, and reliable reward signals. The binary software verifier used in the paper is not directly available in most physical environments.
  • Regulated-domain decision-support agents — Healthcare, finance, and public administration
    • Develop agents whose harness enforces evidence retrieval, source citation, confidence thresholds, audit trails, human approval, and refusal or escalation rules, while policy optimization improves performance on verified domain tasks.
    • In healthcare, examples include code and documentation assistance rather than autonomous diagnosis; in finance, examples include compliance review or reconciliation workflows rather than unsupervised trading.
    • Dependencies: domain-expert validation, privacy and security compliance, calibrated uncertainty, liability allocation, representative data, and legally approved evaluation procedures. Benchmark resolve rates alone are insufficient for safety-critical deployment.

Glossary

  • Ablation: An experiment that removes or replaces a component to measure its effect. “We examine the policy-update strategy, search-set construction, and harness proposer on SWE-Verified.”
  • Agent harness: External software that controls an agent’s context, tools, feedback, execution, and termination. “The harness is the external scaffold that decides what the model observes, how its actions are executed, what feedback it receives, and when an episode terminates”
  • Balanced Adaptive Rollout (BAR): A method that adaptively samples additional trajectories to create groups with informative reward variation. “BAR adaptively draws additional trajectories to construct reward-balanced groups”
  • Capability frontier: The range of task-solving performance accessible when multiple attempts or increasing computational effort are allowed. “Self-HPO improves reliability (pass@1) and expands the capability frontier (pass@kk).”
  • Checkpoint: A saved version of a model’s parameters at a particular point during training. “a harness tuned for one checkpoint may not target the failure modes of an updated policy”
  • Contract grounding: Verifying that generated code conforms to the APIs, interfaces, and behavioral requirements of a software repository. “contract grounding: first submit past the empty guard”
  • Distillation: Training one model to reproduce behaviors or outputs generated by another, usually stronger, model. “SFT distills generated trajectories into the model weights”
  • Executable verifier: A program that automatically checks whether an agent’s output satisfies a task’s correctness criteria. “The resulting trajectory τ∼πH,P(⋅∣x)\tau\sim\pi_{H,P}(\cdot\mid x) is scored by an executable verifier y(x,τ)∈{0,1}y(x,\tau)\in\{0,1\}.”
  • Harness optimization: Searching for improved prompts, workflows, or executable control logic while evaluating an agent. “Harness optimization holds the policy fixed and searches over prompts, workflows, or agent code”
  • Harness-policy pair: The combination of an agent’s policy model and its external harness. “We measure a harness--policy pair by its expected resolve rate on the training data D\mathcal{D}”
  • Hard-task set: Tasks that remain unresolved across all relevant agent rollouts. “The tasks that were never resolved during this P-step are identified as the hard-task set St+1\mathcal{S}_{t+1}”
  • In-distribution: Belonging to the same data or task distribution used for training or optimization. “Main results on in-distribution (SWE-Bench Verified) and out-of-distribution evaluations”
  • On-policy trajectory: A sequence of actions and observations generated by the policy currently being trained. “Starting from PtP_t, we collect on-policy trajectories over D\mathcal{D} as the policy is updated.”
  • Out-of-distribution (OOD): Data or tasks that differ from the distribution used during training. “with gains generalizing to out-of-distribution settings.”
  • Pass@k: The probability that at least one of up to kk generated attempts solves a task. “Self-HPO remains above Base for every kk from 1 to 8”
  • Pass@1: The success rate when only one generated attempt is evaluated. “Self-HPO improves reliability (pass@1)”
  • Policy model: The model that selects an agent’s actions given its observations and task context. “the policy model defines the agent's capability boundary”
  • Prompt optimization: The systematic modification of instructions supplied to a model to improve its performance. “Harness optimization spans prompts and programs”
  • Reinforcement learning (RL): Training through rewards obtained from interacting with an environment or evaluator. “The P-step improves the policy through reinforcement learning under the optimized harness Ht+1H_{t+1}.”
  • Rejection-sampling fine-tuning (RFT): Fine-tuning on generated examples retained only when they meet a desired success criterion. “rejection-sampling fine-tuning (RFT) on the target policy's own successful trajectories.”
  • Resolve rate: The percentage of benchmark tasks for which the generated patch passes the verifier. “We report resolve rate, the percentage of tasks whose generated patches pass the benchmark verifier.”
  • Reward sparsity: A learning situation in which informative nonzero rewards are infrequent. “reducing them alleviates reward sparsity during policy optimization.”
  • Rollout: One execution of an agent on a task, producing a trajectory of actions and observations. “The resulting training rollouts identify the next hard-task set”
  • Search set: The collection of tasks used to evaluate and improve candidate harnesses. “The search set remains fixed within an H-step but evolves between rounds.”
  • Self-play: A training procedure in which a model generates its own interactions, examples, or opponents for learning. “and self-play code repair”
  • Sparse outcome reward: A reward signal that usually provides only a limited binary success or failure indication. “BAR adaptively draws additional trajectories to construct reward-balanced groups, reducing uninformative zero-variance groups under sparse outcome rewards”
  • Staged file: A file added to a version-control system’s staging area so that it can be included in a commit or patch. “ask to git add -N new files”
  • Supervised fine-tuning (SFT): Training a model on labeled input-output examples using a supervised objective. “SFT learns from resolved Opus 4.8 trajectories on the same training tasks”
  • Trajectory: A temporally ordered sequence of states, actions, and observations produced during an agent episode. “The current pair (Ht,Pt)(H_t,P_t) first generates trajectories on St\mathcal{S}_t”
  • Transferable gain: An improvement that remains when a method is evaluated on a different task distribution or benchmark. “with transferable gains on the out-of-distribution SWE-Bench Multilingual”
  • Zero-variance group: A sampled group whose members all receive the same reward, providing no within-group learning signal. “reducing uninformative zero-variance groups under sparse outcome rewards”
  • Zero-success rollout group: A group of sampled trajectories in which none succeeds. “the fraction of zero-success groups, in which no rollout succeeds, declines to 6.5%6.5\%”

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Tweets

Sign up for free to view the 5 tweets with 193 likes about this paper.