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?