LLM Software Engineering Evaluation

Evaluation is expected to follow coding agents through real repository work rather than end with a successful patch. The scenario borrows the mechanism of pharmaceutical safety monitoring: benchmarks establish initial capability, while deployment reveals warning signals through later edits, regressions, and lost understanding. Benchmark authority is retained, but it can be reduced when later evidence shows persistent problems.

In the first year, researchers will define measures for code survival, substantial rewriting, and retained developer understanding. Open sandboxes will isolate parts of the workflow so that context practices, memory, or recovery logic can be tested separately. Multi-organization studies will then check whether the measures remain meaningful across languages, repositories, and developer experience levels. Organizations will run limited pilots and distinguish immediate acceptance from durable use, applying longer observation and stronger review to consequential changes.

In the second year, reproducible measures could become a compact evaluation dossier used across organizations. Results will be separated by task and repository rather than collapsed into one universal score. Researchers will compare memory, clarification, and recovery policies to identify combinations that improve speed without weakening understanding. Organizations may then grant conditional permissions, widening an agent’s role when local survival and recovery results are strong or narrowing it when rework remains high.

By the third year, real repository evidence should feed directly into new evaluations and product controls. Repeated failure patterns will become reproducible test cases, while bounded retry measures will prevent agents from appearing reliable through uncontrolled debugging. Tools may add stronger provenance, rollback support, and task-tiered controls that adjust an agent’s permitted scope. A useful monitoring cue will be benchmark reports that include downstream outcomes and standardized process logs. The path would be weakened if these measures fail to predict defects or later maintenance effort, or if comparable data cannot be shared safely. Repository differences and continued developer editing also limit the safety-monitoring analogy, so task stratification and predeclared observation periods remain important safeguards.

Coding-agent evaluation is moving from narrow benchmarks toward evidence collected during real software workflows. This scenario uses a tiered inspection mechanism: every AI-assisted change receives inexpensive checks, while changes with greater consequences receive stronger testing or human review. The trigger is evidence that accepted code may soon be revised or removed and that faster completion can coexist with weaker understanding.

During the first year, researchers will connect benchmark results with IDE events, pull-request histories, and automated test outcomes. Organizations will add reliable origin tags for AI-assisted changes and measure later rework separately from initial acceptance. Routine style changes may be monitored statistically, while security-sensitive code, migrations, or database changes receive more demanding checks. The key threshold is whether local evidence becomes reliable enough to alter agent rankings, repository permissions, or rollout decisions.

In the second year, common event definitions should make results easier to compare without exposing source code or complete developer traces. These records will describe context use and recovery behavior, while broader outcome measures capture later edits and review burden. Field failures will also shape benchmarks that test whether an agent can recognize a problem and recover efficiently, rather than merely produce a passing patch after repeated attempts. Organizational approval processes may begin requesting this task-specific evidence alongside public benchmark results.

By the third year, evaluation could operate as part of workflow control. Low-consequence contributions would pass through automated checks and statistical monitoring, while consequential changes could trigger replay, additional tests, or human sign-off. Memory and tool use would be evaluated as parts of the complete agent configuration because they can change rework and recovery even when the underlying model stays fixed. The likely result is a set of repository-specific scorecards combining benchmarks, process traces, and downstream outcomes rather than one universal score. A strong monitoring cue would be cases where internal trials rank agents differently from public leaderboards. The path would weaken if telemetry remains too noisy or intrusive to guide decisions, or if broad benchmarks already predict local maintainability well. Since repositories differ greatly and lost understanding is difficult to measure, several imperfect indicators must be interpreted together.

Evaluation may combine benchmark results with process traces, field outcomes, and measures of developer understanding. This scenario again borrows evidentiary sequencing from pharmaceutical safety monitoring. Controlled tests establish initial capability, while real use reveals problems that pre-deployment evaluation cannot estimate well. Post-acceptance edits and later extension work therefore become evidence rather than being treated as activity outside the evaluation.

In the first year, researchers will test whether such events can be measured consistently and separated from normal software editing. Replications will compare repositories, languages, and task types, while privacy-preserving provenance will link accepted suggestions to later changes. Studies will then ask whether rewrite timing, test regressions, or recovery behavior predicts maintenance better than final-patch accuracy. Organizations will instrument a limited set of repositories and define event records, retention periods, and provenance confidence. The practical threshold is reached only if several major users request compatible evidence and make continued access or repository permissions depend on an outcome threshold.

In the second year, anonymized event statistics could support baselines across organizations. Repeated field failures would become reproducible sandbox cases, allowing researchers to test whether early warning signals predict later defects or extension effort. Permissions would also become more specific: an agent might be allowed to handle routine changes in one repository but face stronger review for a consequential task elsewhere. Approval would therefore attach to the complete agent and workflow configuration, not simply to a model name.

By the third year, measures with demonstrated predictive value could support auditable task bands, uncertainty estimates, and periodic re-evaluation. Developer tools and automated integration systems might use this evidence to decide where an agent may operate and which controls it requires. The resulting layer would combine benchmark breadth, recovery behavior, and downstream outcomes rather than produce a universal score. A useful monitoring cue would be compatible trace exports becoming a requirement in tool evaluations or continued-use decisions. The scenario should be downgraded if large replications find that post-acceptance measures do not predict maintenance burden or total workflow cost. It may also stall if privacy reviews block attribution or if telemetry encourages metric gaming. Because software changes are often reversible and developers continue modifying them, causal conclusions will remain more uncertain than the safety-monitoring analogy suggests.