Karpaci AI Coding Guidelines Explanation: Why coding agents should design verification loops, stopping conditions, and CLAUDE.md boundaries before prompts

AI Times reported on June 29, 2026 that an AI coding guideline document believed to have been written by Andrei Karpacy is spreading in the developer community. Although the authenticity has not yet been confirmed, the reason why this news is important is not only because of the name value. This is because we are moving from the stage where developers tell AI to “code well” to the stage where AI designs a work loop where it tests itself, stops and looks back.

1. One-line problem definition

Key one line: The bottleneck of an AI coding agent is not the prompt statement, but the verification loop that prevents it from continuing to work in the wrong direction.

For beginner developers, a coding agent is not a “chatbot that writes code for you.” It is more like an automated worker that reads files, executes commands, runs tests, and continues through multiple steps. So, what to check and when to stop while working becomes more important than the quality of a single answer.

The target readers of this article are developers and team leads who want to put Claude Code, Codex, Cursor, and Copilot tools into practice. The scope is not to determine the authenticity of a specific leaked document, but how to turn AI coding work instructions into operating rules. If you are only doing simple Q&A or generating small code snippets, this structure may be a bit overkill.

2. First, conclusion

Key one-liners: The job of the team now is not to find a “better prompt,” but to create a work manual that replicates failures and fixes passing criteria.

According to the AI ​​Times article, this document is known as 10 rules that add items such as verification, debugging, dependability, communication, and common failure patterns to the existing four principles. In particular, the key point is that it should be reproduced in tests and passed again, rather than “it seems to have been fixed”.

I see this trend as a bigger signal than whether Karpaci has personal documents. The competitiveness of AI coding is not determined by the model name, but by the standards by which the agent reads, plans, modifies, verifies, and stops. Claude Code's official documentation also explains that the agent can repeat itself by giving verification signals such as test, build, or screenshot to the task.

Recommended for teams that want to leave repetitive bug fixing, test enhancement, refactoring, documentation, and migration to AI. Not recommended are teams that say “let’s start with automation” without testing or completion criteria. In that case, the faster the AI, the faster the incorrect changes spread.

3. Decomposition of core structure

Key one-liners: Good AI coding guidelines are divided into four layers: prompt phrases, project memory, verification commands, and abort conditions.

• Action Intent Layer: Converts the user's desired result into a mechanically verifiable statement. For example, “return an error on empty and malformed emails and the test passes” is better than “add input validation”.
• Project memory layer: CLAUDE.md, AGENTS.md, like a skill document, places rules that the agent must read every time. Claude Code's official documentation explains that CLAUDE.md is read at the start of each session, but is context, not mandatory.
• Verification Gate Layer: Gives clear pass/fail signals like tests, typechecks, lints, builds, screenshot comparisons. Without this signal, the agent stops at “looks good”.
• Stop Condition Layer: If you see a failure pattern such as Kitchen Sink, Wrong Abstraction, Optimistic Path, or Runaway Refactor, stop it instead of continuing. Without this layer, small modifications can lead to excessive structural changes.

The important thing is that the four layers are not substitutes for each other. A good prompt is not enough, and even just CLAUDE.md is not enough. You need to give the agent rules to remember, validations to run, and even the authority to stop when it encounters a failure pattern.

4. Description of design intent

Key one line: The intent of the rules is not to make AI more confident, but to reduce unfounded confidence.

Human developers also reproduce bugs first when fixing them. Find out what input is failing, create a test that fails, change the code, and see if the same test passes. AI agents also need this procedure. The reason is that AI is very good at giving plausible explanations.

What is noteworthy in this guideline is that it has moved from “Think before writing” to “Verify after writing, and stop if it is a failure pattern.” If prompt engineering is a technique for refining request sentences, loop engineering is a technique for designing what signals workers will see at each step and choose the next action.

What this design gains is stability. Reviews become easier when you leave test results, error messages, diff scopes, and reasons for adding dependencies. There is also giving up. Each operation incurs the cost of writing completion criteria and verification commands. However, for long coding agents or auto-correction loops, this cost acts as insurance.

5. Evidence and Comparison

Key one line: The comparison criteria is not “Is the answer smart”, but “Is the work verifiable and reversible?”

Claude Code official document emphasizes, “Give a way to verify.” Giving the agent a readable signal, such as a test, build exit code, or screenshot comparison, closes the loop for the worker to view the results and fix them again. Additionally, the /goal document describes a structure in which a separate evaluation model checks whether conditions are met at each turn to continue working.

In contrast, the CLAUDE.md document clearly states that this file is a context, not an enforcement policy. So when it comes to security or blocking risky behavior, you can't just rely on instruction files. If you need actual blocking, you'll need execution controls like PreToolUse hooks, permission settings, and sandboxes.

6. Actual operation flow / step-by-step execution method

Key line: When applying it to a team, it's better to fix a small bug fix loop first than a big rule book.

1. Choose three recurring failures. Example: Claiming modifications completed without testing, adding unnecessary dependencies, modifying one file turning into a large refactoring.
2. Turn each failure into a stopping condition. Example: check existing dependencies before adding a new package, recheck plan when changing more than 5 files, do not complete bug fixes without repro tests.
3. Short write in project instruction file. A 20-line validation rule is better followed than a 200-line philosophy document.
4. Pin the verification commands. Example: pnpm test, pnpm typecheck, specific test files, compare Playwright screenshots.
5. Insert completion criteria into the task prompt. Instead of asking “Please fix it,” ask “Write a failing test → Modify → Present test passing output”.
6. See evidence in reviews. Check actual executed commands, failure logs, pass logs, and number of changed files before code descriptions.

#CLAUDE.md example: Coding agent action rules

## Verification
- Bug fixes are not claimed as complete without tests or command output that reproduce the failure.
- Summarize related test and type check results after implementation.

## Scope Control
- Do not add new features beyond the scope of the request.
- If the number of changed files exceeds 5, present the plan again before continuing.

## Dependencies
- Before adding a new package, check if the problem can be solved with existing libraries and standard libraries.
- If added, leave the reason and alternative in the PR description.

## Stop Conditions
- If you are fixing several parts at the same time without checking the cause, stop.
- If you see code that assumes only normal input, add edge case tests first.

Example work request:
When I refresh after the login session expires, the 401 is repeated.
First, add a test that reproduces the failure,
Explain the cause and fix it with minimal changes.
Completion criteria include passing relevant tests and passing pnpm typecheck.

7. Pitfalls

Key one line: AI coding rules are better when you can actually make them stop, not when longer is better.

1. Trap: Misunderstand CLAUDE.md as a one-size-fits-all policy.
   Prevention: Instructions file Context, and forced blocking is separated into hook·permission·sandbox.
   Recovery: Dangerous commands, external transmission, and secret access are moved to the PreToolUse hook or permission policy.
2. Pitfall: Write the rule too long.
   Prevention: Based on “Will removing it lead to more mistakes?” Keep only the key points within 20 to 50 lines.
   Recovery: Extract long tutorials into separate documents or skills, and keep the rules for each session short.
3. Pitfall: Only auto-repeat is turned on in a repo without tests.
   Prevention: First, do a replay test on the one flow that breaks most often. Create.
   Recovery: For areas without tests, leave any one of script, sample input, screenshot, and type check as a pass signal.
4. Trap: Let it continue even if it discovers a failure pattern.
   Prevention: Kitchen Sink, Wrong Abstraction, Optimistic Path, Write Runaway Refactor as an explicit stopping condition.
   Recovery: The moment the scope of change becomes large, summarize the current diff and break the loop to get a new plan approved.
5. Pitfall: Humans do not re-examine the verification done by AI.
   Prevention: Minimum command, exit code, pass change after failure, change file. The list is checked in PR.
   Recovery: Results with only the sentence “passed” are rejected and actual output basis is requested.

8. Strengths and Limitations

Key one line: Verification loops increase the quality of AI coding, but they do not automatically fix bad completion criteria.

There are three strengths. First, the results of the agent's actions can be quickly judged by human reviewers. Second, when you repeat the same mistake, you can leave behind rules to prevent recurrence with instruction files and verification commands. Third, even for long-time work, you can check “when it is finished” with tests and target conditions.

The limitations are also clear. If the completion criteria are incorrect, the agent may faithfully satisfy the incorrect criteria. If your tests are poor, bugs will remain even if they pass. Also, if CLAUDE.md is too long or ambiguous, it will work weaker than the actual work instruction.

So, I see this method not as “a way to trust AI” but as a “way to automate the process of doubting AI.” Good teams give agents freedom, but are clearer about what evidence they need to pass and what conditions they need to stop under.

9. Points to study more deeply

Key one-liners: This topic should be studied in conjunction with test strategies, working memory, hooks, and permission models rather than how to write prompts.

• Project memory: Check where CLAUDE.md is loaded and what content is appropriate for each session.
• Verification signal: Determine the minimum signal suitable for the repo during test, build, lint, type check, and screenshot comparison.
• Goal-based iteration: Experiment with a method in which completion conditions are checked by a separate evaluator, such as /goal.
• Hooks and Permissions: See how to prevent risky behavior at the execution stage that cannot be enforced with an instruction file.
• Review process: In the PR description, leave the verification performed by AI, the scope of change, and whether the stopping condition was violated.

If you are a novice developer, rather than looking for a “good collection of prompts,” it is better to start by organizing “what commands clearly indicate success/failure” in your project. That command is the dashboard of the AI ​​coding loop.

10. Action Checklist + Author's Perspective

Key line: The standard for completion of introduction is not the day the rule file was created, but the day the AI ​​stops repeating the same failure.

Definition of Done: The first round of introduction is considered complete when the team's five representative AI coding tasks have reproduced failures, minimal changes, passed relevant verifications, summarized the scope of changes, and have no violation of stopping conditions as PR evidence.

From the author's point of view, the key point of this news is not “Did Karpassi write it?” but “AI coding should be viewed as an operable loop rather than a single prompt.” I don't recommend a long rulebook for every development team. Instead, I recommend picking a frequently broken task and fixing the Reproduce failure → Modify → Verify → Check stopping conditions loop first. It is correct to expand agent work for a long time only after this small loop is stable.

Reference material

• AI Times - ‘Karpathi AI coding guidelines’ spread... "Evolving from the prompt to the loop era" (Publication date: 2026-06-29)
• Claude Code Docs - Best practices for Claude Code (Confirmation date: 2026-06-29)
• Claude Code Docs - How Claude remembers your project (Confirmation date: 2026-06-29)
• Claude Code Docs - Keep Claude working toward a goal (Confirmation date: 2026-06-29)
• Claude Code Docs - Hooks reference (Confirmation date: 2026-06-29)