Claude Doesn't Submit Code Directly After Writing It: Runs 4 Skills for Self-Check, Fixes Issues, Then Comes Back to You

marsbitОпубліковано о 2026-07-27Востаннє оновлено о 2026-07-27

Анотація

Claude No Longer Submits Code Directly: 4 Self-Check Skills to Run Before Coming Back to You AI already writes code, but the burden of reviewing it still falls on you. To address this, Anthropic has built a "verification loop" into Claude Code. After writing code, Claude now runs four self-check skills before delivering the work: * `/code-review`: Finds potential bugs and provides review feedback. * `/simplify`: Cleans up the diff, removing redundant or over-complex implementations to reduce future maintenance costs. * `/verify`: Performs end-to-end validation, actually running the application to confirm the feature works, not just appears to. * `/design`: Used only for UI changes; cross-references the implementation against the project's DESIGN.md file. This loop extends the AI agent's workflow from "gather context → execute" to "gather context → execute → auto-verify → fix → re-verify." It tackles the new bottleneck in AI-assisted development: the speed of verifying code now outpaces human review. These skills are built on Claude Code's existing verification foundation (like running apps and using linters). Teams can create their own custom verification skills by documenting their repetitive manual checks in plain language as Markdown files. Verification can be triggered at four levels: manually (Standalone), embedded in a task, chained with other skills, or automatically on every PR (On every PR). The shift signifies that competition in AI programming is movin...

AI has taken over the task of writing code. But the job of acceptance still falls on you.

Whether a piece of code is written correctly or not is not AI's responsibility; ultimately, you still have to go through it line by line. This hurdle has stumped many people.

Recently, Anthropic has also integrated AI acceptance into the loop.

They made Claude, after writing code, not immediately hand it over. Instead, it runs four checks itself first:

/code-review to root out bugs, /simplify to clean up redundant implementations, /verify to perform end-to-end verification, and if the UI was touched this time, use /design to cross-check against the visual specifications in DESIGN.md.

Only after running through all four does it count as delivered.

On July 22nd, the Claude Code team publicly shared this internal "verification loop."

In other words, after Claude writes code, it first finds and fixes errors on its own before coming back to you.

This signifies AI evolving from "being able to write code" to "being able to check the code it wrote."

Agent Work Loop Gains an Extra Verification Step

Anthropic gave this system a name: the verification loop.

The official definition is simple: it's an iterative process where Claude checks and attempts to fix its own work.

What it changes is the agent's work cycle.

Previously, it was "gather context → execute action → manual check." The final step rested on humans: the AI hands over the work, and you have to review it line by line.

Now this line is extended to "gather context → execute action → automatic verification → fix → verify again." Checking and fixing are placed back inside the loop.

Anthropic's official agent cycle diagram: after a prompt comes in, Claude gathers context, executes actions, verifies results. If verification fails, it loops back; only when it passes does it return.

Some checks Claude already knows how to do. Deterministic signals in the codebase, like type checker, linter, running tests, runtime errors—it can read these and will fix them as it goes.

The real trouble lies with another category: whether the UI changes are correct, whether the user flow is smooth, whether this change has buried unseen pitfalls...

In the past, these could only be caught by humans watching, performing the same checks dozens or hundreds of times.

Anthropic's solution is to write down each of those manual checks you perform every time, package them into Skills, and have Claude execute them automatically for each task.

For decades, all software engineering processes—writing requirements, planning, layer upon layer of reviews, endless meetings—were essentially because: writing code was too slow, and engineers' time was too valuable.

But when AI makes the act of writing code faster and cheaper, this premise disappears.

The Claude Code team's own assessment is: the bottleneck hasn't vanished; it has merely shifted: from "writing code" to verification, code review, security, and other such stages.

Code is generated too quickly. The new problem becomes: are these codes correct, who will maintain them, can people keep up with the pace of reviewing code.

Faced with this new bottleneck, the Claude Code team first experimented on themselves.

The 4 Self-Check Skills the Claude Code Team Uses Daily

Internally, the Claude Code team uses these four self-check Skills every day.

/code-review, specialized in reviewing code changes, rooting out potential bugs, and providing review comments along the way.

This is like having a tireless reviewer on standby.

/simplify, cleans up the diff for this change, removing convoluted, complex implementations to make the structure simpler.

It doesn't add features for you; instead, it removes redundancy, simplifies implementation, pushing down future maintenance costs.

This point is crucial and requires real skill. Most people write code by adding more; tools that proactively simplify are particularly valuable.

/verify, performs end-to-end verification, actually running things to confirm the feature is truly complete, not just "looks complete."

/design, only comes into play when the UI is touched. It cross-checks against the DESIGN.md in the repository, verifying point by point if your visual implementation has deviated.

These 4 Skills didn't appear out of thin air.

Underlying them, Claude Code has already laid a foundation of existing verification support:

The built-in /verify can run the application to observe changes; you specify the build and test commands in CLAUDE.md, and it follows them. There's also Code Review specifically for multi-agent reviews on PRs, and GitHub Actions that automatically trigger on every commit.

The team's 4 Skills are like adding their own layer of process on top of this general foundation.

How to Write Your Own Verification Skill?

Anthropic's method is also simple:

Write down that manual step you always perform in plain language, as if you were explaining precautions to a new colleague on their first day.

If you're even stuck on how to describe this check step, you can first ask Claude to provide a version of general best practices and then modify it.

Your version will likely differ from the generic approach at a few key points, and those differences are precisely the things most worth documenting.

Checks don't necessarily have to be vague judgments like "feels right or not."

For example: any change that deletes a database field without an accompanying data migration step should be rejected. This is a "local rule" that a generic linter will never catch but is specific to your project.

Any rule you've only been able to enforce by manually watching like a hawk is worth writing into a loop.

What to do after writing it?

Throw it to skill-creator to have it interview you back, or simply drop a Markdown file into .claude/skills/.

The simplest verification Skill is a few lines of instructions plus a body paragraph. Then test it once on a new task to confirm this check step actually runs. If not, fix it.

For Skills you can't modify, like built-in ones or those hosted by plugins, there's a workaround: write a wrapper Skill that first calls the original, then calls your verification. A detour, but it still embeds the check.

Verification Isn't One-Size-Fits-All; It Has 4 Levels

After packaging checks into Skills, the next question is: when should this thing trigger?

Anthropic provides 4 levels of automation, from loose to tight.

Standalone: You remember to manually invoke it.

Embedded: Embedded into a specific task flow, running alongside it.

Chained: Several verification Skills strung into a chain, automatically running one after another.

On every PR: The strictest level, automatically running on every code commit.

The official term for the middle layer transition is "from habit to contract."

What was "I always remember to run /verify after /simplify" as a personal habit becomes "automatically call /verify after /simplify runs" as a fixed contract once chained.

The entire chain completes the development loop on its own, only coming back to you when your approval is needed.

The longer the chain, the higher the reliability, but the official team specifically cautioned: chained verification will genuinely burn through tokens.

So don't immediately set all checks as PR gates that block every commit. The right approach is to first see if it's stable, then gradually add more.

Behind the 4 Skills: AI Programming is Changing Tracks

Behind the 4 Skills, the competition in AI programming is shifting from generation to verification.

The creator of Claude Code has given the same assessment.

On June 9th of this year, he tweeted: In an era where powerful models can run autonomously for long periods, self-verification is key to letting models run longer and produce results closer to your expectations. You don't have to watch Claude frequently to hand over more work.

Simply put, the more solid the verification, the more confidently an agent can run; the longer it runs, the less hassle for humans.

In the past, we relied on prompts, but they have a ceiling too: they only solve the task at hand; next time you start from scratch.

Let's first correct a common misunderstanding: A Skill is not a piece of Markdown prompt.

It's a capability module containing instructions, file structure, scripts, tool calls, configuration, and an entire workflow. It's about solidifying a team's check steps, design norms, and lessons learned into a package readily available for Claude to reference when needed.

More crucially, Skills are evolving from a feature of Claude Code into an open standard across vendors.

According to industry analysis, GitHub Copilot, Cursor, OpenAI Codex, and Gemini CLI have already adopted the same format.

This means the Skills you solidify for your team won't be locked into one specific tool. They will encapsulate your team's experience, norms, and check processes, turning into reusable capabilities.

This also highlights a stark reality: the same Claude might yield efficiency differences of several times between different teams. This gap isn't due to the model but rather the workflow:

Have you written checks into Skills? Have you set up verification loops? Have you enabled the agent to run its own feedback loop to completion?

Ultimately, an agent's capability is an addition problem: model, plus tools, plus verification mechanisms, plus workflow.

The model aspect is becoming more similar across vendors. What truly creates distance are the latter three items, all of which are in the user's hands.

Of course, what this blog post demonstrates is the process optimization of AI-assisted development, not "AI can already write software independently." It still requires engineers and cannot handle production-grade delivery without humans.

Therefore, it's not about agents coming to take human engineers' jobs, but the direction is already clear.

In the past, we've been teaching AI how to write code. Now we need to start teaching it to verify if what it wrote is correct.

For someone who uses AI to write code every day, the day when "having to manually review everything before leaving work" can finally be entrusted to AI with peace of mind is the day it truly starts carrying the load for you.

References:

https://claude.com/blog/building-verification-loops-in-claude-code-with-skills

https://claude.com/blog/getting-started-with-loops?utm_source=chatgpt.com

This article is from the WeChat public account "New Zhiyuan", author: ASI Revelation

Трендові криптовалюти

Пов'язані питання

QWhat is the core innovation described in the article regarding Claude's code generation?

AThe core innovation is the introduction of a 'verification loop' where Claude, after writing code, automatically runs it through four specialized Skill checks (code-review, simplify, verify, design) to find and fix errors before delivering the final code to the user.

QWhat are the four primary verification Skills used by the Claude Code team internally?

AThe four primary Skills are: /code-review (to catch potential bugs and provide review comments), /simplify (to clean up and streamline the implementation), /verify (to perform end-to-end functional verification), and /design (to ensure UI changes align with a project's DESIGN.md file).

QWhat is the key difference between a traditional AI coding workflow and the new 'verification loop' workflow?

AThe traditional workflow is: 'collect context -> execute action -> human review'. The new 'verification loop' workflow extends this to: 'collect context -> execute action -> automatic verification -> repair -> re-verify', embedding the review and repair steps back into an automated loop before returning to the user.

QAccording to the article, what is the main 'bottleneck' that has shifted as AI code generation becomes faster?

AThe main bottleneck has shifted from 'writing code' to the verification, code review, and security aspects. The article states that the new problem is ensuring the rapidly generated code is correct, maintainable, and can be reviewed at the required pace.

QHow does the article describe the nature and importance of 'Skills' compared to simple prompts?

AA Skill is described not as a simple prompt, but as a modular capability package. It contains instructions, file structures, scripts, tool calls, configurations, and workflows. It is a way to encapsulate a team's review steps, design standards, and learned lessons into a reusable asset that Claude can access autonomously.

Пов'язані матеріали

Take a Calm Look at Domestic Lithography Machines: 5 Units Delivered, How Far Are We from Challenging ASML?

This article analyzes recent news about China's domestic DUV lithography machines, advising a measured perspective. A state-backed enterprise plans to deliver about 5 immersion DUV systems this year, with a 2027 target of 20 units, aimed at 28nm processes. While this marks a step from R&D into initial customer validation, the author cautions against over-optimism. The piece clarifies this is DUV, not EUV technology. DUV is crucial but cannot economically solve challenges for advanced nodes like 5nm or below, where EUV is key. The 5-unit volume is minimal compared to ASML's annual output of over 130 such machines. The author highlights unverified claims regarding specs like 90% yield and warns against conflating this news with unconfirmed reports about Shanghai Micro Electronics' production. China's EUV efforts, while progressing with a prototype, remain in early testing, facing significant hurdles in core components like high-precision optics. The analogy of a "DeepSeek moment" is deemed misleading, as lithography involves slow, iterative precision engineering, not rapid software-like breakthroughs. Current progress represents establishing a potential second supply source and gaining vital engineering experience rather than an imminent industry disruption. For investors, the key indicators to watch are formal customer acceptance, stable operational performance, repeat orders, and growth in production volume and component localization. The conclusion is that this is a positive but early-stage development, far from altering the global competitive landscape.

marsbit15 хв тому

Take a Calm Look at Domestic Lithography Machines: 5 Units Delivered, How Far Are We from Challenging ASML?

marsbit15 хв тому

The 800x Golden Dog, "Gacha" Saves NFT Trading

Title: 800x Golden Dog: How 'Gacha' Mechanics Are Rescuing NFT Trading In the past month, the on-chain TCG (Trading Card Game) narrative, centered around "gacha" or loot box mechanics, has emerged as a major crypto-native revenue generator, second only to platforms like Hyperliquid and pump.fun. Recently, this trend hit Ethereum with Fake World Assets (FWA). Within just over a week, FWA generated approximately $1.3 million in revenue, ranking 15th in the past week's crypto app earnings. Its token, $FWA, surged from an initial market cap of ~$47,550 to a peak of ~$38.8 million—an 800x gain. Meanwhile, Collector Cards' token $CARDS declined significantly from its previous highs. FWA, developed by the team behind "PunkStrategy," operates as an NFT gacha system with a built-in token flywheel. Users deposit NFTs paired with ETH as liquidity into pools. Each deposit creates a personal pool; more ETH deposited lowers the chance of the NFT being "won" in a draw. Players spend ETH to "draw" (gacha). If they get an undesirable NFT, they can instantly sell it back to the original depositor at an 85% discount, generating income for the depositor. A 1% fee is taken on each draw and on depositor earnings when an NFT is kept. The key to FWA's momentum is its token $FWA. It cannot be bought directly externally. The primary way to acquire it is by playing the gacha and choosing to receive $FWA (instead of ETH) when selling back an unwanted NFT. This mechanism creates constant buy pressure for $FWA as players engage, especially during its price ascent. Early participants who held $FWA benefited massively from subsequent inflows. This contrasts with projects like Collector Cards, which, despite strong revenues, suffer from perceived low token utility beyond buybacks. In conclusion, while FWA's flywheel design—linking speculative token gains directly to NFT trading activity—has driven rapid growth, its sustainability is questionable. The model relies heavily on continuous $FWA price appreciation to offset the inherent negative expectancy of each draw. When price momentum stalls, activity will likely decline. The case highlights that in crypto markets, pure profitability narratives can be fleeting; understanding the relationship between attention, token buy pressure, and sustainable mechanics is crucial to avoid speculative pitfalls.

marsbit40 хв тому

The 800x Golden Dog, "Gacha" Saves NFT Trading

marsbit40 хв тому

The Quantum Computing Threat Approaches, Cryptocurrency May Be Exposed to Risks Before Banks

Quantum computing poses a significant threat to all cryptographic systems, including banks and governments, but decentralized cryptocurrencies with public ledgers like Bitcoin are likely the first practical target. Experts warn that a cryptographically relevant quantum computer (CRQC), capable of running Shor's algorithm to break the elliptic curve cryptography securing most crypto wallets, could emerge around 2029. Recent research shows the required quantum resources for such attacks are shrinking dramatically, potentially enabling key extraction in minutes. The core vulnerability for cryptocurrencies is not the cryptography itself—post-quantum standards are being developed—but the slow, decentralized governance required to implement upgrades. Unlike centralized banks that can swiftly transition, Bitcoin needs near-unanimous consensus among its global network, a historically difficult process as seen in past upgrades. Estimates suggest migrating all vulnerable Bitcoin funds could take at least 76 days of dedicated network time, and it must be completed before a CRQC exists to prevent "now-or-never" attacks on exposed keys. The threat is not binary; it begins when a quantum computer can decrypt data before it loses value, not necessarily in real-time. A significant portion of Bitcoin (estimated at millions of coins) already has public keys permanently exposed on-chain, making them vulnerable to eventual "static attacks." While technical solutions exist, the race is against time for decentralized networks to coordinate a defensive transition, serving as an early warning for the broader financial system.

marsbit51 хв тому

The Quantum Computing Threat Approaches, Cryptocurrency May Be Exposed to Risks Before Banks

marsbit51 хв тому

Торгівля

Спот

Популярні статті

Як купити 4

Ласкаво просимо до HTX.com! Ми зробили покупку 4 (4) простою та зручною. Дотримуйтесь нашої покрокової інструкції, щоб розпочати свою криптовалютну подорож.Крок 1: Створіть обліковий запис на HTXВикористовуйте свою електронну пошту або номер телефону, щоб зареєструвати обліковий запис на HTX безплатно. Пройдіть безпроблемну реєстрацію й отримайте доступ до всіх функцій.ЗареєструватисьКрок 2: Перейдіть до розділу Купити крипту і виберіть спосіб оплатиКредитна/дебетова картка: використовуйте вашу картку Visa або Mastercard, щоб миттєво купити 4 (4).Баланс: використовуйте кошти з балансу вашого рахунку HTX для безперешкодної торгівлі.Треті особи: ми додали популярні способи оплати, такі як Google Pay та Apple Pay, щоб підвищити зручність.P2P: Торгуйте безпосередньо з іншими користувачами на HTX.Позабіржова торгівля (OTC): ми пропонуємо індивідуальні послуги та конкурентні обмінні курси для трейдерів.Крок 3: Зберігайте свої 4 (4)Після придбання 4 (4) збережіть його у своєму обліковому записі на HTX. Крім того, ви можете відправити його в інше місце за допомогою блокчейн-переказу або використовувати його для торгівлі іншими криптовалютами.Крок 4: Торгівля 4 (4)Легко торгуйте 4 (4) на спотовому ринку HTX. Просто увійдіть до свого облікового запису, виберіть торгову пару, укладайте угоди та спостерігайте за ними в режимі реального часу. Ми пропонуємо зручний досвід як для початківців, так і для досвідчених трейдерів.

483 переглядів усьогоОпубліковано 2025.10.20Оновлено 2026.06.02

Як купити 4

Обговорення

Ласкаво просимо до спільноти HTX. Тут ви можете бути в курсі останніх подій розвитку платформи та отримати доступ до професійної ринкової інформації. Нижче представлені думки користувачів щодо ціни 4 (4).

活动图片