The Agent Levels Game

When a team tells me "AI doesn't work for us," the first thing they blame is the model. It's almost never the model.
Here's the thing I keep coming back to: an agent can only move as fast as the slowest human in its loop. Every time it has to stop and wait for you, whether that's to explain how the repo works, to check if the fix actually worked, to review the PR, or just to tell it what to do next, the whole thing drops back to human speed. It doesn't matter how smart the model is at that point. It's sitting there waiting for you to get back from lunch.
So getting real value out of agents is mostly about taking yourself out of that loop, one spot at a time. I think of it as a game with levels, and you have to play them in order. Skipping one doesn't save you time. It just moves the pain to a later level, where it's harder to see what's causing it.
| Level | Goal | You stop being | Cleared when |
|---|---|---|---|
| 0 | Agent-friendly repo | The onboarding buddy | A fresh clone runs with one command |
| 1 | Verifiable output | The test runner | The agent proves "done" without you |
| 2 | Review that scales | The bottleneck | The repo rejects bad PRs before a human sees them |
| 3 | Proactive agents | The trigger | Work starts from events, not from your prompt |
Level 0: Make the repo agent-friendly

The bottleneck
You're the onboarding buddy. Think about what it takes for a new engineer to get the app running on their laptop. If the honest answer is three days and two Slack threads, an agent doesn't stand a chance. It gets the exact same repo, except it can't ping anyone to ask which env var is missing.
What to build
- One repo. A monorepo keeps the context and the changes in one place. If a fix touches the API and the frontend, the agent shouldn't have to hop between three repos to make it.
- One command.
git clone, then one setup command, and you have a working environment. Not a wiki page with twelve steps. - Central secrets. The agent pulls them from a store. Nobody copies a
.envfile off someone's laptop. - Written-down decisions. The code only tells you the end state. The why usually lives in people's heads, and the agent can't read those. We keep a brain folder in the repo with our decisions, our terminology, and past incidents, so there's somewhere for it to look.
Proof
Shopify moved everything into one monorepo they call World, and they run dev, CI, and production on Nix. From Under the River:
"Code is going to be increasingly written with AI, and our infrastructure needs to be the substrate for that."
On our team, people started saying "the AI gets us now" before they even knew the brain folder existed. Nobody told them anything had changed. They just noticed.
You're stuck here if
- The agent spends its first twenty minutes guessing env vars.
- It keeps undoing decisions that nobody ever wrote down.
- You switched models and nothing got better.
Level 1: Let it verify its own work

The bottleneck
You're the test runner. This is the loop everybody knows. The agent says "done," you go check, it's wrong, you explain what's wrong, it tries again. The agent might be fast, but every round trip goes through you, so the whole loop runs at your speed.
What to build
- A new contract. Don't just hand the agent
{problem}. Hand it{problem} + {how to check it's fixed}, so it knows what "done" looks like without asking you. - Eyes. A browser it can drive, tests it can run, logs it can read. It can't verify anything it can't see.
- An isolated stack per agent. One command brings up a full stack seeded with known data, so five agents working at once don't step on each other's databases.
Proof
| Task | The check I gave | Result |
|---|---|---|
| Sidebar won't close | Open the URL, click the X, confirm the layout shifts | Fixed in one pass |
| Flaky worker test | Run the flow 1,000 times, stop only when all pass | Found a race condition in ~75 min, no input from me |
| Does it scale? | Scale replicas 10 → 80, measure throughput, graph it | Ran for hours on its own |
There's more on this in Stop Babysitting Your Agent.
You're stuck here if
- The agent says "done" and it never actually ran the code.
- You're still clicking through the UI yourself before every PR.
- The app runs on some remote box the agent's browser can't reach.
Level 2: Make review scale

The bottleneck
You're the reviewer. This one sneaks up on you. Once you clear level 1, the agents actually start finishing things, and the PRs pile up. Now you've got a human spending a whole day reviewing what an agent wrote in an hour. You didn't remove the bottleneck. You just moved it to the review queue.
What to build
The fix is to move the checks out of people's heads and into the repo, where they run every time without anyone having to remember. Roughly, they come in four kinds:
| Kind | Examples |
|---|---|
| Hard rules (block) | Linters on. No commit unless tests pass. Every pre-commit hook is also a CI check. |
| Journey tests (block) | Signup, checkout and the core flow run in CI before merge. |
| Soft rules (nudge) | PR over 500 lines → ask the agent to split it. 7+ review comments → rethink the design and start fresh. |
| Taste rules (nudge) | "Smallest diff that works" on the whole repo, to stop abstractions nobody asked for. |
Two more habits that helped us:
- Review the write-up, not the diff. Have the agent explain what changed and why, with screenshots or a recording. Read that first, and only then go to the code.
- Rule changes get their own PR. Anything that touches CI or the hooks goes in separately. That's how you catch an agent quietly editing the pipeline so its own tests pass.
You're stuck here if
- CI is green, but it doesn't test anything that actually matters.
- Every round of review waits on a remote bot instead of running locally.
- The agent keeps patching review comments onto a design it should have thrown away.
Level 3: Make it proactive

The bottleneck
You're the trigger. Nothing happens until you sit down, open a session, and type a prompt. The agent can do a lot at this point, but it's still waiting on you to notice there's work.
What to build
Let events start the work instead of you: a new ticket, a question in a channel, a failing build, a nightly job. Levels 0 to 2 are what make this safe. An agent running unattended on a repo that hasn't cleared them doesn't produce more work. It produces more mess, and it produces it faster.
Proof
- Tickets → PRs. A support engineer on our team, not a developer, turns Linear tickets into PRs. The fixes are about 80 lines each. The expensive part (getting set up, opening the PR, getting through CI) is already handled by levels 0 to 2, so what's left is small enough for someone outside engineering to own.
- Questions → investigations. Someone asks our Discord bot, Gus, "what happened to this conversation?" It queries the logs and replies with a timeline. By the next day, support was using it on their own.
- Work in public. Shopify's River only works in public Slack channels, so every session is something the whole company can watch and learn from. 1 in 8 merged PRs at Shopify now has River as a coauthor.
You're stuck here if
- You jumped straight here, and now nobody trusts the PRs that show up at 3am.
- Agent sessions happen in private DMs, so nobody else gets to learn from them.
- Only the engineers use it.
How to play
- Find your level. It's the lowest one you haven't cleared, not the one that sounds the most exciting.
- Fix the biggest pain for the whole team, not just your own setup. Your laptop working isn't the goal.
- Repeat every two weeks. Pick the next pain, fix it, move on.
- Stop at 80%. Improving your setup is addictive, and it's easy to spend a month polishing level 1. Once a level is mostly cleared, go to the next one.
So when a team tells me AI doesn't work for them, I don't ask which model they're on. I ask which level they're stuck on. The model usually isn't the ceiling. The setup is.