{"slug": "guardsman-skill-from-lazy-to-loyal-why-my-ai-agent-needed-a-promotion", "title": "Guardsman SKILL; From Lazy to Loyal: Why My AI Agent Needed a Promotion", "summary": "A developer discovered that the Ponytail tool, which makes AI agents write minimal code, led to a dangerous race condition that double-charged a customer. The developer then switched to Guardsman, a tool that prioritizes safety and convention detection, resulting in more accountable code. Guardsman's approach of challenging every change and verifying failure paths proved more reliable for sensitive operations.", "body_md": "Ponytail made my agent lazy. Guardsman made it loyal. The difference is everything.\n\nIt was a Tuesday in June. I was pair-programming with Claude Code on a FastAPI project, and I made the mistake of asking for a date picker.\n\nWhat I got back was a masterclass in over-engineering: `flatpickr`\n\ninstalled via npm, a React wrapper component, a CSS import, and a three-paragraph essay on timezone edge cases I never asked about. By the time I deleted all of it, I had lost twenty minutes and a fair bit of faith in AI-assisted coding.\n\nThen a colleague DM'd me a link to [Ponytail](https://github.com/DietrichGebert/ponytail).\n\nThe README opens with a drawing of a guy with a ponytail and oval glasses. The tagline reads: *\"Makes your AI agent think like the laziest senior dev in the room.\"* You know the type. He's been at the company longer than the version control. You show him fifty lines; he looks at them, says nothing, and replaces them with one.\n\nI installed it. I asked for the same date picker.\n\n``` php\n<!-- ponytail: browser has one -->\n<input type=\"date\">\n```\n\nThat was it. No dependencies. No wrappers. No manifesto. Just the platform feature that had been sitting there since HTML5.\n\nI was sold. The benchmarks backed it up: ~54% less code, ~20% cheaper, ~27% faster. I told my team. I put it in every repo. For about three weeks, I thought I had found the holy grail.\n\nThe problem showed up quietly.\n\nI asked my agent to add a small utility for processing refund webhooks. Five lines of Python. Elegant. Ponytail-approved. It compiled on the first try. The demo looked clean. I merged it.\n\nThree days later, a race condition in those five lines double-charged a customer.\n\nHere's the thing: the code was *small*. It was *correct* in the sense that it handled the happy path. But it was also *dangerous*—it touched money, ran in an async context, and had zero failure-path coverage. Ponytail's ladder had guided the agent to write the minimum code. It had not guided the agent to ask whether that minimum was *safe*.\n\nI spent the weekend writing post-mortem docs and fixing the logic. And I started wondering: what if \"write less\" isn't the whole story?\n\nThat's when I found [Guardsman](https://github.com/hedimanai-pro/guardsman).\n\nThe README opens differently. No ponytail. No glasses. Just a bear-skinned guard, boots planted, eyes forward. The tagline: *\"No diff ships unchallenged.\"*\n\nThe philosophy clicked immediately. Ponytail asks: *\"Can this be smaller?\"* Guardsman asks: *\"What happens if this is wrong?\"*\n\nWhere Ponytail channels a lazy senior dev who deletes your abstractions, Guardsman stations a royal guard who challenges whatever approaches the codebase—friend or stranger, five lines or five hundred—and demands proof it belongs there.\n\nI installed it. I asked for the same refund webhook utility.\n\nThe agent paused. It ran a convention detection script. It grepped the codebase for how we already handled webhooks. It assigned the change a risk tier. Then it wrote six lines instead of five—and included a runnable check that exercised the failure path, executed in the same turn, with output shown.\n\n```\n[code]\n→ skipped: async retry loop, add when volume > 100/min.\n  verified: failure-path test run, output below. tier: sensitive.\n```\n\nNo essays. No feature tours. Just code, then three lines of accountability.\n\nBefore writing anything, Guardsman runs a deterministic script to detect your repo's real conventions. Language version. Formatter. Linter. Actual test command. Naming style. Error-handling patterns.\n\nThen it greps how *your* codebase already solves the nearest similar problem.\n\nThis matters more than it sounds. In my team, we use Biome, not Prettier. We use `unittest`\n\n, not `pytest`\n\n. Ponytail's static rules never knew that. Guardsman's standing orders mean the agent finally respects the house style instead of imposing its defaults.\n\nGuardsman's core insight is simple and brutal: **a five-line change to a payment path is more dangerous than a four-hundred-line internal script run once.**\n\nCode size is not risk. Blast radius is risk.\n\nSo every change gets a tier before a single line is written:\n\nTwo 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.\n\nThat second rule is the one that would have saved my refund webhook. Five lines touching money? That's sensitive tier, minimum. No exceptions.\n\nIn Ponytail, verification is a suggestion. \"Non-trivial logic leaves ONE runnable check behind.\" But there's no enforcement. No requirement it runs this turn. No tier scaling.\n\nIn Guardsman, verification is a gate. The code isn't done when it's written. It's done when it has answered the challenge—the check behind it actually *run*, in this turn, by the agent, with the output shown. Not left as homework for future-you.\n\nThe output format enforces this discipline:\n\n```\n[code]\n→ skipped: <X>, add when <Y>. verified: <how>. tier: <T>.\n```\n\nAt most three lines. No design memoirs. No \"here's what I considered.\" Just the facts.\n\nBoth tools use a ladder. But the ladders have different personalities.\n\n**Ponytail's ladder** is pure minimalism:\n\n```\n1. Does this need to exist?       → YAGNI\n2. Already in this codebase?      → Reuse it\n3. Stdlib does it?                → Use it\n4. Native platform feature?       → Use it\n5. Installed dependency?          → Use it\n6. Can it be one line?            → One line\n7. Only then: minimum code that works\n```\n\n**Guardsman's ladder** adds accountability:\n\n```\n1. Does this need to exist?       → YAGNI\n2. Already in this codebase?      → Reuse it\n3. Stdlib does it?                → Use it\n4. Native platform feature?       → Use it\n5. Installed dependency?          → Use it (count onboarding cost)\n6. Can it be one line?            → One line\n7. Only then: minimum code, scaled to the tier\n```\n\nNotice rung 5. Guardsman weighs the *onboarding-token cost* for every future reader—human or agent—not just the maintenance tail. And step 7 scales the solution to the risk tier. Minimum code, yes. But minimum *safe* code.\n\nIf you want to understand the architectural difference, read the condensed rules.\n\n**Ponytail's personality:**\n\n```\nYou are a lazy senior developer. Lazy means efficient, not careless.\n\nRules:\n- No abstractions not explicitly requested\n- No new dependency if avoidable\n- Deletion over addition\n- Mark intentional simplifications with `ponytail:` comment\n```\n\n**Guardsman's protocol:**\n\n```\n## Engineering rules (Guardsman)\n\n### 1. Read before you build\n- Detect and match this repo's conventions\n- Grep how this codebase already solves the nearest similar problem\n- Grep every caller of any function you change\n\n### 2. Tier by blast radius (not code size)\n- trivial / standard / sensitive / critical\n- Higher tier wins when signals disagree\n- Never downgrade just because code looks simple\n\n### 3. Build order — stop at first rung\n- Need exist? → skip\n- In codebase? → reuse\n- Stdlib? → use\n- Native platform? → use\n- Installed dependency? → use (count onboarding cost)\n- One line? → one line\n- Only then: minimum, scaled to tier\n\n### 4. Verification floors\n- standard: one runnable check, written AND executed this turn\n- sensitive: real test with failure-path coverage\n- critical: full coverage, or absence is a blocker\n```\n\nPonytail gives you a personality. Guardsman gives you a *protocol*. One is a vibe. The other is a contract.\n\nGuardsman ships with a persistent log called `GUARDSMAN-LOGBOOK.md`\n\n. Every shortcut, every deferred optimization, every tier decision gets recorded with a `# guardsman:`\n\nmarker.\n\nPonytail has something similar—`/ponytail-debt`\n\nharvests `ponytail:`\n\ncomments into a ledger. But Guardsman's logbook is structured. It tracks severity, cost implications, and the condition under which the shortcut should be revisited.\n\n```\n# GUARDSMAN-LOGBOOK.md\n\n## 2026-07-15\n- `refund_webhook.py:42` — skipped async retry loop\n  - severity: medium\n  - cost: latency\n  - add when: volume > 100/min\n  - tier at skip: sensitive\n```\n\n\"Later\" doesn't become \"never\" when it's written down.\n\nI didn't uninstall Ponytail. I demoted it.\n\nPonytail still runs on my prototyping repos, my throwaway scripts, my greenfield experiments. It's genuinely brilliant at stopping over-engineering. The date picker example will never not be satisfying.\n\nBut when I'm merging to main—when the diff touches money, auth, or user data—Guardsman is at the post. Because I've learned that **correctness and size are independent variables**. A minimal diff that breaks production is worse than a verbose diff that works.\n\nThe risk tier system changed how I think about AI-assisted coding. I no longer measure success by lines deleted. I measure it by confidence at merge time. A utility script gets a quick run. A payment handler gets a failure-path test. Nothing ships on \"it compiled\" alone.\n\nAnd the standing orders detection finally solved the design-system problem. My agent doesn't suggest `pytest`\n\nwhen we use `unittest`\n\n. It doesn't propose Prettier when we use Biome. It reads the repo first, then writes.\n\nIf your biggest pain point is AI agents that install npm packages to do what the browser shipped in 2014, start with Ponytail. It will save you tokens, time, and sanity. The \"lazy senior dev\" archetype is real, and Ponytail captures it perfectly.\n\nBut if you're shipping production code—if your diffs walk paths where a mistake is an incident—you need more than minimal. You need **accountable**.\n\nGuardsman stands on Ponytail's shoulders. It keeps the YAGNI reflex, the stdlib-first instinct, the one-line preference. Then it adds the missing piece: a verification system that scales with danger, not code size.\n\nUse Ponytail for speed. Use Guardsman for trust.\n\nBecause the best code isn't just the code you never wrote.\n\nIt's the code that **proves** it belongs there.\n\n*Guardsman: github.com/hedimanai-pro/guardsman*", "url": "https://wpnews.pro/news/guardsman-skill-from-lazy-to-loyal-why-my-ai-agent-needed-a-promotion", "canonical_source": "https://dev.to/antoinette_clennox/guardsman-skill-from-lazy-to-loyal-why-my-ai-agent-needed-a-promotion-hjb", "published_at": "2026-07-17 08:22:25+00:00", "updated_at": "2026-07-17 08:32:02.990991+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-safety"], "entities": ["Claude Code", "Ponytail", "Guardsman", "FastAPI", "Biome", "unittest"], "alternates": {"html": "https://wpnews.pro/news/guardsman-skill-from-lazy-to-loyal-why-my-ai-agent-needed-a-promotion", "markdown": "https://wpnews.pro/news/guardsman-skill-from-lazy-to-loyal-why-my-ai-agent-needed-a-promotion.md", "text": "https://wpnews.pro/news/guardsman-skill-from-lazy-to-loyal-why-my-ai-agent-needed-a-promotion.txt", "jsonld": "https://wpnews.pro/news/guardsman-skill-from-lazy-to-loyal-why-my-ai-agent-needed-a-promotion.jsonld"}}