The first reaction of the engineering community when Coding Agent quality regresses is usually "the model has regressed again". But Sghaier et al. of Queen's University point out in arXiv:2607.03691: this is a misdiagnosis. This is the first longitudinal study that strips "scaffolding" out of the LLM as a controlled variable. All previous SWE-bench-type work has "fixed the scaffolding, swapped the model"; this paper does the reverse — fix the same underlying LLM, only swap the scaffolding, and see what happens across 35 consecutive versions. The study covers five major open-source scaffolds: Codex, Qwen Code, Gemini, OpenCode, OpenHands. First, looking at the ecosystem: average release rate is more than 2 times/day, accumulating thousands of issues over a few months. Then drilling into the 35 sequential versions of Qwen Code CLI, with each version scored on 50 stratified-sampled SWE-bench Verified tasks, the underlying model locked throughout. The conclusion is sobering: most of the fluctuation in task success rate and efficiency can be traced to specific PRs and specific architecture components, not the underlying model. Even with the base model completely unchanged, a single prompt template adjustment, a tool execution order change, or a context management refactor can cause quality curves to jump 5–10pp. The value of this paper isn't a new method, but in slapping a common blind spot: the industry bets compute, parameters, and leaderboards on the model, yet no one systematically measures the evolution contribution of the scaffolding itself. It calls for treating scaffolding as a "first-class citizen" to monitor — Agentic QA, Scaffolding Observability should have SLAs and regression tests like models. For teams developing their own Coding Agent, this means: you must do "controlled-variable benchmarks" before upgrading scaffolding, otherwise you'll fall into the mystic cycle of "upgrade one version, get 5% worse; upgrade again, come back".