Last month, an AI coding agent handed me a beautiful fix. Five lines. Elegant. It reused an existing helper, matched the codebase style, compiled on the first try. Exactly the kind of diff we've all learned to praise since "make the agent write less code" became the standard advice.
It was also completely untested, and it sat on a password-recovery path.
That diff taught me something I now consider the central problem of AI-assisted coding in 2026: we've spent a year teaching agents to write less code, and almost no time teaching them to prove the code they kept actually holds.
Every AI coding agent fails in one of two directions.
Failure mode #1: the over-build. You ask for a date comparison; you get a new dependency, a ValidationService
class, and a config layer. This one is well known — it's why minimal-code prompts and skills became popular, and they genuinely work on it.
Failure mode #2: the confidently small diff. Minimal, clean, written after reading half the flow, verified never — dropped onto a path that handles money, auth, or user data. It compiles. It demos. It detonates in week three.
Here's the uncomfortable part: fixing #1 aggressively makes #2 more likely. When the objective function is "shortest diff," the first things to quietly disappear are edge-case handling, failure-path tests, and the guard clause that looked optional. The diff gets smaller. The blast radius doesn't.
A five-line change to a payment path is more dangerous than a four-hundred-line internal script that runs once. Code size is not risk. Blast radius is risk. Yet almost every skill and prompt in this category optimizes for size alone.
This is why I built Guardsman 💂 — an open-source skill that behaves less like a minimalist and more like the royal guard in front of the palace: nothing passes the post unchallenged, and the level of challenge depends on what's behind the gate.
Three duties, on every task:
1. Read the standing orders. Before writing anything, a deterministic script detects the repo's real conventions — language, formatter, linter, actual test command — and the agent greps how this codebase already solves the nearest similar problem. Your patterns win over its defaults. Always.
2. Set the threat level. Every change gets a risk tier before a single line is written:
| Tier | When | The challenge |
|---|---|---|
| trivial | internal one-off | one manual run, output shown |
| standard | everyday feature work | one check written and executed this turn |
| sensitive | money, auth, user data in the blast radius | a test exercising the failure path |
| critical | getting it wrong is an incident | full coverage, or the gap is surfaced as a blocker |
Two rules keep the tiers honest: when signals disagree, the higher tier wins — and the agent never infers a downgrade just because the code looks simple. A confident walk is not a countersign.
3. Issue the challenge. Non-trivial logic isn't "done" when the code is written. It's done when the check behind it was actually run, in the session, with output shown. A test that was written but never executed doesn't count. A promise to test later doesn't count.
TODO
comments rot. Nobody greps them, nobody triages them. Guardsman replaces them with structured watch-log entries:
Severity and revisit trigger are both required — a shortcut nobody can triage is worse than an unmarked one, because it creates false confidence that it's tracked. A bundled scanner harvests the whole repo and reports open entries by severity, overdue first. Your deferred work stops being folklore and becomes a list with dates on it.
Guardsman ships with a rule I haven't seen in this category: it never invents numbers about your repo. It will not tell you it "saved you 12,000 lines" — there is no unbuilt baseline of your codebase to diff against, so no tool can honestly compute that figure. Its status mode reports only what is directly countable, live, or says "nothing computed yet."
And that rule applies to the project itself, which is why I'm launching with zero benchmark numbers. What the repo contains instead is a fully pre-registered protocol: 12 realistic tickets against a pinned open-source FastAPI + React codebase, 43 pre-registered guard checks (no user enumeration on the recovery endpoint, webhook signature verified before any field is trusted, idempotent retries…), four arms including the most popular minimal-code skill, and frozen scoring rules — including the disclosure rule that any published result must include cases where Guardsman did worse, if they exist.
The tasks and rubric were committed before any run, so the report can't be bent around the results afterward. Numbers get published when they're measured, with raw diffs and full transcripts. And if you don't want to wait for mine: third-party runs are welcome via PR.
Claude Code, two commands:
/plugin marketplace add hedimanai-pro/guardsman
/plugin install guardsman@guardsman
Codex, Cursor, or any agent that reads an AGENTS.md
: a condensed, self-contained adapter ships in adapters/AGENTS.md — the tiers, the ladder, and the challenge floors travel everywhere.
Repo: https://github.com/hedimanai-pro/guardsman
If you've been burned by a confidently small diff — I'd genuinely like to hear the story in the comments. It's the failure mode nobody benchmarks, and I'm collecting cases.
No diff ships unchallenged. 💂
I'm Hedi Manai — AI & backend engineer building reliability tooling for AI agents. Also the author of ToolOps, middleware for agent tool-calling. Find me on LinkedIn and X.