Guardsman SKILL; From Lazy to Loyal: Why My AI Agent Needed a Promotion

Guardsman SKILL; From Lazy to Loyal: Why My AI Agent Needed a Promotion

Tópico: Guardsman SKILL; From Lazy to Loyal: Why My AI Agent Needed a Promotion
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------
Ponytail made my agent lazy. Guardsman made it loyal. The difference is everything.

The Day I Met Ponytail

It 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.

What I got back was a masterclass in over-engineering: flatpickr installed 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.

Then a colleague DM'd me a link to Ponytail.

The 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.

I installed it. I asked for the same date picker.


<input type="date">

That was it. No dependencies. No wrappers. No manifesto. Just the platform feature that had been sitting there since HTML5.

I 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.

The Refund Webhook Incident

The problem showed up quietly.

I 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.

Three days later, a race condition in those five lines double-charged a customer.

Here'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.

I spent the weekend writing post-mortem docs and fixing the logic. And I started wondering: what if "write less" isn't the whole story?

The Guard at the Gate

That's when I found Guardsman.

The README opens differently. No ponytail. No glasses. Just a bear-skinned guard, boots planted, eyes forward. The tagline: "No diff ships unchallenged."

The philosophy clicked immediately. Ponytail asks: "Can this be smaller?" Guardsman asks: "What happens if this is wrong?"

Where 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.

I installed it. I asked for the same refund webhook utility.

The 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.

[code]
→ skipped: async retry loop, add when volume > 100/min.
verified: failure-path test run, output below. tier: sensitive.

No essays. No feature tours. Just code, then three lines of accountability.

Three Things Guardsman Does That Ponytail Doesn't

1. It Reads the Standing Orders First

Before 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.

Then it greps how your codebase already solves the nearest similar problem.

This matters more than it sounds. In my team, we use Biome, not Prettier. We use unittest, not pytest. Ponytail's static rules never knew that. Guardsman's standing orders mean the agent finally respects the house style instead of imposing its defaults.

2. It Sizes Danger by Blast Radius, Not Line Count

Guardsman'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.

Code size is not risk. Blast radius is risk.

So every change gets a tier before a single line is written:

•
Trivial — internal one-off, nothing downstream. One manual run, output shown.

•
Standard — everyday feature work. One runnable check, written and executed this turn.

•
Sensitive — money, auth, or user data in the blast radius. A real test exercising the failure path, with coverage notes.

•
Critical — getting it wrong is an incident. Full coverage, or the absence of harness 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.

That second rule is the one that would have saved my refund webhook. Five lines touching money? That's sensitive tier, minimum. No exceptions.

3. Verification Runs Before the Diff Ships

In 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.

In 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.

The output format enforces this discipline:

[code]
→ skipped: <X>, add when <Y>. verified: <how>. tier: <T>.

At most three lines. No design memoirs. No "here's what I considered." Just the facts.

The Build Orders Compared

Both tools use a ladder. But the ladders have different personalities.

Ponytail's ladder is pure minimalism:

1. Does this need to exist? → YAGNI
2. Already in this codebase? → Reuse it
3. Stdlib does it? → Use it
4. Native platform feature? → Use it
5. Installed dependency? → Use it
6. Can it be one line? → One line
7. Only then: minimum code that works

Guardsman's ladder adds accountability:

1. Does this need to exist? → YAGNI
2. Already in this codebase? → Reuse it
3. Stdlib does it? → Use it
4. Native platform feature? → Use it
5. Installed dependency? → Use it (count onboarding cost)
6. Can it be one line? → One line
7. Only then: minimum code, scaled to the tier

Notice 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.

What the SKILL.md Files Reveal

If you want to understand the architectural difference, read the condensed rules.

Ponytail's personality:

You are a lazy senior developer. Lazy means efficient, not careless.

Rules:
- No abstractions not explicitly requested
- No new dependency if avoidable
- Deletion over addition
- Mark intentional simplifications with `ponytail:` comment

Guardsman's protocol:

## Engineering rules (Guardsman)

### 1. Read before you build
- Detect and match this repo's conventions
- Grep how this codebase already solves the nearest similar problem
- Grep every caller of any function you change

### 2. Tier by blast radius (not code size)
- trivial / standard / sensitive / critical
- Higher tier wins when signals disagree
- Never downgrade just because code looks simple

### 3. Build order — stop at first rung
- Need exist? → skip
- In codebase? → reuse
- Stdlib? → use
- Native platform? → use
- Installed dependency? → use (count onboarding cost)
- One line? → one line
- Only then: minimum, scaled to tier

### 4. Verification floors
- standard: one runnable check, written AND executed this turn
- sensitive: real test with failure-path coverage
- critical: full coverage, or absence is a blocker

Ponytail gives you a personality. Guardsman gives you a protocol. One is a vibe. The other is a contract.

The Logbook: Where "Later" Becomes "Now"

Guardsman ships with a persistent log called GUARDSMAN-LOGBOOK.md. Every shortcut, every deferred optimization, every tier decision gets recorded with a # guardsman: marker.

Ponytail has something similar—/ponytail-debt harvests ponytail: comments into a ledger. But Guardsman's logbook is structured. It tracks severity, cost implications, and the condition under which the shortcut should be revisited.

# GUARDSMAN-LOGBOOK.md

## 2026-07-15
- `refund_webhook.py:42` — skipped async retry loop
- severity: medium
- cost: latency
- add when: volume > 100/min
- tier at skip: sensitive

"Later" doesn't become "never" when it's written down.

Why I Made the Switch

I didn't uninstall Ponytail. I demoted it.

Ponytail 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.

But 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.

The 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.

And the standing orders detection finally solved the design-system problem. My agent doesn't suggest pytest when we use unittest. It doesn't propose Prettier when we use Biome. It reads the repo first, then writes.

Final Thoughts

If 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.

But 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.

Guardsman 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.

Use Ponytail for speed. Use Guardsman for trust.

Because the best code isn't just the code you never wrote.

It's the code that proves it belongs there.

Guardsman: github.com/hedimanai-pro/guardsman

Ponytail: github.com/DietrichGebert/ponytail