← All Notes

Give Claude Code a specific instruction and you get a focused result. I've watched the opposite happen enough times in ChatGPT and Gemini — same kind of task, same level of specificity, noticeably more drift — that for a while I chalked it up to a model difference. Better model, better discipline.

That's not it. Correction, because getting this wrong matters: that discipline is the scaffolding, not the intelligence. The CLAUDE.md file it reads before touching anything, the permission gate between "the agent proposed this" and "the agent did this," the diff it shows you instead of silently committing — that's what narrows the model's behavior down to something focused. Swap in a weaker harness around the same class of model and the vagueness comes back.

A Real Problem, Aimed At Correctly

Which is exactly why Boffin caught my attention on Hacker News this week — a "staff-engineer layer" that injects architectural constraints per edit, so an agent doesn't wander across a module boundary it shouldn't touch. I have to salute whoever built this. They're pointed at a real failure mode, and they're pointed at it the right way: an agent making architectural calls edit by edit, with nothing structural stopping it, will eventually make a bad one. That's true no matter which model is doing the editing.

Two craftsmen bent together over a blueprint on a workbench, comparing notes with mutual respect

Where I land differently is on where that discipline should live.

Constraints Are Code, or They're Nothing

Here's what actually holds when you're running agents against a real, changing codebase. Your file structure enforces boundaries — if the agent can import across a line you didn't want crossed, that's a structure problem, not an agent problem. Your tests catch violations the moment they happen; red means revert, and you don't need a layer to "route" architectural intent when a failing test already says exactly what broke. Your linter is mandatory, not aspirational — it doesn't negotiate with the agent any more than it negotiates with you. Your types do the heavy lifting a paragraph of prose can't: fewer ways to pass the wrong thing to the wrong function in the first place.

A bricklayer setting a load-bearing brick wall course by course, mortar between each brick

You don't build a staff-engineer layer for humans. You build a codebase where the wrong move is hard to execute in the first place.

None of that is theoretical for me — I run agents against production systems daily. The ones that behave are the ones working inside structure that rejects a bad edit mechanically, not the ones being reminded, edit by edit, what the rules are.

The Layer You Already Have

Here's the piece Boffin's pitch skips, and the reason my own experience with it differs from what someone running raw API calls to a model would report: a good chunk of "per-edit architectural reminder" is already the harness's job, not a bolt-on layer's. Claude Code reads your standing rules before it acts, shows you the diff, asks before it commits to something irreversible. That's scaffolding doing exactly what Boffin is trying to do from outside — except it's already inside, already running, already free.

I've made this argument before about a different layer of the same stack: the deterministic parts of your system — structure, tests, rules, the harness itself — are what make the probabilistic parts trustworthy enough to build on. Boffin is a second, external attempt at that same deterministic layer, built for a world where the harness underneath doesn't already provide it.

That's not nothing. If you're running agents through a harness that doesn't read a standing architecture doc, doesn't gate irreversible actions, doesn't show you a diff before committing — a tool like Boffin is a legitimate way to bolt that discipline on from outside. The authors picked the right problem. For anyone already inside a harness built to solve it, the fix was already running before Boffin arrived.

— J.P. Howlett

Related:

Sources