TL;DR
A coding agent that gets feedback on its errors fixes them. Without feedback it reports success, however many errors remain. Only the checks it can run, or better still has to run, secure the quality of what it hands back. Write the build, test and gate commands into the project's instruction file (CLAUDE.md, AGENTS.md) so the rules hold for the whole repository and nobody has to remember to repeat them in a prompt or a skill. Best of all, let a deterministic trigger fire the checks instead of the agent: a pre-commit hook runs them without the agent needing to know they exist.
The code did not compile. That is the version of the story I hear most often, and it arrives as a verdict on the agent: it invented a method that was never in the library. The agent hallucinated. That happens, and it is no rumour. What is worth stopping on is the other half of that sentence. The code had never once been run, and nothing in the setup had asked it to.
An agent that finishes its task and gets no feedback on quality counts the task as done.
#An agent has no trouble treating its task as finished while plenty of errors remain. It was given a task, and at some point, by its own reading, it has fulfilled it.
That the code does not compile never registers. Make compiling part of the task, though, and a failed compile keeps the task open until the code builds.
Attaching that as a goal to every single task is cumbersome and tedious.
The instruction file is where a rule stops depending on anyone remembering it.
#Instructions that should always apply are not something you want to repeat in every prompt and every . The project's instruction file (CLAUDE.md, AGENTS.md) makes that repetition unnecessary. What is written there is a general rule of the project, not of one particular task. Such instructions deserve care, because they act on every piece of work the agent does in the project.
There are global instruction files too, which apply to every project. Handle those with caution: only a rule that really should hold for every existing and every future project belongs there.
A pre-commit hook runs the check whether or not the agent thought to.
#Even a command written into the instruction file still asks the agent to decide to run it. It gets that decision right most of the time, but not always.
A pre-commit hook takes the decision away. One instruction remains: commit. At that moment the checks fire by themselves. A failure blocks the commit; the agent notices and repairs the errors on its own.
What fires the checks is no longer the agent's judgement but a deterministic trigger. That is clearly better than any rule you hand the agent.
Automated checks have to make an error as easy as possible for the agent to detect.
#Whoever fires it, the check's output has to be something a machine can read.
What matters is how easily an agent gets at concrete information about a failure. At minimum a check returns pass or fail. Add a clear failure message and the problem gets solved the most efficient way, which keeps the cost down. And the checks have to be deterministic.
Every rule you can state as a check is one class of mistake fewer. The obvious ones are a build, a type-check, a test run and a lint pass. Then come the checks fewer people think to automate: no architectural boundary crossed, every generated file still matches its source, every translation key actually carries translations.
The more such checks there are, the higher the quality of what a coding agent delivers.
Thirty project-specific checks run on every commit, and the gate is shaped for the agent that reads it rather than the person who wrote it: a passing check prints nothing. Every one of the thirty runs to completion, so once the code compiles and its tests pass, one commit attempt hands back every broken rule at once rather than the first one and another round trip.
All checks passing proves only that the code meets certain rules, never that it was the right change.
#This is where the technique stops, and the limit is worth stating plainly because a wall of passing checks can give a false sense of security.
They say nothing about whether a change was justified at all, or whether it makes sense both for the domain and technically.
That is why, in agentic engineering, the tasks an agent is given have to be planned with care.
When an agent finds its way around an environment quickly and gets at the relevant rules and information easily, we have a good (AX). Automated checks are a major part of it.
Keep exploring