What Should Developers Safeguard After AI Writes the Code?

Boris Cherny, the creator of Anthropic’s Claude Code, recently offered a very clear assessment: in the age of AI programming, what developers should safeguard most is not every line of code they write themselves, but the quality of the code itself.

This assessment may sound like a management slogan, but in today’s development environment, it corresponds to an increasingly real shift: engineers are moving from being “code producers” to becoming the ultimate owners of code quality. AI can accelerate implementation, but it will not automatically take responsibility for architectural loss of control, maintenance difficulties, or production incidents on anyone’s behalf.

On September 10 local time, Cherny publicly shared an email written to him by a developer. The subject line was direct: “How do you deal with AI slop?” He said he receives similar messages every day and tries to respond whenever possible.

What makes this email worth attention is not that it revisits the question of whether “AI will replace programmers,” but that it brings the debate back to engineering practice: when a model can generate in minutes code that previously took hours or even days to write, what standards should teams use to determine whether that code can enter the system?

Two Approaches to AI Programming: Accelerating Traditional Development or Only Looking at Results?

The anonymous developer in the email summarized the friction brought by AI programming into two approaches.

The first is the relatively restrained “augmented development” approach. Developers continue to work according to traditional engineering practices, but use AI to speed up implementation. They may not inspect every line of generated code, but the person submitting the code should understand and be able to explain their changes. The code should be at least as maintainable as before, and ideally clearer than code written manually.

The second is a more thorough “vibe coding” approach: treat code as a black box, look only at inputs and outputs, and do not worry too much about how it is implemented internally. As long as the functionality works, the page renders, and the test cases pass, the task is considered complete.

The fundamental difference between these approaches is not whether to use AI, but whether code understandability and maintainability still belong to the delivery criteria.

For one-off scripts, proofs of concept, and short-term prototypes, the answer can be relatively flexible. Temporary code used to validate a product idea may have already served its purpose if it can quickly prove the direction, even if its structure is not particularly elegant. Investing heavily in refactoring a prototype that is destined to be discarded may instead slow down decision-making.

Production code is different. It will be taken over by other people, face unexpected inputs, and interact with legacy systems, permission systems, data pipelines, and monitoring tools. What looks today like only a few hundred lines of “working” code may become a core dependency that no one dares touch several months later.

Therefore, Cherny does not believe the two approaches must be mutually exclusive. He draws a clear boundary: prototypes and other one-off code can be treated as black boxes; as long as the impact of failure is limited, there is no need to pursue perfection. Code that truly enters production, however, should meet a higher standard than code written by humans.

“It Works” Is Only the Starting Point for AI-Generated Code

In the past, code quality was often constrained along with human productivity. How much code an engineer could write in a day and how many features a team could complete in an iteration determined the rate at which system complexity grew.

AI has broken that constraint, but it has also introduced a new risk: code production has accelerated, while review and maintenance have not accelerated in parallel.

It is like expanding a construction crew from ten people to one hundred while leaving the inspection team at only two people. Buildings can go up faster, but hidden problems will accumulate faster as well. The biggest problem with model-generated code is usually not that every line is obviously wrong, but that after many locally reasonable implementations are layered together, the overall architecture begins to become fragile.

Common situations include:

• To complete the current requirement, the model reimplements logic that already exists, creating code forks;
• An interface appears to remain compatible on the surface, while exception handling, permission checks, and edge cases are inconsistent;
• Tests cover only the normal path, leaving null values, concurrency, timeouts, and retry logic unaddressed;
• To make the build pass, the generated code introduces unnecessary dependencies;
• Implicit constraints between modules are not included in the context, so the model can only make locally optimal choices;
• The code passes static checks but is difficult for the next engineer to understand and modify.

These problems are difficult to solve through a single manual read-through. They require a combination of standards, testing, automated review, and continuous maintenance of the system context.

Anthropic’s Answer: Bring Quality Control into the Automated Pipeline

Cherny mentioned that Anthropic has established multiple layers of protection for production code generated by Claude, including code-standard checks, tests, Claude-driven end-to-end tests, daily fuzz testing, automated code review, security review, and automated refactoring.

The focus of this approach is not to “make the model generate perfect code in one attempt,” but to acknowledge that models make mistakes and intercept as many of those mistakes as possible before they enter production.

It can be understood as a quality pipeline for AI-generated code:

1. Define the boundaries first. Through project standards, architectural constraints, directory structures, and interface conventions, tell the model what it can change and what it cannot touch.
2. Then verify behavior. Run unit, integration, and end-to-end tests. Do not check only whether the code compiles; also check whether it matches business expectations.
3. Continue checking for risks. Pay attention to permissions, data leakage, dependency vulnerabilities, injection risks, performance degradation, and exception handling.
4. Make a human judgment at the end. Automated tools can identify a large number of problems, but they cannot decide on the team’s behalf whether a piece of code truly aligns with the system’s long-term evolution.

This is also where AI programming tools differ from traditional code-completion tools. Completion tools mainly solve the problem of “how to write the next line,” whereas tools like Claude Code are participating in longer chains of work: reading a repository, understanding requirements, modifying multiple files, running tests, and then continuing to iterate based on feedback. As the scope of tasks expands, quality control cannot remain limited to syntax hints inside the IDE.

Cherny believes that as model capabilities improve, it will become easier to run fixed testing, review, and security processes every day. This is important: AI is not only a code generator; it can also become part of the testing and review pipeline.

But one premise here cannot be ignored—the AI reviewing AI can also make mistakes. Therefore, automated review is suitable for expanding coverage, but not for replacing the party responsible. For authentication, payments, permissions, privacy, and core data pipelines, human review remains the final gate.

Developers Are Becoming “Mini CEOs”

Cherny calls this new role a “mini CEO.” This phrase can easily be misunderstood to mean that developers need to become product managers or executives, but what it really emphasizes is that developers’ focus is shifting from “personally completing implementation” to “making the right trade-offs and taking responsibility for the outcome.”

After AI becomes involved in development, developers need to make more judgments:

• Is this requirement worth implementing, or is it only a one-off validation?
• Which modules can the model generate freely, and which must have a restricted modification scope?
• Does this code fit the existing architecture, rather than merely fixing the error in front of us?
• Do the tests cover genuinely dangerous failure paths?
• When the code is handed to the next person, can they understand it without help from a model?
• If the model’s implementation conflicts with the technical plan, should the team rework the implementation or adjust the plan?

In the past, writing code itself was a way of understanding a system. Developers built mental models through typing, debugging, and refactoring. Now, if large amounts of implementation work are handed over to AI without making up for the reading, verification, and decision-making steps, developers may develop a dangerous illusion: the project is moving quickly, but their own understanding of the system is becoming thinner.

This is also why many people find AI programming “convenient but lonely.” When machines take over most of the code-typing work, if humans are left only with accepting tasks, copying prompts, and checking the final page, the technical feedback provided by the work will decline significantly. Programmers are no longer pulled along by every implementation detail, but they must actively design new feedback mechanisms.

Responsibility Is Not Outsourced to the Model Along with Code Generation

The easiest thing to blur after AI generates code is the boundary of responsibility. The code was written by a model, the prompt was written by a person, the requirements may have come from a product manager, and the tests may have been performed by another automated system—who is responsible when something goes wrong?

From an engineering perspective, the answer has not changed: the person who submits the code remains responsible for it. A model can be an implementation tool, but it cannot be the party responsible.

This means “I only had AI write it” cannot serve as an explanation after a production incident. Developers do not necessarily need to remember every character, but they must know the code’s purpose, boundaries, dependencies, and risks, and be able to demonstrate through tests, reviews, and operational data that it meets requirements.

For teams, the truly effective approach is not to require everyone to handwrite every line again, but to embed “understanding and responsibility” into the delivery process: submission records should explain the scope of changes, code reviews should check architecture and risks, test results should be traceable, and the context and constraints used by the model should be preserved as project assets.

In the Age of AI Programming, Judgment Is the Scarcest Resource

In the short term, AI will significantly increase the speed of feature development. Especially for modules with relatively clear business logic, mature technology stacks, and sufficient test coverage, models can take on a large amount of repetitive implementation work. Developers will have more time to handle architectural design, complex debugging, and cross-team collaboration.

In the long term, speed itself is not a competitive advantage. Once everyone can call more powerful models, the gap will shift to three areas:

1. Can you define the problem clearly?

Ambiguous requirements will be amplified by AI into large quantities of seemingly reasonable code. Excellent developers must first be able to break down goals, clarify constraints, and identify risks, rather than rushing to have the model start generating.

2. Can you establish high-quality feedback?

Tests, logs, type systems, code standards, and architecture documentation are no longer merely maintenance costs; they are feedback mechanisms that provide direction to the model. Without feedback, the model can only make probabilistic guesses; the more specific the feedback, the more reliable the iteration.

3. Can you safeguard long-term quality?

Models are good at completing local tasks, while humans need to take responsibility for the system’s life cycle. Which technical debt is acceptable and which complexity will explode in the future ultimately still requires judgment from experienced engineers.

For individual developers, the more important skills in the future may not be memorizing every API of a particular framework, but understanding system boundaries, recognizing abnormal patterns, designing validation plans, and knowing when to stop and rethink in situations of uncertainty.

Do Not Turn “Vibe Coding” into a Production Standard

“Vibe coding” is not without value. It is suitable for exploring new ideas, generating boilerplate code, building internal tools, and rapidly experimenting in low-risk scenarios. The problem is that many teams bring the way they work during the prototype stage directly into production.

A prototype can focus only on results because its value is helping the team answer the question, “Is this direction worth pursuing?” Production code must answer more questions at the same time: Is it stable? Is it secure? Can it scale? Can it be maintained? Can it be rolled back if something goes wrong?

These two sets of standards cannot be mixed.

A more realistic AI programming workflow should be “fast first, strict later”: during exploration, allow the model to generate and modify code rapidly; once the decision is made to enter production, switch to strict branch protection, test gates, code review, security scanning, and release rollback mechanisms. Use speed to shorten the trial-and-error cycle, and quality mechanisms to control system risk.

Perhaps this is also the most valuable aspect of Cherny’s remarks: he did not simply encourage developers to embrace AI, nor did he mythologize “handwritten code” as the only correct approach to engineering. Instead, he returned the discussion to the context in which code is used. A black box is not inherently wrong; losing boundaries is.

Conclusion: From People Who Write Code to People Who Safeguard Quality

What AI programming truly changes is not only the amount of work done at the keyboard, but also the allocation of responsibility in software engineering. Models can generate more code and may even participate in testing, review, and refactoring; but whether a system should accept that code still requires human judgment.

Future developers may not personally write large amounts of code every day, but they must know more clearly than ever: which code is worth keeping, which code should be rewritten, which code can remain only in a prototype, and which risks must never be left for a probabilistic model to decide.

“Safeguarding code quality” sounds slower than “writing more code,” but for systems that truly run over the long term, it is the faster, cheaper, and more reliable path. AI has lowered the barrier to implementation, but the barrier to engineering judgment has risen.

Sources

• ITHome: “Father of Claude Code” Cherny on AI Programming: Developers’ Core Responsibility Is to Safeguard Code Quality — Reports on Cherny’s public sharing of the developer’s email and his response regarding quality standards for prototype and production code.