The Generation Gap
In early August, Meta Superintelligence Labs released Muse Code, a terminal coding agent in beta powered by its new Muse Spark 1.2 model. The agent plans changes across large repositories, writes code, and validates its own results, with async background agents that persist for an entire session rather than spawning per task. Three weeks later, GLM-5.3 Flash arrived with open weights, a 1-million-token context, and a hybrid sparse-linear attention architecture. Meanwhile, the Model Context Protocol roadmap, updated in August, is organized entirely around the problems of running agents at production scale: agent identity for non-human callers, progressive tool discovery so a server with hundreds of tools does not flood the model's context, extensions for long-running tasks, and HTTP-native transport unification. The July 2026 specification release, which the maintainers called the largest revision since MCP launched, made the protocol stateless at its core, removed session handshakes, and enabled MCP servers to scale on standard HTTP infrastructure. For engineering teams, that last point matters: it means MCP-connected agents can now run on the same commodity cloud infrastructure that serves web traffic, without specialized session management.
The pattern is clear: the tooling is maturing rapidly around generating and orchestrating more work. What is maturing more slowly is the organizational capacity to own what that tooling produces.
The constraint on AI-assisted delivery is shifting from generation to ownership. Code now arrives faster than the practices that keep it maintainable, and the resulting debt is not evenly distributed. It concentrates in the categories that are least visible in review and most expensive to find later. This article is not a skeptical take on AI-assisted development. We build AI-native applications using these tools and offer AI-driven engineering as a core service. The credibility here comes from being specific about where the maintenance cost concentrates, not from hedging about whether the tools work.
What the Research Actually Shows, and What It Does Not
The most rigorous dataset we have on this question comes from a March 2026 empirical study by Liu, Widyasari, Zhao, Irsan, and Lo at Singapore Management University and Huazhong University of Science and Technology. The researchers examined 304,362 verified AI-authored commits across 6,275 GitHub repositories, identified through explicit Git metadata rather than inference, and found 484,606 introduced issues: 89.1 percent code smells, 5.8 percent runtime bugs, and 5.1 percent security issues. To put the scale in perspective: 304,362 commits represents roughly the output of thousands of active developers over a year, which is why the dataset is unusually well-powered to detect patterns that smaller studies miss.
Before citing any number from this study, we need to be precise about what it does and does not establish. The authors deliberately excluded a human-written baseline. Their reasoning: AI use often leaves no Git trace, and a contaminated baseline would mislead more than no baseline at all. This means the paper measures the volume and persistence of debt in AI-authored commits only. It does not prove AI code is worse than human code, and we will not claim that it does.
The paper also contains an internal inconsistency worth naming directly, because naming it is more credible than repeating either figure alone. The study reports that more than 15 percent of commits from every assistant introduce at least one issue, with a per-assistant range documented in the paper's own tables. Its aggregate table, however, reports a substantially lower share of affected commits as a percentage of the total, without reconciling the two figures. We do not know whether the discrepancy reflects different counting units, different filtering criteria, or something else the authors did not explain. Both figures appear in the paper; neither is authoritative without the reconciliation that is missing.
A separate empirical study, arXiv:2510.10165, examined GitHub Copilot adoption in open-source repositories and reached findings that are worth presenting on their own terms, with their own population and definitions. In that study, productivity did increase, but the increase was driven primarily by less-experienced developers. Experienced developers reviewed 6.5 percent more code after Copilot's introduction but showed a 19 percent drop in original code productivity. The paper additionally documents a divergence between how productive developers felt and what output measurements showed. These are different studies with different methodologies, different populations, and different definitions of productivity, and they are cited separately here for that reason.
A number of other figures circulate widely in commentary on this topic: claims of technical debt increases of 30 to 41 percent after AI tool adoption, 1.7 times more issues per pull request, and 23.5 percent more incidents per pull request. We evaluated these figures and chose not to cite them here. The underlying benchmark reports from which they originate are vendor-produced, and we were unable to verify the sample definitions and pull request populations against primary sources in a way that would allow us to present the figures accurately. Blending vendor benchmark numbers with peer-reviewed findings in the same argument would misrepresent the state of the evidence. Where a number cannot be traced cleanly to its methodology, it does not belong in this analysis. That standard applies to our own analysis as well.
The Debt That Stays
The survival data from Liu et al. is where the operational picture becomes actionable. Of the issues the authors could track, 24.2 percent survived at the repository's latest revision. Security issues survived at the highest rate: 41.1 percent. AI-authored commits fixed more code smells than they introduced, a net reduction the authors document in their aggregate results table, which is genuinely good news. They also introduced security issues at a substantially higher rate than they fixed them, which is not.
The time-decay data sharpens the picture further. Debt introduced in the last three months shows roughly 39.9 surviving issues per 100 AI-authored commits. For debt older than nine months, the figure is 22.2. The authors acknowledge their own caveat honestly: part of that decline reflects real remediation, and part reflects files being deleted or rewritten, which they count as resolved and acknowledge may understate persistence. Either way, recent debt is largely still present.
Security debt is the least likely to be cleared, which means the category of debt most likely to cause a serious incident is also the one most likely to still be there when the incident occurs. That asymmetry is the operational problem. Teams that have significantly increased AI-assisted output over the past year are not accumulating a backlog of cosmetic issues. They are accumulating a backlog of unresolved security findings at a higher survival rate than any other category. For a team that has shipped a year's worth of AI-assisted commits, a 41.1 percent security-issue survival rate means that roughly four in ten security findings introduced during that period are still present in the codebase today.
Specific Shapes, Specific Fixes
What separates a useful analysis from a general warning is specificity about defect shape. The Liu et al. findings are specific enough to act on directly. In Python, the leading issues include broad exception handling, unused arguments, undefined references, and access to protected members, with broad exception handling accounting for the largest share of Python-specific findings according to the paper's per-language breakdown. In JavaScript and TypeScript, the paper's per-language tables identify unused variables and parameters and shadowed outer variables as the leading patterns. On the security side, the paper's security issue taxonomy identifies recurring patterns including subprocess calls without shell checks, try-except-pass patterns that suppress exceptions entirely, partial executable paths, and insecure random generators.
Every one of these is detectable by static analysis in continuous integration, today, without custom tooling. The recommendation is not "improve code review." It is to name the rule sets and enforce them.
For Python, Pylint catches bare and broad exception handling, unused arguments, and related patterns; the W0702, W0703, and W0613 rule numbers are documented in the official Pylint reference. Bandit catches subprocess calls without shell checks and insecure random generators, along with hardcoded secrets and other OWASP Top 10 patterns. Semgrep covers try-except-pass, broad exception handling, and subprocess patterns across Python and JavaScript, and integrates directly with GitHub Actions, GitLab CI, and equivalent pipelines. For JavaScript and TypeScript, ESLint rules no-unused-vars and no-shadow catch the leading patterns identified in the study. These tools are specific and implementable; Pylint, Bandit, and ESLint each publish official CI integration documentation, and all four support merge gate enforcement in standard pipelines. In our experience delivering AI-assisted engineering engagements, that enforcement is the control mechanism that makes the difference between debt that accumulates silently and debt that gets surfaced before it reaches production.
Why Review Alone Will Not Catch This
This argument is distinct from the code review capacity bottleneck, which is a different problem about reviewer bandwidth. The issue here is not that there are too few reviewers. The issue is that the defect shapes AI tools produce most frequently are the ones that pass human review precisely because they look deliberate.
Broad exception handling looks like intentional fault tolerance. A suppressed try-except-pass looks like a conscious decision to swallow a known error condition. A subprocess call without a shell check looks like a performance choice. Human reviewers, operating under the reasonable assumption that the author had a reason, will approve these patterns at high rates. That is not a failure of attention. It is a structural limitation of review against code that is syntactically correct and contextually plausible. The Liu et al. data on defect persistence supports this directly: if these patterns were being caught in review, the survival rates would be lower.
The controls that reliably catch these patterns are automated: lint and security rule sets enforced as merge gates, dependency and secret scanning, and a standing policy that agent-authored changes cannot bypass them. The merge gate is not a substitute for review. It is the control that catches what review routinely misses, precisely because it does not assume intent.
CISA's Secure by Design guidance makes the case for this approach directly, establishing that security properties must be built into software through verified controls rather than assumed through process alone. That expectation is already embedded in government acquisition frameworks. CISA's Software Acquisition Guide explicitly requires suppliers to perform a risk assessment of AI-generated code's impact on security functions and to validate license implications of AI-generated code. NIST has finalized SP 800-218A, a Secure Software Development Framework community profile that augments the base SSDF with practices, tasks, and recommendations specific to AI-generated code throughout the software development lifecycle. Neither document prescribes merge gates by name, but both establish the verification expectation that automated tooling is the practical means of satisfying. The verification expectation is not emerging. It is already written.
The Modernization Problem Is a Decade-Long Bet
Legacy modernization is one of the strongest current use cases for AI-assisted development. GitLab, a DevOps platform vendor with commercial interest in government software delivery, has noted that critical agencies including the Department of Health and Human Services, the Social Security Administration, and the Centers for Medicare and Medicaid Services depend on COBOL and other legacy systems for essential government functions. That observation is consistent with what independent academic research on human-AI collaboration in COBOL modernization has documented: these are long-lived systems in public administration supporting tax processing, pension management, and social security, sectors where the pressure to modernize is real and the cost of getting it wrong is durable.
AI-assisted analysis and translation of legacy code is genuinely useful in this context. It is also the setting where surviving security debt matters most, for reasons that compound over time. The staff who could recognize a subtle defect in the original system are often the ones being replaced by the modernization itself. The resulting code will be maintained for a decade or more by people who did not write it and cannot interrogate the original intent.
In this context, a 41.1 percent security issue survival rate is not a quality metric. It is a liability that accrues interest. A modernization program that generates code faster than it verifies it is not accelerating delivery. It is deferring a security audit that will eventually be mandatory and considerably more expensive to conduct after the fact.
The practical recommendation for agency technical staff writing modernization statements of work is to fund verification and static analysis explicitly as line items in the scope, not as an assumption that generation savings will absorb the cost. CISA's acquisition guidance already creates the expectation. NIST SP 800-218A provides the framework. The statement of work should require the verification artifacts that satisfy both.
Throughput Is Real. So Is the Bill.
We build AI-native applications using these tools. The throughput gains from AI-assisted development are real and worth pursuing. The question is not whether to use AI-assisted development. The question is whether the practices that keep the output maintainable are scaling alongside the output itself.
That is the reasoning behind AI-Driven Engineering as we define it: AI-native applications built by engineers rather than by models alone, with architect-led design and humans in the loop. The model generates. The engineer owns. The automated gate enforces what neither can catch reliably on its own. That division of responsibility is not a constraint on velocity; it is what makes velocity sustainable.
The practical implication of the evidence reviewed here is a sequencing requirement, not a capability constraint. Any team that has measurably increased AI-assisted output over the past year should audit whether automated quality gates, lint enforcement, security scanning, and merge gate policies were added in the same change, or whether they are still on the backlog. Adding them in the following quarter is not soon enough. The debt accumulates in real time, and as the Liu et al. data shows, recent debt at roughly 39.9 surviving issues per 100 AI-authored commits is largely still present when the audit finally happens.
The MCP roadmap is solving for agent identity and production-scale orchestration. Muse Code is targeting complex software engineering across large repositories. The next constraint is not generation capacity. It is the organizational discipline to own what has been generated. The teams that will look back on this period with the least regret are the ones that treated verification capacity as a prerequisite to generation capacity, not a follow-on.
Sources
- Meta AI Releases Muse Code (Beta): A Terminal Coding Agent Powered by the New Muse Spark 1.2 Model — MarkTechPost (2026)
- GLM 5.3 Flash: Specs, Benchmarks, Price and Weights — FelloAI (2026)
- Model Context Protocol Roadmap — Model Context Protocol (2026)
- Model Context Protocol Blog - 2026-07-28 Specification — Model Context Protocol (2026)
- New MCP Roadmap Tackles the Problems That Come with Running AI Agents at Scale — VKTR (2026)
- Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild — arXiv (2026)
- AI-Assisted Programming Decreases the Productivity of Experienced Developers by Increasing the Technical Debt and Maintenance Burden — arXiv (2025)
- Pylint: Code Analysis for Python — PyCQA
- Bandit: A Security Linter for Python — PyCQA
- Semgrep: Static Analysis for Code Security and Quality — r2c
- ESLint: Pluggable JavaScript Linter — OpenJS Foundation
- Software Acquisition Guide: Supplier Response Web Tool — CISA
- Secure Software Development Framework — NIST
- How AI can fix government's legacy code problem — GitLab
- Human–AI Collaboration in the Modernization of COBOL-Based Legacy Systems — MDPI
