Why AI Coding Agents Can Degrade a Codebase One Feature at a Time

A model that fixes one well-scoped bug and passes the tests is not the same thing as a model that can extend a product for a year. An individual-issue score does not measure that second skill. Founders pay for the second.

SWE-bench evaluates individual GitHub issues in existing repositories. An issue can require coordinated changes across functions, classes and multiple files; it is not necessarily a small or self-contained task. What that setup does not measure is an agent repeatedly extending its own earlier solution as requirements evolve. Real products receive changes over time, with each request building on previous decisions.

What iterative work does to code quality

In SlopCodeBench, agents repeatedly extend their own code as requirements evolve. The study's 7 May 2026 revision evaluated 15 coding agents on the Python track: 36 problems and 196 checkpoints. Structural erosion increased in 77% of trajectories, while the verbosity measure increased in 75.5%. Core-test pass rates also fell as problems progressed. These findings identify a risk in repeated autonomous changes under the benchmark's conditions, not an inevitable outcome for every agent or codebase.

Our practical recommendation is to review structural changes alongside behavior: can the team explain the new abstraction, remove replaced paths safely and extend the result without duplicating logic? Those are review questions, not findings about code deletion or the training rewards of the evaluated models.

Do not borrow against a future model

It is tempting to accept sloppy code today on the theory that a better model will clean it up later. That is a planning assumption, not a result established by the benchmark. Our recommendation is to assign today's code quality to today's team, with an explicit cleanup scope rather than an unspecified future model.

For a product team, our practical recommendations are:

• Keep human ownership of structure. Agents add code quickly, but someone must decide where it belongs and what should be removed.
• Review for accumulation, not only correctness. A change can pass its tests and still make the next change harder.
• Run less in parallel. Fewer simultaneous agent tasks leave more attention for judging each result.

Plan to remove failure modes before code exists

For a large feature, our practical recommendation is progressive narrowing. Start with a one-page description of the problem and intended end state, then work through the specific changes, dependencies and acceptance checks. This gives reviewers a concrete plan to challenge before code is written. It can expose misunderstandings early; it does not guarantee that a generated pull request will need little rework.

Whether this document is called a plan, a spec or a design doc matters less than its content: where the product is going, how the work gets there, and how success will be judged. The code remains the source of truth, so the plan is a filter and not a promise of perfection.

Model choice deserves the same discipline. The largest and most expensive model is not needed for every task, and some organisations restrict it to cases that justify the cost.

What this means for web development

AI coding agents are useful for web products, but a first draft and a sustained change are different review problems. Our recommendation is to pair them with upfront design, small reviewed increments and deliberate refactoring, then check the actual result. A passing test suite is evidence of the behaviors it covers, not a guarantee that the next feature will be easy to add.