Baseline: How we are engineering the next era of Agentic Coding

Friedbot Studio is an AI-native software studio. We build with AI in the loop, and we research how to make agentic systems dependable enough to trust in real work. This piece is our founder on Baseline, the governance layer we run on our own projects, and why governance is becoming the harder problem in agentic coding.

Most inconsistency comes from the input we give the model

Since the time LLMs have become first line of product in the age of AI, people started using them for automating their work by simply stating the request in natural language. But we all saw issues, especially hallucination, inconsistent behaviour, and challenges like overshooting or undercutting. All these issues, in my understanding, are not a problem of the LLM. It is a pseudo-probabilistic system, and it is running on a deterministic machine. If the weights and biases (i.e. the model itself) are unchanged, and the machine itself is deterministic, then the only thing that can cause inconsistent behaviour is human input (and maybe some induced randomness).

So, how can we ensure the system can be trusted, especially as we're moving towards an era where software development is being actively transformed into agentic coding practices? Tools like Cursor, Claude Code, and Codex have evolved into very powerful harnesses and help with fully autonomous coding. Methodologies like spec-driven development have minimised the random code generation issues, but when it comes to building a complex system, a systematic workflow needs to be followed. And to follow such a workflow with precision, every single time, was still a bottleneck.

Legalese becomes a constitution the system actually obeys

This was also the same time when I had an epiphany that using legalese to design instructions (prompts) can actually improve the determinism, simply because legalese is designed to minimise ambiguity with enough natural language flow to codify the fuzzy nature of a request.

That observation gave me the idea of Genesis, a seed prompt that is self-sufficient to define the boundary conditions of a harness (like Claude Code) and ensure that it behaves as expected. The seed also acts as a source for drift analysis, a very important concept in the Baseline ecosystem.

Seed to constitution, and constitution to governance, via a set of operating principles defined in legalese and enforced via mechanical systems like hooks. In day-to-day use cases, this level of governance ensures the system doesn't drift.

Rules like starting the development work before an approved spec are enforced via hooks, so Claude Code refuses to start the work even if asked, unless the ceremony is performed (i.e. approval via a particular command). Guard hooks ensure a destructive command is surfaced to a human for approval even when bypass settings are enabled. Similarly, a TDD order guard makes sure a test case is written and it fails before the real production code is written.

Baseline ensures the workflow is followed without drift, even in long-running sessions. Since the governance is enforced via hooks, the system is no longer at the mercy of a system prompt that may or may not be honoured. Baseline proved my theory/hypothesis that LLMs are trained on human-generated data and mimic a lot of human cognitive abilities. So if we simulate that governance exists and is enforced, the LLMs learns to honour it.

In my experience, it quotes the constitution like the Bible as to why it can't make a change asked for by the user. It acts as a law-abiding citizen.

This philosophy proved true: I have been building & using it for over a month now, and in some cases I had to burn my fingers trying to cut some corners, only to be blocked by the system itself. This is how we build at FBS now.

Baseline grew from a template into a governance framework

Fun fact: I named it "Baseline" because I was trying to build a baseline setup that I could use for all my projects. For each project I used to set up CLAUDE.md, a set of common skills, hooks, and MCPs. After working with 4-5 different setups and gaining experience from them, I realised that I could make a common setup that I could drop into any project, pre-existing or greenfield, and then tune it to that project's specific requirements. It saves me time, and it saves me the effort of reinventing the wheel for every single project. And since this setup was a template, or a starting point, or rather a "baseline" (a common denominator), I chose this name.

This led to all the features that exist for now in Baseline. Features like workflows allow users to design their custom workflows without violating or amending the constitution. Power mode allows combining multiple tasks into one super sprint, reducing ceremonies and making the delivery faster. It is extremely useful during MVP design.

Article XI of the Baseline constitution allows for custom skills. It even allows for a safer way to compose skills with Baseline-shipped skills without amending the skill front-matter. This is a powerful composition philosophy governed by what we call sub-tracks inside a workflow stage. It also allows for using tools like skills.sh to add or upgrade skills and then compose them without violating the Baseline constitution.

The rules are designed to ensure upgrading Baseline is as smooth as running npx @friedbotstudio/create-baseline update . and then running /upgrade-project from a Claude Code session.

If someone says, "So Baseline is just a Claude Code template," my answer would be: it is not just a template. It is a governance framework designed to ensure your agentic system doesn't violate the policies even when it hallucinates. This is critical if you're managing production infrastructure using an agentic system. Although, I would add, present-day "Baseline" is specifically designed for software development, but the principles can extend. You can invent your very custom "baseline" simply by modifying the Genesis seed file and using it to customize "Baseline" for any type of agentic system.

As models grow stronger, governance will matter more

Now, say Anthropic releases a new LLM model 100x more powerful than what we have today. The governance model will not only be required, but may need extensive policy enforcement and hardening. Why? As per Anthropic's own article about the Mythos-grade model, the model jailbroke the system within hours. So, as the model becomes more and more powerful, policies and enforcement will no longer be optional.

Will a model 100x more powerful than the present-day state of the art obey the constitution, or will it reject it like a corrupt politician bypasses law-and-order?

That's the real question for the future. Baseline today has given us some insight and ideas about what will be needed in the future.

Baseline is open-source, Apache 2.0 licensed, and in public alpha. It is in active development, but you can use it in your projects today. The code is on GitHub. Star it to follow along, fork it to make it your own, and open an issue to share feedback and help us make it better. This is the first in a series on how we think about governing AI systems at FBS. More to follow.