Agentic coding with checks an agent can't skip

Agentic coding is AI-assisted coding where the model works through a task in a loop. It reads your code, edits files, runs commands such as your tests, reads what comes back and decides what to do next. Anthropic’s How Claude Code works (2026) calls the three phases gather context, take action and verify results. A coding agent such as Claude Code, Codex or Cursor runs that loop.

Left to itself, an agent stops when the work looks done. Agentic coding works when it can’t skip the checks that show whether the work is done. Those are a plan you approve, a brief in the repository, specs it can run and a build that fails on lint, type or test errors. Each check below comes with the evidence for it and what it costs.

Every agent feature below was checked against its own documentation on 12 October 2026.

Agentic coding vs vibe coding

Andrej Karpathy named vibe coding in a post on X in February 2025, as coding where you “forget that the code even exists”. Simon Willison’s Not all AI-assisted programming is vibe coding (2025) narrows it to one test, whether anyone reviews the code.

When I talk about vibe coding I mean building software with an LLM without reviewing the code it writes.

Agentic coding and vibe coding describe different things. Agentic coding is about how the work gets done, by an agent using tools in a loop, and vibe coding about whether anyone reads the result. Ranjan Sapkota, Konstantinos Roumeliotis and Manoj Karkee’s Vibe Coding vs. Agentic Coding (2025) describe agentic coding as goal-driven agents that plan, execute, test and iterate “with minimal human intervention”.

An agent working like that is still vibe coding if nobody reads what it writes. You stay in the loop below at two points, the plan and your final review. Checks cover the steps between them.

Approve a plan before the agent builds

AI1 The Intern Pattern runs every change through plan, approve, execute and review. The agent writes a plan that names the files it will touch, the decisions it makes and how it will check the result. It changes nothing until you approve it. Anthropic’s Best practices for Claude Code (2026) gives the reason: “Letting Claude jump straight to coding can produce code that solves the wrong problem.”

Claude Code and Cursor both build this in as a plan mode, reached with Shift+Tab:

• In Claude Code’s plan mode the agent reads files and answers questions without making changes. Ctrl+G opens the plan in your editor, and approving the plan ends plan mode.
• Cursor’s Plan Mode asks clarifying questions, researches the codebase and writes a plan you can edit before it builds. Plans go to your home folder unless you click Save to workspace. That button keeps them in the repository beside the brief.

Keep the brief in the repository

A brief holds what the agent needs in every session, such as the commands that build and check the project, conventions it can’t infer and decisions already made. AI2 Persistent Brief keeps it in a committed file, so every session and everyone on the team starts from the same text. For most agents that file is AGENTS.md, and CLAUDE.md vs AGENTS.md covers which agent reads which file.

Agents follow what the file says. Thibaud Gloaguen and colleagues tested this in Evaluating AGENTS.md (ETH Zurich, 2026). Agents used the uv package manager 1.6 times per task when a context file mentioned it, and fewer than 0.01 times when it didn’t. The same study found the files didn’t generally raise success rates and raised the cost of a run by over 20% on average. Repository overviews, it found, “are not helpful”.

So keep the brief short and specific to your project:

• Name the command that runs your checks. That’s the kind of specific instruction the study found agents follow.
• Leave out the overview of a codebase the agent can read for itself.

Keep the context small

Everything the agent reads stays in its context window, the text sent to the model with each request. AI3 Working Context treats that window as a finite resource. In Anthropic’s best practices, “LLM performance degrades as context fills”, and Claude may start forgetting earlier instructions as the window fills.

Adherence can slip within a single task, too. Damon McMillan’s Instruction Adherence in Coding Agent Configuration Files (2026) measured one instruction in CLAUDE.md across 1,650 Claude Code sessions, mostly with Sonnet 4.6. Each additional function the agent wrote came with 5.6% lower odds of following it. The author found the effect during analysis and hadn’t set out to test it, so treat the number as a lead.

In practice, give each task its own session:

• Run /clear between unrelated tasks in Claude Code, as Anthropic’s best practices advise.
• Start again after two failed corrections. In the same guide’s words, “A clean session with a better prompt almost always outperforms a long session with accumulated corrections.”
• Send research that reads many files to a subagent. It works in its own context and returns a summary.

Give it specs it can check

AI4 Verifiable Specs asks for specs the agent can run and grade itself against, such as tests written before the code, type signatures and schema validators. With a test, the agent doesn’t have to judge whether the spec is met. It runs the test and reads the result. Anthropic’s best practices make the case from the other side:

Claude stops when the work looks done. Without a check it can run, “looks done” is the only signal available, and you become the verification loop: every mistake waits for you to notice it.

That page also turns “implement a function that validates email addresses” into a prompt with example cases and an instruction to run the tests after implementing. That prompt is a spec the agent can check. Spec-driven development covers writing specs like that for whole features.

Make the coding agent check the API

A model learns each library from training data that stops at a cutoff, so its first guess at a call reflects the library as it was. AI5 Verify the API asks the agent to check the current docs or source before it writes a call to any framework, library or SDK.

Jude Gao’s AGENTS.md outperforms skills in our agent evals (Vercel, 2026) shows the size of the gap. Its evals used Next.js 16 APIs that “aren’t in current model training data”. With no docs, agents passed 53% of them. With a compressed index of the docs in AGENTS.md, which the agent used to find and read the right page, they passed 100%. The post doesn’t name the agent or the model, or say how many evals it ran.

AI coding agents rely on training data that becomes outdated.

So put two facts in the brief, the version of each library the project uses and where its docs are. The docs can be a local copy, the package source or a docs site.

Make it review its own draft

AI6 Self-Review Pass has the agent critique its draft and fix it before it hands anything back. That review needs something outside the model to check against. Jie Huang and colleagues’ Large Language Models Cannot Self-Correct Reasoning Yet (ICLR 2024) found that models “struggle to self-correct their responses without external feedback”. At times they did worse after trying.

Huang and colleagues tested reasoning tasks. Code already has that external feedback in its test output, type checker errors and spec. An agent reviews its diff against those and says what it couldn’t check.

AI code review has a checklist for that second pass.

Gate it with tools it can’t argue with

Every step so far relies on the agent following a brief that is only advice. Anthropic’s How Claude remembers your project (2026) says Claude treats CLAUDE.md files “as context, not enforced configuration”. A July 2026 study shows what that means for checks.

Wenhao Yang, Runzhi He and Minghui Zhou tested this in A First Look at Coding Agents’ Compliance with AI Contribution Rules in Open-Source Communities (2026). Their rules asked an agent to run a repository’s required checks before it submits. Claude Code with Sonnet 4.6 ran them in 11 of 26 runs. With the rule copied word for word into AGENTS.md, it ran them in 11 of 26. When a run broke the rule, one message naming it was enough to bring 16 of 19 such runs into line.

Verify barely moves from its unaided baseline; it behaves more like a fixed system trait than a response to steering.

For rules like this, the authors advise writing them where the agent reads at the start of a session and adding a feedback loop. A quality gate gives that feedback on every run, whether or not the agent remembers the rule. TA1 Linter as Law makes every gate an error, so a breach stops the build whatever the agent decided. P4 Continuous Quality Feedback runs the same checks as close to the edit as the tools allow, so a failure arrives while the change is still in the agent’s context.

Two studies measured what a gate does for an agent:

• Lint on each edit. In John Yang and colleagues’ SWE-agent (2024), the edit command ran a linter and reverted any edit that introduced a syntax error. With GPT-4 Turbo, that version solved 18.0% of SWE-bench Lite’s 300 tasks, and 15.0% without the linter.
• Type checking. Conner Nilsen’s Type Checking in Agentic Workflows (Pyrefly, 2026) reports experiments at Meta, where success rose from about 80% to 84% on well-typed code, in fewer steps. On poorly typed code, “the type errors actually distracted the agent and took it off course”.

Claude Code can hold the gate inside the session, too. Anthropic’s best practices describe a Stop hook that “runs your check as a script and blocks the turn from ending until it passes”. A hook runs only where it’s installed, so the same check belongs in CI, where it blocks the merge for every change. Each Prickles pack holds the lint config for its language.

I build prickles.org this way. One command, npm run check, runs ESLint, a Prettier check, type checking, duplicate detection and the unit tests held at 100% coverage. A pre-commit hook runs ESLint and the Prettier check on the staged files. A Claude Code Stop hook runs the whole command before an agent’s turn may end, and Pre-commit hooks shows that hook in full. Every pull request runs the same checks in CI, plus a build and the full end-to-end suite. That suite sets the acceptance bar and it’s frozen, so the agent changes the site until the tests pass, never the tests.

What the checks cost

None of these checks is free. Every run of a linter, type checker or test suite adds its output to the context window. Anthropic’s best practices say the window holds “every command output”, as well as every message and every file the agent reads.

Those test figures come from Zhihao Lin and colleagues’ To Run or Not to Run (ISSTA 2026). Across SWE-bench leaderboard submissions, agents ran the tests 8.8 times per task on average. In the authors’ own runs of Claude Code and Codex, banning test runs cost 1.25 points of success on average. They found the benefit “concentrated rather than uniform”, and argue for weighing the cost of each run against its benefit.

So decide where each check runs. P4 Continuous Quality Feedback asks for lint on save and for the tests of the file you just edited, so each run stays small. The full suite can wait for the end of the task and for CI. Why messy code costs more AI tokens covers the other side of the bill, what the code itself costs an agent to read.

How to set up an agentic coding loop

1. Write the brief in AGENTS.md. Give the command that runs your checks, the conventions the code doesn’t show and where the current docs for your libraries live.
2. Make that command run your linter, type checker and tests, with every lint rule set to error.
3. Start each task in a new session, in plan mode. Edit the plan until it names the files, the decisions and how the result will be checked, then approve it.
4. Write the acceptance tests before the build, or have the agent write them first and approve them with the plan.
5. Next the agent builds, runs the check command, reviews its diff against the plan and the test output, and reports anything it couldn’t check.
6. Run the same command in CI, and block the merge when it fails.
7. Review the diff yourself before you merge.

For steps 1 and 5, the brief might read:

## Checks

- Run `npm run check` before reporting a task as done. It runs ESLint, `tsc --noEmit` and the tests.
- When a check fails, fix the code. Never add a lint-disable comment.
- Before calling a library, read its docs for the version in `package-lock.json`.
- Finish by reviewing the diff against the plan, and list anything that couldn't be checked.

Swap npm run check for whatever runs your project’s checks, such as a make target or a Gradle task.