Enforcement over Alignment and Steering

I'm building an open-source Claude Code plugin called The Enforcer. Not because I fancy writing more rules, but because asking a coding agent nicely to behave is clearly not enough.

If something must happen, I don't want to cross my fingers and hope the model remembers. I want the system to make the wrong thing hard to do. The usual fix when a coding agent goes off the rails is more prompting. Add a rule. Explain the mistake. Write another skill. Tell it not to do that again. Rinse and repeat. At some point you have to wonder why we're still doing this.

I've had Opus 5.5 try tools at the wrong time, narrate the work instead of doing it, and stop to suggest memories nobody asked for. Individually, these sound minor. After enough sessions, you're spending more time supervising the thing than getting on with the work.

I'm not interested in how impressive the demo looks. Every release turns up with a fresh round of trust-me-bro benchmarks, Anthropic's included, and none of them tell me how the model behaves halfway through an ordinary day's work. Meanwhile X is full of people showing off one-shot vibe-coded demos that are pretty average to begin with and useless the moment the video ends.

I want small, correct changes to a real codebase, and a straight answer about what has and hasn't been tested.

Instructions are not an enforcement mechanism #

Nobody secures a database by writing "please maintain integrity" in the README. We use constraints and transactions. Why are we treating critical agent behaviour any differently?

A model can't solve a model's problem. Another prompt just asks the thing that got it wrong to keep an eye on itself. This is a software engineering problem, and we already know how to solve those. We write deterministic code.

That's why my harness uses hooks, schemas and state gates. Claude can work out how to do something. It shouldn't get to decide whether a hard rule applies.

What enforcement looks like in practice #

One excerpt shows my PreToolUse:Bash hook refusing a shell command until the required reply had happened. Claude tried again. Same refusal. Once it had replied, the stop hook gave it a pretty clear nudge: "Tools work. Do the work." The boundary held because the tool was blocked, not because Claude suddenly understood the assignment.

It also shows the maddening bit: Claude spent turns explaining why it couldn't continue instead of recovering and getting on with it. So the gate did its job and still cost me time.

That's the lesson I didn't expect. A hook that blocks the wrong action isn't good enforcement if the agent can't get past it quickly. Enforcement without recovery is just a new way to be annoyed. A good gate needs a clear way through, not a new conversation about the gate.

The memory detour

Another excerpt has Claude asking to save a fairly ordinary testing observation to memory. I said no. Not because I want auto-memory switched off.

I do want to hear the ideas. Every now and then one is worth keeping. But I reckon I accept about 1–2% of the suggestions. The rest are usually details from today's task dressed up as permanent wisdom. Give me the good ones without turning every run into an admin exercise.

This one is a different kind of problem, and it's worth being straight about that. Whether a memory is worth keeping is a judgement call. No schema can decide it. What a hook can decide is the mechanical part: nothing gets written to memory without a yes from me.

That's the line I'm drawing for the plugin too. Hard requirements get enforced. Preferences stay as steering. If The Enforcer tried to enforce taste, it'd just be a more elaborate prompt.

What the harness actually changed #

The next excerpt isn't about Claude Code hooks at all. CS126 was a piece of work on Ask, the feature in my MakerSketch app where a model does its work through tool calls. It's the same principle at a different boundary. In Claude Code I can only put a gate in front of the tools. In Ask I own the tools the model talks to, so the rules go into the interface itself.

The CS126 report is more useful than another polished explanation of how the agent intends to behave. It says seven slices landed, the tool interface changed, and three recorded replays ran. Actual controls were added, rather than another page of instructions.

Among the changes:

1. Refusals carry correction. A refused call gets anError: <words> [tag: …] response so a repeat refusal can be identified, and the agent is told the corrected call.
2. The model sees one naming convention. Sixty-six keys were renamed tosnake_case at the model boundary, without renaming saved projects or recordings.
3. Finish and checkpoint have separate jobs.finish does not report while a check remains open;checkpoint reads the saved parts list rather than requiring the agent to repeat it.
4. Rules are centralised. Seven rules applying to every reply moved into instructions rather than being repeated in each reply.
5. Replay has measurable limits. Three recorded runs reportedly sent less than 300 KB each, with no reply above 4 KB, no raw UUID, no number with more than four decimal places, and no camelCase key.

That's useful engineering: normalise inputs, reject invalid actions, keep state, and measure what comes out.

"Done" is not the same as tested #

Then, in the very same report, we learn the final engine re-check didn't run, two app-test failures remained, and there was no live-model bridge run.

So yes, work landed. No, that isn't the same thing as a verified green build. I shouldn't need to read the fine print to work that out.

"I have completed all my required tasks" and "all required verification has passed" are two different statements.

Completion needs to come from test results and recorded state, not the model congratulating itself.

A quick story about the junior engineers I've had on my teams. I could give them a vague task, and more often than not they'd go digging. Read the code. Ask someone who knew the history. Check the edge cases. Come back with more than I'd expected.

It happened often enough that I came to expect it. Not perfection, and not mind-reading. Grit, curiosity and a genuine determination to do a good job when the requirements were a bit rubbish. Sometimes they got the wrong end of the stick, but they made an effort to find the right end first.

Now compare that with the agents. I'm sitting in front of models that are supposed to be operating at an extraordinary level, facepalming because they've stopped to narrate a refusal, invented extra scope, or declared victory before the tests have run. I never had anything remotely like this with the juniors, and that's the bit that really does my head in. There's a pretty big gap between generating code and showing engineering judgement.

Why I am building The Enforcer #

The Enforcer is the plugin I'm writing to make this repeatable. Not another personality prompt. A way of turning important instructions into boundaries the agent can't quietly step over, with useful feedback when it tries.

It comes down to four jobs:

The plugin will ship with a set of ready-to-use enforcement recipes, plus clear places to add your own. A recipe is for something code can check: did the tests run, is the argument valid, has the reply happened. Pick the rules your project actually needs instead of another novel into the context window. Enforcement should happen at the tool and workflow boundaries, not by making Claude read the same instructions over and over.

And it'll be open-source from day one. If you've got a better way to enforce something, add a recipe. If mine is rubbish, improve it. The point is to share working guardrails, not another collection of magic prompts.

That's what I'm building towards. The excerpts show why, and some harness work already reported. They don't mean the plugin is finished.

And this is happening while software teams are already stretched thin. The same companies selling us productivity are talking about a future that needs fewer engineers. Yet here we are, spending our time babysitting tools that are meant to take work off our plates.

It feels like the race is to make the next model one-shot a vibe coder's dream project. Good for the demo. But I spend my time in existing codebases, where the hard bit is changing one small thing without breaking five others. We need less clever theatre and more boring, reliable engineering.

This should not be necessary at this level of model #

At this level of model, this is pretty ordinary. In my experience, Fable 5.2 is only marginally better than Opus 5.5 at this stuff. That's hardly a leap forward when both still need a defensive harness to follow basic workflow rules.

The problems aren't exotic. Premature tool calls. Unwanted interruptions. Bad arguments. "Done" before the checks are done. Each costs a bit of time and attention. Across a day, it adds up.

The engineering decision. Stop treating model compliance as the control plane. Enforce invariants at the boundary, make failures recoverable, and require evidence before declaring completion.

Two of my favourite skills are i-have-adhd and ponytail. The first gets Claude to be more concise than its own concise mode seems capable of managing. The second leans on basics like YAGNI: don't build what you don't need. Neither should require a community skill. Both should be part of the product's default behaviour.

i-have-adhd

A skill to stop your coding agent from burying the answer. ADHD-friendly output.

ponytail

Makes your AI agent think like the laziest senior dev in the room. The best code is the code you never wrote.

Make the right thing the easy thing #

"You can't expect people to do the right thing. What you have to do is make the right thing the easiest thing to do."

Attributed to R. Buckminster Fuller

That's about as good a design brief for this as I've found. Don't just tell the agent not to do the wrong thing. Make the correct tool call the obvious one. Make invalid input fail immediately. Make unfinished verification impossible to pass off as done. That's the whole point of enforcement.

The difference is who holds authority #

With steering alone, the model does the work and then marks its own homework. I've had enough of that arrangement.

With enforcement, hooks reject the wrong call, schemas catch bad arguments, and recorded checks tell us whether we're finished. The agent can get on with solving the problem.

Steer the intelligence. Enforce the contract. #

That is the point of The Enforcer. Claude can decide how to solve the problem. It should not get to decide whether the rules apply.