AI Slop Will Change Coding Before It Replaces Programmers

Anthropic reported on June 16, 2026, that its analysis of roughly 400,000 Claude Code sessions from October 2025 through April 2026 found users averaging 20 hours a week in the tool, while the share of GitHub projects showing coding-agent activity had more than doubled since late 2025. Those are usage measures, not proof that the resulting software is better or more profitable. They do establish that agent-written code is moving from occasional autocomplete into the ordinary production process.

My prediction is that, by July 2028, AI slop will make the median well-run software team more selective about what it merges, even as it writes and ships more code. I put the probability at 70 percent. I am not predicting that AI-generated code will become uniformly bad, that programmers will disappear, or that every organization will suffer a debt crisis. The more likely result is uneven: cheap implementation will expand the volume of plausible changes, and teams that cannot cheaply verify those changes will slow down or accumulate costs they have deferred.

For this essay, AI slop means code, tests, configuration, documentation, or pull requests generated or materially expanded by an AI system that enter a shared codebase faster than a responsible maintainer can establish their behavior, security properties, architectural fit, and future maintenance cost. A small generated script that an engineer understands is not slop under this definition. Nor is a rejected agent patch. The defining issue is a mismatch between production speed and accountable understanding.

The bottleneck moves from typing to verification

The driving force is a cost curve. A coding agent reduces the marginal cost of producing a credible-looking implementation: it can search a repository, edit many files, draft tests, run commands, and retry. Anthropic describes Claude Code as a system that can read a codebase, make multi-file changes, run tests, and deliver committed code. That capability matters because code review has historically used authorship as a rough proxy for understanding. When a developer wrote a change, reviewers could assume the author had at least traversed the relevant paths. Agentic production weakens that assumption.

The causal chain is straightforward. First, an agent makes an additional feature, refactor, migration, or integration cheap enough to request. Second, each request arrives with the surface signals that normally ease approval: formatted code, a coherent diff, passing unit tests, and an explanation. Third, the reviewer must determine whether the test suite omitted an edge case, whether a dependency is appropriate, whether the design duplicates an existing abstraction, and whether a locally correct patch worsens a system property that no test captures. Fourth, a team either spends more senior time reviewing, introduces stronger automated checks, or merges on less evidence. The third option is where slop becomes debt.

This is why counts of generated lines and completed tickets are leading indicators, not outcome measures. They tell us that supply is rising. Defect escape rates, rollback frequency, on-call load, time to understand an unfamiliar subsystem, and the age of unresolved static-analysis findings are lagging indicators. They arrive after a team has already accepted the code. A March 30, 2026 preprint that tracked 304,362 verified AI-authored commits across 6,275 GitHub repositories found that 24.2 percent of the AI-introduced issues it followed remained at the latest repository revision. The study is not a verdict on every tool or codebase, but it identifies the exact failure mode that a production metric such as “time saved writing code” can miss.

The verification problem also explains a seeming contradiction in developer sentiment. Stack Overflow’s 2025 survey reported that 84 percent of respondents were using or planning to use AI tools, while only 29 percent said they trusted AI output, down from 40 percent in 2024. Its respondents also identified almost-right answers as a leading frustration, and 66 percent said they were spending more time fixing almost-right AI-generated code. Adoption is therefore not evidence of settled confidence. It is evidence that the tool clears a low bar for trial even when it fails a higher bar for delegation.

The historical analogy is publishing, with an important difference

The closest analogy is not the arrival of a better compiler. It is the web’s earlier collapse in the cost of publishing. When posting became nearly free, the supply of pages grew faster than the supply of editing, fact-checking, and audience attention. Distribution systems responded by ranking, filtering, and rewarding trusted sources. Software teams are likely to build their equivalent: policy checks, provenance requirements, stronger test harnesses, constrained agent permissions, and review rules tied to risk rather than diff length.

The analogy breaks down in a way that makes coding more dangerous. A weak web page can waste a reader’s time and damage a publisher’s reputation; a weak code change can alter payroll, expose customer data, corrupt a database, or turn an on-call rotation into a permanent cleanup operation. Software also has executable feedback loops. An AI agent that can read untrusted text, access private files, and make external calls creates a different class of risk from a content generator. Anthropic’s October 20, 2025 description of sandboxing for Claude Code makes the point indirectly: it treats filesystem and network isolation as necessary boundaries when agents can run commands inside a developer environment.

There is a second historical lesson. Adoption and profit often diverge. Cloud computing made infrastructure easier to provision, yet it also created large bills and a discipline of FinOps to control them. AI coding will have a similar split. A company can increase feature throughput while losing margin to review, incident response, security remediation, inference spending, and a codebase whose ownership has become unclear. The winners will not be the organizations that generate the most patches. They will be the ones that make high-confidence rejection and repair cheap.

The case for abundance is stronger than critics admit

The best opposing case is that “slop” is a temporary label for work that engineers have not yet learned to supervise. Simon Willison has argued that code is cheap in agentic engineering, and he has documented patterns in which coding agents can take on substantial typing and execution work while people supply intent, constraints, and evaluation. Anthropic’s June 2026 session analysis similarly found that greater domain expertise was associated with agents doing more work per instruction, and that the share of sessions devoted to debugging fell by nearly half over the seven months studied. The optimistic interpretation is not frivolous: better tests, clearer specifications, isolated environments, and experienced operators can turn abundant code into useful output.

That view gets two things right. First, generated code can remove real drudgery, particularly boilerplate, mechanical edits, test scaffolding, and exploratory prototypes. Second, the quality of the human operating system around the model matters more than a simplistic human-versus-AI comparison suggests. METR’s randomized trial, published July 10, 2025, found experienced open-source developers took 19 percent longer when using then-current AI tools on familiar repositories. METR explicitly cautioned that this did not establish a general slowdown across software work. Its February 24, 2026 update also said a newer experiment had become unreliable because more developers did not want to work without AI. That is a useful warning against treating either enthusiasm or one adverse result as a universal law.

What will separate useful AI code from slop

The practical dividing line will be whether a team converts tacit engineering judgment into checks an agent cannot casually evade. Mature organizations will make agents work inside narrow permissions, require tests that express product and failure behavior rather than merely execute new lines, record who owns a generated subsystem, and reserve senior review for interfaces, data handling, concurrency, security boundaries, and irreversible changes. That is a change in software management, not merely an IDE preference. It shifts authority toward people who can specify a system and detect when a neat local solution violates a global constraint.

The first falsifiable prediction is dated June 30, 2027: in public developer surveys, reported use of AI coding tools will remain above 80 percent while reported trust in their accuracy will stay below 40 percent. I would concede this forecast is wrong if trust clears 40 percent without a comparable decline in usage, because that would show experience is closing the verification gap faster than expected. The second is dated July 23, 2028: major engineering organizations will treat agent access, generated-change provenance, and automated evaluation as normal release controls, much as dependency scanning is now. I would concede that prediction is wrong if widely used coding agents become broadly autonomous in production repositories without those controls and organizations can show falling rollback, security-remediation, and maintenance costs at the same time.