Boffin Adds Per-Edit Agent Guardrails

Boffin is an MIT-licensed open-source project by MicSm that adds a small control layer in front of AI coding agents. You ask for a tiny fix, and the agent returns a broad renovation that still passes tests. Route narrow architectural rules before the edit, then require proportional verification after it.
Boffin is a staff-engineer control layer for coding agents. For Codex users, the interesting part is not a new prompt trick; it is a concrete way to implement code review habits for ai-generated code without turning every change into a meeting. That makes it relevant to AI coding governance, but the story starts with a small GitHub repo and a very specific annoyance.
See the trick before judging the tool
Boffin’s README says it feeds the agent the constraints for the exact file being edited, then makes the agent verify the result. As of July 2026, the repo had 28 GitHub stars, was mainly JavaScript, used the MIT license, and had been pushed on July 26.
The project is explicit about what it is not. It is not another repo-wide AGENTS.md. It is not a prompt pack. It is not a linter or CI gate, because it acts before and after the edit rather than only rejecting code at the end.
That distinction matters. A root instruction file is good at durable norms: test commands, security rules, language preferences, and “don’t touch generated files.” Boffin is trying to answer a narrower question: which constraints apply to this file, right now?
The README highlights a DuckDB case study where a guided refactor landed at +17 / -17 lines with 2,104 assertions passing. Treat that as a motivating example, not proof that every repo gets the same outcome. The important bit is the shape of the loop: constrained edit, bounded diff, verified result.
Compare it with the tools you already have
The Hacker News reaction was predictable in a healthy way: is this just CONTRIBUTING.md, CONTEXT.md, or AGENTS.md with extra ceremony? That is the right objection. Most teams should be suspicious of a new layer that promises to make agents less sloppy by adding more agent instructions.
Here is the clean comparison.
| Criteria | Boffin | Scoped AGENTS.md |
Linter or CI gate |
|---|---|---|---|
| When it acts | Before and after the edit | Mostly before the session or task | After code is written |
| What it gives the agent | File-relevant architectural constraints | Repo or directory rules, depending on placement | Pass/fail feedback from tools |
| Best use | Preventing broad, architecture-breaking edits | Durable project conventions for Codex and other agents | Enforcing deterministic checks |
| Main weakness | Another layer to understand and maintain | Can become too broad or stale | Often catches problems late |
| Source-specific fact | README says it ships for Cursor, Claude Code, Codex, and more | Boffin explicitly says it is not another static repo-wide rules file | Boffin says it is not a linter or CI gate |
Verdict: Boffin wins when the risk is an agent touching the wrong abstraction or widening the diff. Scoped AGENTS.md wins when the rule is stable and local to a directory. CI wins when the rule can be checked deterministically and nobody needs prose to understand it.
A good Codex setup can use all three. Keep stable rules in AGENTS.md, let Boffin-style routing handle file-specific architecture, and still require tests before merge.
Try the idea in Codex without buying the whole frame
You do not need to install anything to learn from Boffin’s shape. Start with one boundary in a real repo, such as “API handlers may validate input, but domain decisions live in services.” Then make the agent read that boundary before touching files under src/api/.
A small AGENTS.md instruction can mimic the first version of the habit:
# AGENTS.md
When editing files under src/api/:
- Keep request parsing in the handler.
- Put business rules in src/domain/ services.
- Do not introduce database calls in route handlers.
- After the edit, report the smallest diff that satisfies the task.
- Run the narrowest relevant test first, then the broader test if behavior changed.
Then give Codex a bounded request:
Fix the null customer_id bug in src/api/orders.ts.
Use the local AGENTS.md rules.
Do not refactor unrelated order flow.
After the edit, show the diff summary and the exact verification command you ran.
Don't make the instruction block bigger every time an agent surprises you. Big rule files become fog. Boffin’s bet is that routing beats dumping.
The same experiment works in Cursor or Claude Code. For a UI hook, name the public signature and client wrapper that must remain unchanged. For a query planner, name the enumeration and cost-model behaviour outside the fix. These are examples of local constraints, not Boffin configuration. Record the relevant invariant before the edit and check it again afterward. Skip the extra receipt for spelling fixes.
Use the checklist when the change is risky
This is the practical place to implement code review habits for ai-generated code: before the agent starts, decide what must not change; after it finishes, review against that boundary before reading the whole diff.
Copy this review checklist into the PR, the Codex handoff, or the agent transcript.
- The requested change is stated in one sentence.
- The allowed files or directories are named.
- The architectural boundary is explicit: “this layer may do X, but not Y.”
- The diff size is explained if it is larger than expected.
- The agent reports what it did not change.
- The verification command is shown, not summarized.
- The reviewer checks behavior first, then style.
- Any new abstraction is justified by a failing test or repeated pattern.
- MCP access, if used is read-only unless the task requires writes.
- The final handoff names the remaining risk in plain English.
That MCP line is not decorative. The Model Context Protocol is a standard way for tools to connect agents to external systems such as repositories, docs, databases, and issue trackers. If an agent can read production context through an MCP server, the review boundary should say what it can read, what it can write, and what must stay human-approved.
Know when Boffin is overkill
Boffin is worth a look when a repo has real architectural seams and agents keep crossing them. Think C++ engines, compiler code, payment flows, data access layers, or large TypeScript apps where “just fix the bug” can accidentally rewrite a subsystem.
It is probably overkill for a small app with one developer, a simple test suite, and low blast radius. In that case, scoped AGENTS.md rules plus ordinary CI may give you most of the value with less machinery.
It also will not save a weak review culture. AI coding training for teams still has to teach developers to ask for bounded diffs, reject unrelated refactors, and verify behavior. Engineering team ai adoption goes sideways when everyone treats a passing test suite as the same thing as a good change.
Boffin’s best contribution is the reminder that agent context should be selected, not sprayed. That is a sharp idea whether or not this exact project becomes your default layer.
Common questions
Can a plugin really make AI-generated code less sloppy?
Only partly. A control layer can reduce sloppy edits by narrowing context and forcing verification, but it cannot replace a reviewer who understands the system. The believable claim is not “agents become safe”; it is “agents get fewer chances to wander.”
When should a Codex user try a Boffin-style workflow?
Try it when the same kind of agent mistake keeps repeating around one boundary. For example, if route handlers keep gaining database calls, write a scoped rule and require a verification note after each edit. If the problem disappears with a five-line AGENTS.md, you may not need Boffin yet.
Further reading
Next step
Pick one file boundary where agents often overreach, then write the smallest rule that would have prevented the last bad diff. If that works, you have learned Boffin’s main lesson before adding another layer.
Editorial update
Updated 20 September 2026: consolidated the Cursor and Claude variants, preserving their UI-hook and query-planner examples.