In the Age of AI Coding, Is Code Quality No Longer Necessary? — The Answer from the Creator of Claude Code

If you leave it to Claude Code or Copilot, code appears in an instant. It works. It even passes tests, more or less. When that happens, have you ever had this question pop into the back of your mind?

"Doesn't this mean I don't need to worry about refactoring or code readability anymore?"

In the era when humans wrote code by hand, it was natural to spend time on code reviews and refactoring. But is there any point in putting the same amount of effort into something that AI can write in a few minutes? Perhaps it would be better to run with a "if it works, it's fine" approach to leverage the speed of AI. At the same time, there is a vague anxiety about what will happen to a codebase that is continuously churned out sloppily. There must be many people who are just going through their daily development without having their own answer to this question of "how much should I care about quality?"

In September 2026, Boris Cherny (Anthropic), the very person who created Claude Code, answered this question in a fairly clear way. In this article, I will organize the theme of "code quality in the AI coding era," centered on that answer.

What is "AI slop" in the first place?

Before getting into the main topic, I will touch upon the term "AI slop" that appears repeatedly in this article. It is a slang term derived from "sloppy," referring to low-quality, hollow output generated by AI. Originally, it was a term that started being used in the generative AI community for text and images, but recently it has also come to be used in the context of coding. Code that works, but is full of useless duplication, just suppresses errors, or is code that no one understands the contents of. That is "AI slop in coding."

An email sent by a developer to Anthropic

In September 2026, a developer sent an email to Boris Cherny with the subject line "What to do about slop?". Cherny replied to this after prefacing that he "receives emails with similar content every day," and he published the content on his X account.

In the email, the developer pointed out the conflict between the following two positions.

• The Cautious Camp : Even if code is accelerated by AI, it should be reviewable, the submitter should be able to properly explain the contents, and it should be kept in a state that humans can maintain.
• The Permissive Camp : As long as the result is correct, that is all that matters. The contents of the code can be treated as a black box.

The developer pointed out that "many teams, out of fear of layoffs, cannot stick to the cautious approach and are being swept away by the permissive camp," and asked Cherny for "arbitration." This is exactly the same dilemma mentioned at the beginning: "Should I be particular about quality, or is it fine if it works?"

Cherny's answer — "There is a place for both," but with conditions

Cherny's reply was as follows.

The point is in the latter half. Cherny asserts that for production code, rather than lowering the standards because it was written by Claude, one should actually impose higher standards than if it were written by a human.

In other words, it is not a matter of "the cautious camp or the permissive camp, one of them is correct." By showing a two-stage judgment axis of prototype = black box is fine / production code = impose higher standards than if written by a human, he is giving an answer that clearly leans toward the "production code" side.

Returning to the opening question, the answer is this: far from code quality becoming unnecessary if AI writes it, at least for code that runs in production, you actually need to build in more quality than ever before. This is the position of the person who created Claude Code. There is no reason to lower the hurdle from the era when humans wrote it; it is a conclusion contrary to intuition that it should actually be raised.

Why are "higher standards" necessary? — The habits of AI code shown by data

This conclusion is backed by more than just intuition. The report "The Maintainability Gap: 2026 AI Code Quality Research" published by GitClear in June 2026 analyzes 623 million code changes from 2023 to 2026. Looking at the numbers shown there, it is clear that code written by AI has structural habits that naturally deteriorate if left alone.

• Block-level code duplication: 81% increase
• Copy & paste: 41% increase
• Refactoring (moving/organizing code): 70% decrease (dropped from 21% in 2022 to 3.8% in 2026)
• Error masking structures (ways of writing that suppress errors): 47% increase
• Changes to code untouched for over a year (long-term maintenance): 74% decrease

This is not simply a matter of AI 'writing bad code.' While AI is good at quickly producing code to solve the task at hand, it tends to put off the mundane but eventually impactful work of reorganizing existing code or finding and consolidating duplicates. The 'incidental cleanup' that human engineers naturally performed stops happening when you leave it to AI. This is the structure that GitClear's data reveals. That is precisely why, as the ratio of work left to AI increases, the codebase will quietly deteriorate unless you consciously prepare mechanisms for refactoring and quality checks from the outside. Cherny's statement about 'imposing higher standards than when humans write it' is easier to accept if you read it as being premised on this structural tendency.

The burden on the reviewer is not a matter of individual laziness

There is another interesting piece of evidence. The arXiv paper "An Endless Stream of AI Slop: How Developers Discuss the Burden of AI-Assisted Software Development" (Sebastian Baltes, Marc Cheong, Christoph Treude) analyzes 1,154 posts across 15 Reddit and Hacker News threads to organize how developers talk about AI slop.

According to this paper, discussions surrounding AI slop fall roughly into three clusters. These are 'Review Burden,' which concerns the load on reviewers and the loss of trust; 'Quality Degradation,' which refers to the deterioration of the codebase and skills; and 'Pressure and Consequences,' which includes the pressure of layoffs, forced adoption, and a sense of crisis over the loss of craftsmanship. This paper views the problem of AI slop as a structure where 'the cost of individual productivity improvement is externalized to reviewers and maintainers.' It is a composition where the bill for someone writing quickly using AI is passed on to someone else who has to review it and maintain it later.

This is a form of academic analysis confirming the conflict structure depicted in Cherny's email—cautious versus permissive, and the fear of layoffs. In other words, 'whether or not to build in quality' is not a matter of individual mindset, but a structural friction occurring across the entire team or even the entire industry. That is precisely why we need to ensure quality as a system, rather than relying solely on individual effort. The Anthropic initiative we will look at next is exactly an example of that systematization.

The 6 checks Anthropic actually imposes on production code

So, how exactly does Anthropic implement 'higher standards than humans'? In the quote above, Cherny lists the following six (Umesh Malik organized these in a blog post on September 14, 2026, adding practical supplements).

1. Lint rules (lots of lint rules) — Mechanically detecting code styles and anti-patterns
2. Unit and integration tests (lots of tests) — Continuously checking that behavior is not broken
3. Agent-driven E2E tests (Claude-driven end to end tests) — Having Claude itself perform end-to-end behavior verification
4. Continuously running fuzzers at night (Claude-powered fuzzers running daily) — Automatically identifying behavior against unexpected inputs every night
5. Automated code reviews and security reviews (automated code reviews and security reviews) — Applying mechanical checks before human reviewers
6. Automated refactoring (automated code refactoring) — Periodically and automatically resolving duplication and missed cleanup

As you can see when laid out, none of these are novel technologies. Linting, testing, and code reviews are all long-standing quality management techniques. What Anthropic is doing is increasing the density of their application—moving them from things that "humans do when they feel like it" to things that are "mechanically and continuously applied to the massive amount of code that AI generates at all times." It can be seen as a pinpoint strike against the trends of "increased duplication" and "decreased refactoring" that GitClear's data has highlighted.

Reflecting on my own development, about half of the six items are covered mechanically. I have already implemented formatters and unit/integration testing frameworks, and I have integrated these into CI so they run constantly. I also have E2E tests, which cover some scenarios on both the frontend and API sides. However, both are just tracing scenarios written by humans, not agent-driven E2E. In particular, the frontend E2E has become overly complex due to pattern branching based on environment variables, so I now prioritize maintaining the existing scenarios over adding new ones. On the other hand, I honestly haven't touched automated code review or automated refactoring. Looking at them all, while "linting" and "testing" are working as mechanisms, the reality is that E2E is halfway there, and automation for reviews and refactoring is a complete blank.

You don't need to implement all six at once

What concerns me here is the sentiment that "we don't have the capacity to set up six different mechanisms." Regarding this point, Umesh Malik provides a practical supplement.

If you try to implement all six layers at once, the team will run out of time to "classify the newly detected noise." A massive influx of warnings and review comments will arrive all at once, making it impossible for anyone to judge which points are truly important. Therefore, Malik recommends a phased introduction: start with the weakest layer in your team, build trust in those checks over about two weeks, and then add the next layer.

For organizations that are already shipping AI-generated pull requests on a daily basis, it is explicitly stated that adding the fifth item, "automated code review," first provides the highest ROI. This is because inserting a mechanical check before a human reviewer even looks at the code significantly reduces the review burden. In terms of cost, it is noted that while the execution infrastructure itself, such as GitHub Actions, can be run for about $15 per month, the actual costs that add up are the subscriptions for specialized tools like Semgrep or Snyk. In other words, what is needed is not to "equip all six with an expensive system," but to start with what you can within your existing CI environment.

Summary — Situations where "if it works, it's fine" is acceptable, and where it is not

Reorganizing Cherny's answer, the judgment criteria are simple. If it's a prototype intended to be discarded and the impact of it breaking is small, you don't need to scrutinize the contents. However, for code that runs in production—that is, code that will be used by people and maintained by someone later—you should impose higher standards than if it were written by a human, precisely because it was written by an AI.

The intuition that "if AI writes it, quality is no longer needed" leads to the opposite result based on the data we have seen in this article. Duplication increases, refactoring decreases, and the bill for that is passed on to the people who review and maintain it. If that is the case, what we should do is not "sacrifice quality to leverage AI's speed," but "prepare mechanisms from the outside to ensure quality does not drop while still leveraging AI's speed." Techniques like linting, testing, and automated reviews are not new. Whether or not we can update our systems to continuously apply these to the massive amount of code AI generates will likely be the turning point for quality management from here on out.