Anthropic has laid out an internal “verification loop” used by the Claude Code team, a workflow that has Claude check its own coding work before handing results back to the user.
Under the setup described by the company, Claude does not stop after generating code. It first runs four checks on its own output: /code-review, /simplify, /verify, and, when the user interface has been changed, /design. Only after those steps are complete is the work treated as delivered.
The Claude Code team made the internal process public on July 22. In practical terms, the system has Claude look for mistakes in its own code, make corrections, and return only after that pass is done. The shift Anthropic is pointing to is not just code generation, but the ability to inspect code that the model has already written.
How Anthropic defines the verification loop
Anthropic calls the process a verification loop. Its definition is simple: an iterative process in which Claude checks and attempts to fix its own work.
The change sits inside the broader agent workflow. A shorter version of the loop used to look like “gather context → take action → human review,” with the last step remaining firmly in human hands. Anthropic says that path is now extended to “gather context → take action → automatically verify → repair → verify again,” moving both checking and repair back inside the loop.
In the company’s agent loop diagram, Claude receives a prompt, gathers context, performs actions and verifies the result. If verification fails, the task is sent back through the loop. If it passes, Claude returns the result.
Some forms of checking were already available to Claude. Anthropic says the model can read deterministic signals in a codebase, including a type checker, a linter, test runs and runtime errors, and it can often fix those issues directly.
The harder class of problems is less mechanical: whether a UI change is correct, whether a user flow still works cleanly, or whether a change introduces a hidden issue that is not obvious on a quick read. Those are the checks humans have traditionally had to repeat over and over.
Anthropic’s answer is to write down those recurring manual checks and package them as Skills, so Claude can run them automatically in each task.
The bottleneck is shifting from writing code to validating it
The article argues that many software engineering processes developed over decades — requirement writing, planning, layers of review and long meetings — were shaped by one basic assumption: writing code was slow, and engineers’ time was expensive.
As AI speeds up code generation and lowers its cost, that assumption changes. The Claude Code team’s view is that the bottleneck has not disappeared. It has moved from writing code toward validation, code review and security.
When code can be generated very quickly, a different set of questions moves to the front: whether the code is actually correct, who will maintain it, and whether people can still keep pace with the review load. Anthropic says the Claude Code team began by testing this on its own workflow.
The four self-check Skills used daily by the Claude Code team
The team says it uses four self-check Skills every day.
/code-review: inspect the change and surface likely bugs
/code-review is aimed at reviewing code changes, identifying potential bugs and producing review comments. The article frames it as giving the system a reviewer that does not tire.
/simplify: trim complexity and reduce maintenance burden
/simplify is used to clean up the diff, remove unnecessarily complex implementations and make the structure simpler. It does not add features. Its role is to cut redundancy and lower future maintenance costs.
The article puts particular weight on this point, noting that most coding work tends to accumulate more structure over time. Tools that actively subtract are rarer.
/verify: run end-to-end checks on the actual result
/verify is the end-to-end validation step. Instead of accepting code that merely looks finished, it runs the relevant flow and checks whether the feature is actually complete.
/design: compare UI changes against DESIGN.md
/design is used only when a UI has been changed. In that case, it checks the visual implementation item by item against the repository’s DESIGN.md.
Anthropic says these four Skills were built on top of verification support that Claude Code already had in place:
- the built-in /verify, which can run an application and observe changes;
- instructions in CLAUDE.md, where users can specify build and test commands for Claude to execute;
- multi-agent Code Review on pull requests;
- GitHub Actions that can be triggered automatically on each commit.
The team’s four daily Skills, in that sense, add another internal step on top of a general verification base layer.
How Anthropic says users can build their own verification Skill
Anthropic’s suggestion is straightforward: write down the recurring manual check in plain language, as if you were explaining it to a new teammate on their first day.
If the check is hard to describe from scratch, the company suggests asking Claude for a generic best-practice version first and then editing it. The article says the places where a team’s own version differs from the generic one are often the most important parts to preserve.
Those checks do not need to stay vague or subjective. One example in the article is a project rule that any change deleting a database field without a matching data migration step should be rejected. A general linter would not catch that, but a team-specific verification rule could.
Any red line that currently survives only because someone watches for it manually is a candidate for being turned into a loop.
Once written, the Skill can be handed to skill-creator to ask follow-up questions, or a user can simply place a Markdown file in .claude/skills/.
The simplest verification Skill can be just a few lines of instruction and a body of text. Anthropic says users can then test it in a new task, confirm that the check actually runs, and revise it if needed.
For Skills that cannot be edited directly, including built-in or plugin-hosted Skills, the article says there is another route: build a wrapper Skill that calls the original first and then runs the custom verification step after it. That allows the check to be inserted without changing the original component.
Four automation levels, from manual habit to fixed contract
After a check has been packaged as a Skill, the next question is when it should run. Anthropic describes four levels of automation, from loose to strict:
- Standalone: the user calls it manually when needed;
- Embedded: it is inserted into a task flow and runs as part of that workflow;
- Chained: several verification Skills are linked and run automatically in sequence;
- On every PR: the most stringent level, where checks run on every code submission.
The company describes the middle transition as moving “from habit to contract.” A personal habit such as remembering to run /verify after /simplify becomes a fixed rule once the two are chained together, so that /verify is called automatically after /simplify finishes.
At that point, the chain can carry more of the development loop on its own and return to the human only when approval is needed.
Anthropic also includes a warning: chained verification consumes tokens in a very concrete way. The article says teams should not turn every check into a pull request gate immediately. A better approach is to see whether the setup is stable and then increase automation gradually.
What the four Skills suggest about the next stage of AI coding
The article argues that these four Skills point to a broader shift in AI-assisted programming, where the competitive focus is moving from generation to verification.
It cites a June 9 post from the creator of Claude Code, who said that in a period when strong models can run autonomously for long stretches, self-verification is central to keeping the model working longer and keeping outputs closer to what users want. The point, as framed in the article, is that users no longer need to watch Claude constantly in order to hand off more work.
In that framing, stronger verification makes it safer to let an agent run for longer, and that reduces the amount of manual oversight still needed.
The article also pushes back on a common misunderstanding: a Skill is not just a Markdown prompt. It is a capability module that can include instructions, file structure, scripts, tool calls, configuration and an entire workflow. In effect, it packages a team’s checks, design standards and lessons from past mistakes into something Claude can call on when needed.
It adds another point that goes beyond Claude Code itself. According to the article, Skills are becoming an open format used across vendors, with GitHub Copilot, Cursor, OpenAI Codex and Gemini CLI already adopting the same structure.
That would mean the workflows a team records in Skills do not have to remain locked inside one tool. Team knowledge, standards and checking procedures can be retained as reusable capabilities.
The article uses that to make a broader observation: two teams using the same Claude may still end up with sharply different productivity, and the gap may not come from the model. It may come from workflow — whether checks are written into Skills, whether a verification loop exists, and whether the feedback loop has been wired so the agent can handle more of it on its own.
It describes agent capability as an additive equation: model, tools, verification mechanisms and workflow. Models are getting closer to each other, the article says. The bigger differences come from the latter three, and those are in users’ hands.
Anthropic is describing process optimization, not fully autonomous software delivery
The article closes with a clear limitation. What Anthropic has shown is a way to optimize AI-assisted development workflows, not proof that AI can independently build production software from start to finish.
Engineers are still required, and production-grade delivery still depends on people. The point is not that agents are replacing software engineers. The point, as the article puts it, is that the direction is becoming clearer: after teaching AI how to write code, the next step is teaching it how to verify whether the code it wrote is actually correct.
For people who use AI coding tools every day, that final manual review before the end of the day remains a familiar burden. The article’s argument is that AI starts to shoulder more of the real work only when that review step can be handed over with confidence.
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
The piece cites the WeChat public account “新智元” and credits the author as ASI 启示录.