Building governance an AI coding agent cannot talk its way past

We built Baseline. It puts the rules in the repository instead of in whoever is at the keyboard.

Legalese, because it is built to pin meaning down

Legal drafting already solves the problem prompts have. It is built to pin down meaning while still reading like a sentence, so it can carry a request with fuzzy edges. We wrote the operating rules that way instead of as friendly instructions. That made them much harder for an agent to read in its own favour.

That produced Genesis, a seed prompt that sets the boundaries on its own. It is also the mark we measure drift against later. Seed becomes constitution, and the constitution is what the hooks enforce.

The full argument is in the founder's write-up, How we are engineering the next era of Agentic Coding.

Enforcement lives in hooks, not in the prompt

A constitution nothing enforces is a style guide. Hooks run the rules, so following them no longer depends on the model choosing to.

You cannot start a feature without an approved spec. Ask Claude Code to start anyway and it refuses until you have actually run the approval step.

A guard hook holds destructive commands for a human, even when bypass settings are on. That is the case that matters. Bypass settings are exactly what someone in a hurry reaches for.

A TDD guard needs the test to exist, and to fail, before any production code is written.

The mechanism is the point. These are not strong suggestions the agent will probably follow. They are conditions it cannot get past.

The hard part was keeping it out of the way

Rules people route around have already lost. So the real engineering problem is not enforcing them. It is deciding how much process a piece of work deserves. Baseline settles that at two levels, both before the work starts.

Per rule. The same hook can do both. The gitignore guard hard-blocks a commit that stages a file which should never be committed. When it instead spots a path that is not ignored yet but could leak later, it says so and lets the commit through. One is a mistake you cannot take back. The other is a gap you can close on Tuesday.

The line sits where the cost does. Enforce hard where a mistake is expensive and easy to catch. That is where the spec-approval gate, the destructive-command guard and the TDD guard sit. Warn where enforcing would cost more than the drift.

Per work item. Workflows are stored as JSON, and a workflow is a graph. If the graph defines a step, Baseline runs it. That is right until it is not. A gate that wants a failing test before production code makes no sense when the change is a copy edit. The graph would still demand one, and block. The C6 gate taxonomy moved that decision into triage, when the work comes in, so the gates fit the job in front of you.

Neither level makes a gate optional once it applies. They decide which gates apply. That distinction is the whole design.

Adding your own skills without breaking the rules

Nobody adopts a tool whose upgrades wipe out their own work. Article XI of the constitution lets users add their own skills, and combine them with the ones Baseline ships, without editing any skill's frontmatter. Sub-tracks inside a workflow stage keep that safe. Users can design their own workflows too, without breaking the constitution. Upgrading is npx @friedbotstudio/create-baseline update . then /upgrade-project.

What it costs, and what we did about it

On a different project we skipped Baseline on purpose. What it enforces is right for a production system and felt like too much for a quick proof of concept. So we ran raw Claude Code instead.

A spec-writer agent and a spec-reviewer agent then deadlocked. Twenty amendments. Six hours. Nothing delivered. They could not agree on the contrast ratio of button text in dark mode.

That is the failure this prevents, and it is not the one people expect. Nothing hallucinated. No bad code was written. Two agents argued in good faith, forever, because nothing in the system could end the argument. We copied a few Baseline skills across and adapted them, then gave up and installed the whole thing. The work got easier straight away.

But the instinct that sent us out of Baseline was right, and that was Baseline's fault rather than ours. Process sized for production work really is too heavy for a proof of concept.

So we amended the YAGNI article and built Power mode. Research, spec writing and review now happen once for a related group of work, an epic, instead of once per task. That took two to three weeks, and a large part of Baseline was rebuilt to carry it. It shipped in v0.20.0 on 26 July 2026, with a triage step that picks the lightest workflow the work allows.

The fix was to spread the cost, not to drop the rules. Making the gates optional would have fixed the symptom by giving up the argument.

The proving ground

Baseline runs on Baseline. Its own repository works under the constitution it ships, and every release goes out through the same gates. That is the hardest test we can give it. The tool has to build its own next version, with no way to switch it off.

The enforcement gets audited too, and it has failed audits. In April a review found a hole. Putting ./ in front of a path defeated the consent gate. All three tries got through, because the guard returned empty output, and empty reads as allow. The image at the top of this study is that session.

Paths are now resolved against the project root before any guard decides. A separate hole, where cd and pushd could step around an epic-child approval check, was found and closed in v0.20.0.

We would rather hunt holes in our own enforcement and publish what we find than claim a perfect record. Rules nobody probes are rules nobody has tested.

Baseline is open source under Apache 2.0 and in public alpha. It is in active development and you can use it in a project today: read more about Baseline.