A well-crafted system prompt will increase the quality of code produced by your coding assistant. It does make a difference. If you provide guidelines in your system prompt for writing code and tests, the coding assistant will follow the guidelines.
However that depends on your definition of “will follow”. If your definition is “will often follow”, then that is accurate. If your definition is “will always obey” or even “will obey most of the time”, that’s wrong (unless you’ve found a way to make them reliable which I haven’t – please let me know).
Coding agents will ignore instructions in the system prompt on a regular basis. As soon as the reference window fills up and they start getting high, all bets are off.
Even with the latest Opus 4.5 model, I haven’t noticed any major improvements. So if we can’t trust models to follow system signals, we need to invest in feedback loops.
I’ll show you how I’m using cloud code hooks to apply automated code review to all AI-generated code so that the code quality is higher before it reaches a human in the loop.
| You can find a code example that demonstrates the concepts discussed in this post on my github. |
Auto code review for fast, semantic feedback
Software architect and author Nick Tune, writing for O’Reilly Radar, describes a pattern for automatically reviewing code produced by Claude Code: a fast feedback mechanism aimed at common code-quality issues, run at the moment Claude finishes editing. Speed matters here — this is distinct from the deeper, multi-subagent reviews used when examining pull requests, which take considerably longer. The focus is the quick pass in between.
The purpose of auto code review is to reinforce the system prompt, project documentation, and on-demand skills — catching the things Claude may have overlooked — as one part of a multidimensional quality approach. Wherever possible, lint and test rules should carry the enforcement load, leaving auto code review for semantic issues that mechanical tools cannot check. Maximum file length or indentation depth belongs in the linter; minimum test coverage belongs in the testing framework.
What semantic code review catches
Semantic review examines how well code is designed. Naming is a prime example: does the code accurately describe the business concepts it represents? AI assistants often default to names like “helpers” and “utils” — words a lint rule can ban outright (a practice worth adopting) — but a linter cannot judge nuance, while an AI reviewer challenged to find better names does the job quickly and well.
Another example is domain logic leaking out of the domain model. When a use case or application service queries an entity and then makes a decision itself, domain logic has probably leaked into the application layer — hard to catch with lint tools, but well worth watching.
A third example is the default fallback value. When Claude encounters an undefined value where one is expected, it tends to substitute a default. It seems reluctant to throw exceptions or challenge the type signature by asking whether undefined should be allowed — it wants the code to run no matter what, however firmly the system prompt says otherwise. Lint rules catch some of this, but the right answer is subtle and context-dependent; sometimes falling back to a default genuinely is correct.
Building an auto code review with Claude Code hooks
For teams using Claude Code, one solution is a script that runs on the Stop hook. The Stop hook fires when Claude finishes working and hands control back to the user — the natural moment to trigger a subagent that reviews the modified files. Triggering the subagent requires returning an error status code, which blocks the main agent and forces it to read the review output.
Best practice is a dedicated review subagent with a deliberately critical mindset: asking the main agent to mark its own homework is clearly a poor approach, and it consumes the main agent’s context window.
| The solution I use is Available on GitHub. You can install it as a plug-in in your repo and customize the code review instructions, or simply use it as inspiration for your own solution. Any feedback is greatly appreciated. |
In the example shown, the review took 52 seconds — likely faster than a human reviewing and writing feedback. That is not always the case; some reviews take minutes. A developer sitting blocked waiting for the review may find it slower than reviewing manually, but one who is unblocked and working on something else comes out ahead: the end result is higher quality and needs less time to review and fix.
Scanning for updated files
Ideally the auto review only covers files modified since the last review — but Claude does not provide that information in the Stop hook’s context. Git can list modified or unstaged files, but that alone is not sufficient. The workaround is hooking PostToolUse to keep a log of each modified file:
When the Stop hook fires, the review looks up files modified since the last review and asks the subagent to review only those; if nothing has changed, the review does not run.
Challenges with the Stop hook
The Stop hook is not perfectly reliable for this use case. First, Claude may pause to ask a clarifying question — auto review should not fire there, before the user has responded and the work is actually finished. Second, Claude can commit changes before the Stop hook runs, so by the time the subagent reviews, the changes are already in Git. Neither issue is fatal, and both have straightforward workarounds — but they are extra things to keep in mind and set up.
The ideal solution, in Tune’s view, would be for Anthropic and other tool vendors to provide hooks at a higher level of abstraction — aligned with the software development workflow rather than low-level file operations. Something like a CodeReadyForReview hook that supplies the list of all files Claude modified would let teams plug in custom review solutions cleanly. Until then, this remains a problem each team solves for itself.
Limitations and what to watch
- The pattern reflects one practitioner’s setup as of early 2026; Claude Code’s hook system is evolving quickly, and newer releases may address the file-tracking and reliability gaps described.
- Automated review adds latency and inference cost to every completed task; the economics depend on how often the review catches issues that would otherwise reach a human.
- An AI reviewer inherits AI blind spots — subtle logic errors and security issues can pass both the generator and the reviewer, so human review before merging remains essential.
The takeaway
Auto code review of AI-generated changes is a useful pattern when granting an AI assistant some autonomy: it reinforces standards the generating agent may ignore, catches semantic issues that lint rules cannot express, and raises the quality of code before a human reviews it — saving time and sparing developers from repeating the same feedback to the AI. Related tooling approaches are covered in this roundup of tools for spec-driven development, and the original article with code examples is at O’Reilly Radar.
