What are AI development standards?

Most teams had coding standards long before AI: a style guide, a linter config, a wiki page about how to name database migrations. People read them once, mostly. AI coding agents read their instructions on every request, which changes what a standard is for. The file an agent reads decides whether it uses pnpm or npm, whether it touches generated code, and whether it runs the tests before saying it is done.

How are AI development standards different from coding standards?

AI development standards are written for a reader that follows them literally and forgets them between sessions. A human developer absorbs “we prefer small functions” over months of code review. An agent gets exactly the words in its context, every time, and nothing else. So the standard has to be explicit, short and checkable.

They also cover more than code style. An agent acts: it runs commands, calls tools, reads internal systems. A complete standard says which tools it may use, which procedures it should follow for recurring work, and which actions get stopped automatically. That is closer to a platform team’s job than to a style guide.

What goes into an AI development standard?

An AI development standard has five parts, and each one maps to a kind of file the coding tools already read.

Part	What it decides	Where it lives today	HubBound Artifact type
Rules	Conventions the agent must always follow	AGENTS.md, CLAUDE.md, .cursor/rules, .github/copilot-instructions.md	Rule
Procedures	Repeatable work the agent can run by name	A SKILL.md folder (Agent Skills format)	Skill
Tools and data	Which systems the agent can reach, and how	MCP server configuration	MCP server
Delegation	Specialists for focused tasks (review, tests, migrations)	Subagent definitions	Subagent
Enforcement	Checks that run before or after an agent acts	Hook configuration	Hook

The rules row is where most teams start and stop. The other four are where a standard stops being advice. A rule that says “never commit secrets” is a request. A hook that scans the diff before a commit and blocks it is a control.

Which open formats exist for AI development standards?

Three open formats cover most of what a team writes down, and adopting them keeps a standard portable across tools.

AGENTS.md is a plain Markdown file at the root of a repository, described by its maintainers as “a README for agents”. It came out of a collaboration between OpenAI Codex, Amp, Google’s Jules, Cursor and Factory, is now stewarded by the Agentic AI Foundation under the Linux Foundation, and its site reports use in more than 60,000 open-source projects.

Agent Skills is the SKILL.md format, originally developed by Anthropic and released as an open standard. A skill is a folder with a SKILL.md file (a name, a description and instructions) plus optional scripts and references. Agents load only the name and description at startup and read the rest when a task matches, so a team can ship many skills without filling the context window.

The Model Context Protocol is the open standard, introduced by Anthropic in 2024, for connecting an agent to tools and data through MCP servers. A team standard that names the approved MCP servers is how every developer’s agent reaches the same issue tracker the same way.

The formats do not cover everything. Hooks, subagents and tool-specific rule files still differ from tool to tool, which is why a team using two or three coding agents ends up maintaining several copies of the same intent.

What does a good rule look like?

A good rule names a specific action and can be checked by reading the diff. A weak rule describes a value.

## Weak
- Write clean, maintainable code.
- Follow best practices for testing.

## Strong
- Use pnpm. Never run npm or yarn in this repository.
- Before you say a task is done, run `pnpm test --filter <package>` for every package you changed.
- Never edit files under `src/generated/`. They are rebuilt by `pnpm codegen`.
- New API routes go in `src/routes/` and need an entry in `docs/api.md`.

Each strong line could fail in code review with a clear reason. Each weak line could not. Agents behave the same way: a rule they can verify against the repository gets followed far more consistently than a rule that asks for judgment.

How does a team keep AI development standards from drifting?

A team keeps standards from drifting by having exactly one source for each one and a way to deliver it to every machine. Drift starts the day a rules file is copied. Somebody fixes a line locally, never sends it back, and six months later the team has six versions of “the” standard.

Three things stop it. Versioning, so every change produces a new version and anyone can say which one they run. Distribution, so the current version reaches developers without anyone copying files. And pinning, so a team can stay on a known version while a change is tested elsewhere.

That is the problem HubBound is built around. Each part of a standard is an Artifact (a rule, a skill, an MCP server, a subagent or a hook) with its own version history. Artifacts are bundled into a Kit, and an admin distributes the Kit to one team or to the whole organization as Mandatory or Optional, following Always latest or pinned to a version. The HubBound Runtime installs mandatory Kits on each machine in its next background sync, into Claude Code, Cursor, OpenAI Codex, GitHub Copilot and Antigravity.

When are AI development standards the wrong tool?

A standard does not guarantee behavior. Agents can and do ignore instructions, especially long ones. If an outcome really matters (no secrets in commits, no writes to production), enforce it with a hook or with the CI pipeline, and treat the rule as documentation of why.

More rules are not better. Every rule competes for the agent’s attention with the actual task. A 2,000-line rules file reads to an agent the way a 2,000-line policy reads to a new hire: the important lines get lost. Prune as often as you add.

And a personal preference is not a standard. How one developer likes their agent to phrase commit messages belongs in their own setup, not in the file the whole team receives.

Where should a team start with AI development standards?

Start with your code review comments, not with a blank document. Every comment a reviewer leaves more than twice on AI-written code (“we don’t use that library anymore”, “tests go next to the file”, “don’t touch the generated client”) is a rule waiting to be written. Those rules are specific by construction, the team already agrees on them, and you can see whether they work: the comment stops appearing.

DORA’s AI Capabilities Model lists a “clear and communicated AI stance” as the first of its seven capabilities. A short, versioned set of rules that came out of real reviews is the most concrete version of that stance a team can have. The glossary defines each of the five parts, and Artifacts & Kits shows how each one is versioned in HubBound.