Self-Evolving Coding Agents via Harness-Policy Optimization
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.
Paper Prompts
Sign up for free to create and run prompts on this paper.
Top Community Prompts
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:
- ¿Es mejor mejorar el modelo y el arnés juntos que mejorar solo uno de ellos?
- ¿Puede el propio modelo descubrir por qué falla y proponer cambios útiles en su arnés?
- ¿Puede este sistema seguir mejorando cuando los problemas difíciles cambian?
- ¿Las mejoras funcionan también en tareas y lenguajes de programación diferentes de los usados durante el entrenamiento?
- ¿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:
- El agente estudia sus fallos.
- Propone un arnés mejor.
- Aprende con ese arnés.
- Se identifican sus nuevos problemas difíciles.
- 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
kintentos.
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:
- mejorar el arnés usando los errores del agente;
- entrenar el modelo con ese arnés mejorado;
- 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 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@ analysis is narrow: The capability-frontier analysis uses eight attempts on SWE-Bench Verified only. It does not examine how gains scale with larger , 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@).”
- 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 is scored by an executable verifier .”
- 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 ”
- 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 ”
- 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 , we collect on-policy trajectories over 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 generated attempts solves a task. “Self-HPO remains above Base for every 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 .”
- 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 first generates trajectories on ”
- 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 ”





