AI coding agents

Coding agents such as Claude Code, OpenAI Codex and Cursor can now take a story from the backlog to a pull request. What decides whether that pull request is right is rarely the model. It is the work item the agent starts from, the context it can reach, and the checks it has to pass before a person reads the result. This hub covers those three things, one decision per article.

It is written from how Stride itself is built. More than nine in ten commits in Stride's repository carry a coding agent's co-author line, and a person scopes each change, reviews it and approves every push. The practices here are the ones that held up at that volume, and the failure modes are ones we have hit.

1. Writing stories a coding agent can execute: what an agent needs that a teammate would infer
2. Acceptance criteria for AI coding agents: the contract the agent codes against, including the "must not" cases
3. Spec-driven development and the backlog: what Spec Kit and Kiro add, and where the spec should live
4. AGENTS.md and CLAUDE.md for coding agents: the durable project context every session needs
5. Backlog access for coding agents over MCP: what to expose, how to scope it, and why tickets are untrusted input
6. Test-first development with coding agents: tests that can fail, and an agent that cannot weaken them
7. Reviewing pull requests from coding agents: reviewing a plausible artefact against its contract
8. Running coding agents in parallel: isolation, collisions and review capacity

The loop in one paragraph

A story an agent can execute states the outcome, the reason, the acceptance criteria and the command that proves it done. The repository carries durable instructions in an AGENTS.md or CLAUDE.md file; the backlog carries the work, which the agent reads when it starts rather than from a pasted copy. The agent writes failing tests from the criteria, implements until they pass without touching the tests, and returns the evidence. A person reviews the diff against the criteria, not against the agent's summary, and decides what merges. Once that loop is reliable for one agent, it can run for several at once, each in its own worktree.

Why the backlog matters more now

When people wrote all the code, a vague story cost a conversation: the engineer asked, somebody answered, and the gap closed before it reached the code. An agent usually does not ask. It resolves the gap with a plausible guess and builds on it, quickly and confidently, so the cost of a vague story now shows up in review, or after release.

The same shift makes review the bottleneck. Agents produce changes faster than people can read them, and a change nobody reads properly is approved on the strength of green checks that only test what someone thought to test. Most of the practices in this hub either remove guesses before the agent starts or make the result faster to verify once it finishes.

What this hub assumes

You use an agent that can read and edit files and run commands in your repository: Claude Code, Codex, Cursor's agent, GitHub Copilot's cloud agent or similar. Your work lives in a tracker, whichever one it is. The advice is tool-agnostic. Where a tool's documentation says something specific, we name the tool, link its documentation and describe what it said when we checked it in September 2026, because these tools change monthly.

How to use this hub

If agents already work on your codebase and the pull requests keep coming back, read the articles on reviewing agent pull requests and test-first development first; they fix the loop where it leaks most. If you are setting up from scratch, read in order: stories and acceptance criteria define the work, the instruction file and backlog access give the agent context, tests and review verify the result, and parallelism comes last.