When code breaks, it’s obvious, right?
Most of the time, AI agent output looks correct. It may even work in the narrow path the agent tested. That is the problem. The failure rarely announces itself with a loud build error. It arrives as a clean diff, a fluent explanation, and a change that feels plausible enough to accept.
These failures are patterned. Anyone working with Claude, Codex, Cursor, Copilot, Gemini, or similar tools will recognize the shape: the agent claims the task is complete, stretches the boundary of the request, or patches around a symptom because the prompt framed the problem too narrowly.
Common AI Coding Failure Modes
AI coding agents tend to break codebases in recognizable ways:
- Polished but wrong: The code is tidy, the comments read well, and the explanation is fluent. Authoritative presentation hides a bad result.
- Answered before it checked: The assistant claims tests pass or the bug is fixed before any real evidence exists.
- Patched the symptom: The agent applies a local fix instead of investigating the broader behavior.
- Drifted off the task: A narrow request grows into renamed functions, added dependencies, config edits, or schema changes.
- Worked from stale context: After an interruption or long session, the tool continues from an old assumption and still sounds productive.
- Defaulted to a custom solution: The agent builds a new path instead of reading the local pattern before and after the target change area.
Code Review Sees the Same Polished Surface
Human review is the usual backstop, but reviewers see the same confident code and prose that made the change feel acceptable in the first place. By the time the issue becomes visible, the code may already be merged, shipped, or patched again by another agent run.
That is why governance has to happen before the change becomes a commit. The deeper category problem is covered in Why Software Change Needs Governance Now, and the same acceptance boundary shows up in tool-specific comparisons such as Hakama vs Claude Code.
Catch the Work Before It Enters the Codebase
Hakama checks AI-assisted work against objective rules before the change reaches a commit.
Run Claude, Codex, or Gemini under Hakama’s governance. Two commands initialize the project path:
hakama init
Then run the agent through Hakama:
./.hakama/bin/claude
Hakama Controls Those Patterns
| Failure pattern | Hakama control |
|---|---|
| Answered before it checked | Pre-write evidence checks block unsupported claims. |
| Drifted off the task | Scope contracts compare the diff to allowed files and systems. |
| Patched the symptom | Required checks and review evidence expose missing blast-radius work. |
| Worked from stale context | The run is checked against the current task and repo state. |
| Polished but wrong | Tests, assertions, and receipts matter more than prose. |
Do Not Let Agent Output Become Unreviewable
AI agents are useful because they move quickly. Hakama exists because fast output still needs scope, evidence, and a review boundary. Teams can start with one workflow through a Hakama pilot and decide whether the governed path improves review quality before expanding it.