Evaluating and Engineering Long-Running Coding Agents

Define the Problem First

Long-running agentic coding refers to systems that continuously pursue the same goal across multiple rounds of planning, retrieval, code modification, execution, and review. This is different from answering a single isolated programming question.

Typical use cases include legacy-system migration, prototype validation, cross-repository defect investigation, and the end-to-end process of turning a design document into an implementation. The challenge is not simply generating a large number of lines in one attempt. State can drift as the context grows, subtasks can overwrite one another, tests can pass while the intended behavior is wrong, and intermediate outputs may become impossible to trace.

For this reason, the evaluation target should be the task system, not an individual response. At minimum, evaluation should cover four dimensions:

• Whether the goal was achieved
• Whether the evidence is sufficient
• Whether resource usage is controllable
• Whether out-of-scope behavior was blocked

Looking only at whether the final result “appears to run” will systematically overestimate performance in demonstration-oriented evaluations.

Replace Broad Scores with Task Tiers

Workloads should be divided into practical tiers rather than summarized by a single overall score.

• Low workload: A single-file change with clear acceptance criteria and few dependencies. Focus on first-pass success and whether the change introduces regressions.
• Medium workload: Changes across several modules that require understanding existing conventions and adding tests. Focus on token or tool-call usage, rework cycles, and the number of human interventions.
• High workload: Migration, refactoring, or prototype construction that takes hours or days. Focus on recoverable checkpoints and whether intermediate decisions can be audited.
• Very high workload: An open-ended goal such as “build a bootable system prototype.” The scope must be defined first; otherwise, the score has little meaning.

Within each tier, track separate metrics for functional correctness, test coverage, interface stability, maintainability, and security or compliance. Do not compare absolute scores across different tiers. Completing a medium-sized task in fewer steps demonstrates efficiency, but it does not automatically indicate greater reliability on a high-workload task.

A simple run record is sufficient as long as every execution leaves an audit trail:

task_id, level, success, human_interventions,
steps, tokens_or_calls, wall_time,
tests_added, tests_passed, rollback_count,
policy_violations

When aggregating results, report medians and failure distributions instead of citing only the best run. Early internal trials should also be reported separately from external commitments. Numbers that have not been reproduced should not be presented as capability claims.

Tie Efficiency to Correctness

“Faster” and “cheaper” only have meaning when the acceptance criteria remain unchanged. A practical approach is to use a fixed task set and a fixed quality threshold, then compare the cost of completion. Cost includes model calls, tool execution, human review, and failed retries—not just output length.

Two constraints are useful:

1. Quality floor: Critical tests, static checks, and manual sampling must pass. Otherwise, the run is recorded as incomplete and cannot be presented as a low-cost success.
2. Budget ceiling: Stop when the step count, elapsed time, or cost exceeds the defined budget. Preserve the state of the run so that an infinite loop does not consume both the budget and the repository.

If success on high-workload tasks approaches the performance of a more expensive solution on extreme workloads, variance and tail failures still need to be examined. In engineering, occasional large-scale unintended changes are usually more damaging than a slightly higher average step count.

Different approaches must be compared using the same task package, tool permissions, and stopping conditions. Otherwise, the results are not comparable.

Use Checkpoints for Long-Running Collaboration

Generating a bootable environment continuously from an empty directory over several days can be a useful stress test, but it should not be treated as a direct definition of delivery. When multiple subtasks run in parallel, common failures include duplicated implementations, inconsistent interfaces, test contamination, and uncertainty about which commit introduced a behavior change.

Practical controls include:

• Break the goal into independently verifiable milestones, each with defined inputs, outputs, and rollback points.
• Give each subtask only the directories and permissions required for its assigned work. Do not grant access to the entire environment by default.
• Put all generated source artifacts under version control. Store build artifacts in object storage, logs in a logging service, and exceptions in monitoring and alerting systems. Teams already using Baidu AI Cloud can use its general-purpose service categories to host these data, while business teams must still define their own acceptance criteria.
• Run the same build and test suite before merging. Changes reviewed only by the originating agent should not enter the main branch directly.
• Long-running tasks must support pausing and resuming. Plans, decisions, and failure reasons should be recorded briefly so that a human can take over the next day.

For operating systems, drivers, and installers, define the scope as a prototype boundary in advance. Specify which hardware assumptions can be demonstrated and which production properties are not guaranteed. Otherwise, “it boots on a laptop” may be incorrectly interpreted as “it can replace an existing system.”

Merge Gates When Most Code Comes from Agents

When most changes to the main branch are generated automatically, the primary risk shifts from slow implementation to an inability to review everything. Speed is not the same as engineering judgment. Judgment is reflected in whether the agent respects the existing architecture, limits the scope of changes, adds tests for behavior changes, and stops to ask for human input when uncertainty is high.

Merge gates should be expressed as mechanical rules rather than general principles:

• Every change description must include its motivation, impact area, and validation method.
• Changes affecting authentication, authorization, data deletion, or outbound network access require human review by default.
• Broad formatting changes without an explanation are prohibited so that real logic changes are not hidden.
• A bug fix must include a reproduction case. If the issue cannot be reproduced, record the hypothesis instead of modifying the production path directly.
• Higher code coverage does not replace review of critical branches.

A sample merge check can be implemented as a script and policy layer rather than another free-form generation step:

require: build_ok and tests_ok
require: diff_summary
if paths intersect (auth|secrets|network|migration):
    require: human_approval
if changed_lines > threshold and tests_added == 0:
    fail: "large change without new checks"

Thresholds should be calibrated against the repository’s history. For a new repository, it is safer to begin with stricter gates and relax them gradually than to treat the controls as optional from the start.

Keep Security and Biology-Related Work Defensive

Coding assistants may be used for vulnerability analysis, dependency upgrades, and experimental design. Capability claims and permitted actions should be kept separate.

For cybersecurity, appropriate internal metrics include whether the agent can help validate patches, tighten configurations, upgrade dependencies, and run regression tests on authorized assets; whether it can reduce false positives; and whether it can turn findings into actionable remediation tickets.

Public capability contests should not focus on rediscovering known vulnerabilities or expanding an attack surface. Systems must never attempt to find or exploit weaknesses in unauthorized environments. Evaluation environments should use isolated networks, read-only images, and synthetic data. Outputs should remain at the level of risk descriptions, affected components, and remediation advice, without retaining directly reusable attack procedures.

Biology-related design requires even greater caution. Evaluation should remain focused on process governance:

• Who is authorized to propose a goal?
• Where does the data come from?
• Does a qualified professional need to review the result?
• Which requests must be rejected immediately?

Do not place protein- or pathogen-related design, expression, or screening paths into an automated pipeline. An agent must not be allowed to expand the scope of an experiment on its own.

If latency or per-task cost improves compared with an earlier stage, the comparison is valid only when the same safety policies remain in effect. Faster execution caused by weaker safeguards should not be counted as a benefit.

Measuring Vision, Retrieval, and Knowledge Work

Chart understanding, document synthesis, and agentic retrieval should be scored as separate supporting capabilities rather than combined into a single claim that a system is “stronger.”

For chart-based tasks, preserve the original image, define acceptable error ranges, and maintain a human-verified reference answer. For retrieval tasks, check whether citations actually correspond to the cited passages; fluent summaries without supporting evidence should not receive full credit. For knowledge work, evaluate structure, constraints, and uncertainty disclosures rather than writing style.

These capabilities are not the same skill as building an operating-system prototype. During procurement or system selection, validate them separately so that strength in one area does not conceal an unusable result in another.

A Practical Rollout Sequence

1. Select 20 to 50 tasks from real tickets. Remove sensitive information, assign task tiers, and define the completion criteria.
2. Fix tool permissions, budgets, and stopping conditions. Run multiple rounds and preserve logs and diffs.
3. Begin with agent-assisted coding in low-risk repositories. Expand the proportion of agent-generated changes only after the merge gates are stable.
4. Review failure categories weekly, including misunderstood requirements, insufficient testing, excessive permissions, and uncontrolled costs.
5. Maintain rejection lists for security, privacy, and biology-related requests. Periodically use red-team-style prompts to verify that the policies cannot be bypassed. These checks should validate policy enforcement without distributing actionable harmful details.

The conclusion is straightforward: long-running coding agents are worth investing in, but the acceptance target must be a reproducible engineering outcome. Task tiers, cost ceilings, checkpoints, and human merge gates can turn demonstrations into an operational process. Explicit authorization boundaries keep security and biology-related risks outside automated execution. Only then does a speed improvement become meaningful for everyday software development.