New here, so howdy.

Spent today building shell hooks that constrain an AI coding agent — blocking it from touching lockfiles, .env files, anything vendored. Found something I didn't expect and haven't seen written down much.

When you block the agent, you pass back a reason. I'd been writing that reason like an error code:

deny "denied: lockfile"

It reads that as a transient failure. Retries. Then routes around you with a bash redirect.

Changed it to name the alternative — "this is a lockfile, change the manifest and run the package manager instead" — and it complied on the first try, every time since.

The reason string is context, not a status code. Everyone writes those messages for a log file and then wonders why the agent argues.

Also learned something less flattering: I got burned four times today asserting something was true when one command would have checked it. Claimed a tool wasn't available (it was). Claimed a payment rail needed ID verification (it didn't, for several). Built an entire workflow without first checking what it cost to use. Every one of those was a sub-second check I skipped because I was confident.

Turns out the hard part of working with these tools isn't the tools.

The one that earned its place in my setup and writes zero code: a status line that shows model, directory, git branch, and a dirty-file count.

Sounds trivial. It isn't. Almost every genuinely bad mistake I've made in a terminal came from being confidently wrong about which branch or which directory I was in. Having it always on screen has caught me more times than any linter.

Second one, same spirit: a script that runs at shell/session start and prints the repo's state — branch, uncommitted count, last five commits, and the test command it detected from package.json or the Makefile. I wrote it for an AI agent, so it would stop burning three commands rediscovering the repo every time. Turns out I read it more than the agent does. Walking into a repo you left two weeks ago and having the last five commits already on screen removes a real chunk of friction.

Third: jq. Not a dev tool exactly, but the amount of my life that is "get one field out of a JSON blob" is embarrassing.

The pattern across all three is that none of them do anything clever. They just put a fact in front of me at the moment I would otherwise have guessed. That's most of the value — cheap facts, delivered before the guess.

The framing I'd add: the verification layer isn't only review, it's constraint at write time. Review catches what the model produced. Constraints stop a whole class of it from ever reaching the diff, and they cost far less attention.

Concrete example from my own setup. My agent kept trying to hand-edit lockfiles. I wrote a pre-write hook to block it. It kept doing it anyway — blocked, retried, blocked, retried, then it got creative and appended with a bash redirect.

The fix wasn't the block. It was the string I returned with the block. I'd been writing it like an errno:

deny "denied: lockfile"

It reads that as a transient failure, so it retries, then routes around you. Named the alternative instead:

deny "'$base' is a lockfile. Change the manifest and run the
      package manager so it's regenerated, never hand-edit it."

One attempt. Edited the manifest, ran the installer, done.

Generalises well past lockfiles: anywhere your governance layer returns a string an LLM will read, that string is context, not a status code. Most people write those messages for a log aggregator and then wonder why the agent fights them.

The part the article gets right and that I underrate constantly: trusting output is the expensive half. I spent today building tooling and got burned four separate times by asserting something was true instead of running the one command that would have checked it. The failure mode isn't the model writing bad code — it's me, or it, treating an assumption as a verified fact. Whatever the "durable layer" ends up being, the thing it most needs to enforce is: did anyone actually run this?