This note outlines why maintainability-oriented evaluation matters for coding agents and why benchmarks such as NITR are useful complements to patch-level correctness metrics.

Coding agents are often evaluated by whether they produce a patch that passes tests. That signal is necessary, but it is not enough if the goal is to measure engineering usefulness in real repositories.

In practice, many failures are not pure correctness failures. A patch may work while still introducing avoidable callsite spread, duplicated helpers, brittle interfaces, hidden coupling, or unnecessary side effects. These are maintainability failures, and they compound over time as codebases evolve.

This is the motivation behind maintainability-oriented evaluation. The right question is not only whether an agent can finish a task, but whether it can finish the task in a way that preserves the structure of the repository it is modifying. Benchmarks like NITR make that distinction explicit by testing whether changes remain local, reusable, testable, and structurally coherent.

Three properties make this kind of benchmark especially useful:

  • It exposes failure modes that are invisible in pass-or-fail patch metrics.
  • It gives dimension-level diagnosis instead of a single opaque score.
  • It better matches how engineers judge code quality during review.

For coding agents to become genuinely reliable engineering tools, they need to handle not just correctness pressure, but also design pressure. That means keeping changes local, reusing what already exists, isolating side effects, and maintaining clean boundaries as requirements evolve.