§07 · Patterns of Work

Automated check

Also called Check · CI check · Verification step

A mechanical pass/fail test the harness or CI runs on the agent's work: types, lint, tests, build. Cheap, fast, no judgement.

An automated check is anything that can say yes or no about the agent's work without a person looking: the type checker, the linter, the test suite, a build, a schema validation, a link checker. It has a definite answer and it runs in seconds or minutes. It is the cheapest feedback an agent can get, and unlike a human it never gets tired of running.

Checks matter more with agents than with people because the agent will happily continue past a mistake it can't see. A hallucinated method name compiles in the agent's head but not in the compiler. Without a check, that error surfaces three files later as a confusing failure; with one, the agent gets a tool result saying exactly what broke and fixes it in the next turn.

Wire the checks into the loop rather than running them yourself at the end. Tell the agent in AGENTS.md which command to run after every change, or use hooks to run it automatically after each edit. The stricter and faster your checks, the further you can let the agent run AFK. What checks can't judge (taste, product sense, whether the feature is the right feature) is the job of human review.

In the tools
  • Claude CodeA post-edit hook can run the type checker or tests after every change and feed failures straight back to the agent.
  • GitHubCI on the pull request is the last automated check before a human sees the work.
In conversation

It refactored the whole module and the tests still pass. Do I still need to read it?

The checks tell you it didn't break anything you already tested. They don't tell you it's good. Skim the diff.

Related terms
Learn it in the school
Words are the easy part

Course 01 puts every one of these terms to work: you install Claude Code, run the loop, and ship a real project — permission modes, compaction, hooks and all.

Start Course 01 →