# The AI-Native Baby Steps > The 7 steps that make a codebase safe for AI coding agents, in the order to do them. A test safety net first, rolling it out to your whole team last. - **Source:** https://ainativesoftware.engineering/baby-steps - **Site:** AI-Native Software Engineering — https://ainativesoftware.engineering/book Small steps work because you take them in order, one at a time: a safety net first, then the risk that needs it. Making a repo safe for AI coding agents works the same way. Here are the 7 steps, in the order to do them. - **Steps:** 7 - **Rule:** Do them in order, one at a time. Finish a step before you start the next. - **Try it:** https://ainativesoftware.engineering/baby-steps ## The 7 steps ### 01 · Build a test safety net **Goal:** Enough automated tests that an agent cannot quietly break something that already worked. Without tests, every change an agent makes is a guess you have to check by hand. Tests are what catch the agent when it breaks something that used to work, so you can let it move without reading every line of every diff. Cover the paths that would hurt if they broke. You do not need every line. **What to do** - Cover the critical paths first, not every line. - Wire up one command that runs the whole suite, like npm test, make test or pytest. - Make a real break fail loudly, so the agent sees it. **Done when:** The important paths have tests, and one command runs them all and goes red on a real break. ### 02 · Write down the context **Goal:** An AGENTS.md or CLAUDE.md, a few rules files, and a handful of skills, so the agent knows how to build, test and behave in this repo. Drop an agent into a repo with nothing written down and it relearns the same things every session: how to build, how to run the tests, which patterns you use. It guesses, and it guesses wrong. Write that down once and every future run starts from the answer instead of the question. Begin with the file that says how to build and test, then add the rules and the skills. **What to do** - Add an AGENTS.md that names the build, test and lint commands. - Write down the conventions the agent keeps getting wrong. - Turn a repeated task into a skill or a slash command. **Done when:** A fresh agent lands in the repo and runs the right commands without you telling it. ### 03 · Add the quality gates **Goal:** Linting, formatting, type checks, security scanning and dependency checks, plus a CI gate that can actually stop a bad merge. Tests catch broken behavior. They do not catch a leaked secret, a risky new dependency, or code that does not type-check. Add the rest of the checks, wire them into one command, and make the branch reject anything that fails. Now a bad change stops at the gate instead of in production, whether you are watching or not. **What to do** - Add a linter, a formatter and a type check, and run them from one command. - Turn on secret scanning and dependency checks in CI. - Make the checks a required gate on the main branch. **Done when:** An agent cannot merge a change that fails a check, and you are not the one checking by hand. ### 04 · Manage your specs **Goal:** A way to write intent down before code: a spec-driven development framework the whole team uses. A one-line prompt leaves the agent to invent the details, and it invents different ones each time. A short spec written first gives it something to build against, and gives your gates something to check against. Work you spec well gets reused instead of redone. **What to do** - Pick a spec-driven development framework and standardise on it. - Keep specs in the repo, next to the code they describe. - Write acceptance criteria a machine can check. **Done when:** New work starts with a short spec the agent reads, not a one-line prompt. ### 05 · Give the agent your tools **Goal:** Connect the agent to the tools you use by hand: the AWS CLI to watch a deploy, the gh CLI for pull requests, MCP servers to read the browser or your project tracker. An agent that can only edit files does half the job. Give it the CLIs and servers you already use and it can watch the deploy, open the pull request, and read the ticket for itself. Do this after the gates are up. A capable agent with no checks around it breaks things faster, not better. **What to do** - Give it the gh CLI so it can open and read pull requests. - Give it read access to your deploy and logs, through the AWS CLI or a read-only MCP server. - Connect an MCP server for your project tracker and the browser. **Done when:** The agent does a real task end to end without you copy-pasting between tools. ### 06 · Orchestrate multiple agents **Goal:** Run more than one agent, in parallel or as a pipeline, on the same repo. Running many agents at once multiplies what you ship and what can go wrong in equal measure. The tests, the written context, the gates, the specs and the tools are what keep the second half of that off your desk. With them in place you can hand out work and trust the gates to catch the misses. Without them you have only built more ways to break things at once. **What to do** - Start with two agents and a clear hand-off, not ten at once. - Let one agent plan and another implement, gated by review. - Lean on the gates from step 3 to catch what you cannot watch. **Done when:** You can hand a spec to a team of agents and trust the gates to catch what goes wrong. ### 07 · Take it to your team, then your org **Goal:** Turn a repo one person made ready into how the whole team, and then the whole org, works. Shared agents, shared context, shared gates and specs, with an owner who keeps them current. A repo one person made ready is still a private win, and a team never moves at the speed of its fastest engineer. Buying everyone a license changes nothing on its own. Standardise the parts that have to match: the agent, the AGENTS.md and rules, the shared skills, the gates, and the spec workflow. Leave the rest, like editors and personal prompt style, alone. Layer the rules like a tree, a base for the whole org, then language, framework and team rules, all kept in Git, so a Python service and a React app share one base and grow their own branches. Then it compounds. A rule one person writes lifts everyone at once, and the harness gets more reliable every month. **What to do** - Standardise the shared stack: the agent, the AGENTS.md and rules, the shared skills, the gates and the spec workflow. Leave editors and personal style free. - Layer the rules like a tree: one base for the org, then language, framework and team rules, all in Git. - Give the standard an owner, a tech lead or a platform team, and run the team canvas to agree on it together. **Done when:** A new engineer or a new repo inherits the harness instead of rebuilding it, the standard has an owner, and it still changes when a better way earns its place. ## The mistake everyone makes Almost everyone wants to start at step 6. Running ten agents at once is the exciting part. Do it first, on a repo with no tests and no gates, and the first bad run costs you more than you saved. Build the nets first. You go fast, and then go wide, near the end, not at the start. ## Rules of the road - Do them in order. Finish one step before you start the next. - Every step is a net. You go fast, and then go wide, only once the nets hold. - You do not need each step perfect. You need it good enough to stand on before you climb to the next. - Come back and check the lower steps. A test suite or a gate you set up last year can rot without anyone noticing. ## Where this comes from These steps are the practices from [AI-Native Software Engineering](https://ainativesoftware.engineering/book.md), put in the order you should tackle them. To see where your repo stands today, run [the Readiness Analyzer](https://ainativesoftware.engineering/readiness.md). For step 4, compare [the spec-driven frameworks](https://ainativesoftware.engineering/compare.md). To run it with your team, take [the maturity assessment](https://ainativesoftware.engineering/assessment.md) or work through [the team canvas](https://ainativesoftware.engineering/canvas.md) for step 7. --- _AI-Native Software Engineering by Alfonso Graziano (O'Reilly Media, Early Release; print edition February 2027). Every page of ainativesoftware.engineering is also served as Markdown: append `.md` to any URL. Index: https://ainativesoftware.engineering/llms.txt — whole site in one file: https://ainativesoftware.engineering/llms-full.txt._