Coding with AI comes in levels, set by how much of the work you hand to the model. Each level has its own bottleneck, and at the top one the slow part is reviewing the code, not writing it.
Level 1: autocomplete and a chat window
At the first level you still write the code. Your editor's AI suggests the rest of a line or a whole function as you type, and you accept it with Tab. For anything harder you open a chat assistant in the browser, describe the problem, copy the answer and paste it into your project.
This works, and for a lot of people it is the right amount of help. The cost is the copying. The chat assistant can't see your repository, so it guesses at your file names, your helper functions and the versions of the libraries you use. You fill those gaps by hand, run the code, paste the error back and try again. Each round trip is a context switch, and code you paste without reading is code you can't debug later.
Level 1 suits learning a language, small scripts, and codebases where you want to understand every line.
Level 2: one agent, one pull request
At level 2 you stop typing the code. A coding agent runs in your terminal or editor with access to the project. You describe the feature, and the agent reads the files it needs, edits them, runs the tests and opens a pull request. A pull request (PR) is a proposed change on its own branch, waiting for someone to review it before it joins the main code; there is more on them in the video on pull requests.
Here an agent has added a menu item to a small shop, updated the test that counted the items, pushed a branch and opened the PR:
You are now the reviewer, and this is where level 2 goes wrong. The diff looks tidy, the tests are green, so you skim it, write 'LGTM' (looks good to me) and merge. A skim catches typos. It doesn't catch a route that forgot to check who is calling it, or a change that breaks something in a file the diff never touched. And the agent wrote the tests too, so green only means the code does what the agent thought you wanted.
Level 2 also runs one feature at a time. The agent works in your local copy of the project, so you wait for it, check its work, then start the next task.
Level 3: many agents in the cloud
At level 3 the agents run in cloud sessions instead of on your laptop. Each session gets its own copy of the repository on its own branch, so ten of them can work at once without stepping on each other. You hand out ten features in the morning and come back to ten pull requests. Multi-agent orchestration covers how to split work so the agents don't collide.
Here are ten sessions, one per feature for the same shop:
Proof in every pull request
At this volume you can't run every branch yourself, so you ask each agent to prove its change works. The agent starts the app, drives it in a headless browser (one with no window, controlled by code) with a tool such as Playwright, and attaches screenshots and a short recording to the PR description:
Proof tells you the feature behaves as it should from the outside. It says nothing about what the code does behind the screen: who is allowed to call the new endpoint, what happens to other customers' data, whether an old feature quietly broke.
The review bottleneck
Ten agents can write more code in a morning than one person can read properly in a day. If you go back to skimming, you have level 2's LGTM problem ten times over. That is why many developers stay at level 2: the writing scales, and the reviewing doesn't.
Letting a reviewer agent read it first
The fix is to put a second agent between the coding agents and you. This video was sponsored by Aikido Security, whose reviewer is called Aikido Deep Review, so that is the one described here.
Deep Review runs on every pull request in the repositories you turn it on for. Unlike a check that only reads the changed lines, it pulls in code from the rest of the repository, and from any related repositories you link, before deciding whether to comment. That context is what lets it find problems in how a change interacts with the rest of the app: missing access checks, business logic flaws, data leaking between customers, plus ordinary bugs and side effects. It reads repository files such as AGENTS.md and CLAUDE.md for risks you have already accepted, so it doesn't keep reporting them.
Findings arrive as comments on the PR, with a suggested fix, and Deep Review adds its own status check. That is the part a coding agent can act on. The loop goes:
- A coding agent opens a PR.
- Deep Review reads it and comments on what is wrong.
- The coding agent reads the comments and pushes a fix.
- Deep Review checks the new commits, resolves the comments the fix addressed and raises anything new.
- The loop repeats until there are no findings left.
You don't take part in any of this. A re-review after new commits on the same PR costs nothing extra: Aikido charges one credit per pull request, however many rounds it takes.
A worked example
Say one of the ten agents adds a 'sold out' button to the shop. It writes a new endpoint, POST /menu/:id/sold-out, a test that marks a fish sold out, and screenshots of the badge appearing. The diff is twenty clean lines and the proof looks right.
What the diff doesn't show is that every other route that changes the menu goes through a requireOwner check in the auth module, and this one doesn't. Any customer could mark every fish sold out. A skim misses it because nothing in those twenty lines looks wrong. A reviewer reading the auth module alongside the change sees the gap, comments that the route needs the owner check, and the agent adds it, plus a test that a customer gets a 403. The second review finds nothing, and the PR reaches you ready to merge.
Your job shrinks to the things only you can judge. Watch the recording, look at the screenshots, check the agent made sensible product choices (the agent above picked a price because nobody gave it one), then merge.
When to stay at a lower level
Level 3 isn't the goal for every project. It pays off when you have a steady list of well-defined features and a codebase with tests worth trusting. It costs money per session and per review, and it needs clear tasks: ten vague prompts give you ten vague pull requests.
Stay at level 1 or 2 when you are learning, when the change touches something delicate that you want to reason through yourself, or when the project is small enough that you can read every diff. The original meaning of vibe coding, accepting AI code without reading it, is fine for a throwaway prototype and a bad idea for anything that holds customers' data.
Common mistakes
- Treating green tests as a review: the agent wrote the tests, so they share its blind spots.
- Giving parallel agents overlapping work: two agents editing the same file produce merge conflicts, or one silently undoes the other's work.
- Turning off the other checks: an AI reviewer adds to static analysis, dependency scanning and your test suite. It doesn't replace them.
- Skipping the proof: without screenshots or a recording you are back to running every branch by hand.
- Leaving accepted risks unwritten: put them in
AGENTS.mdso reviewer agents stop flagging the same deliberate choice.
Key takeaways
- Level 1 is autocomplete plus a chat window: you write the code and paste in the hard parts.
- Level 2 is one agent writing a whole PR, with you as a reviewer who is tempted to skim.
- Level 3 runs many agents in parallel, each proving its PR with screenshots and a recording.
- At level 3 review becomes the bottleneck, so an AI reviewer such as Aikido Deep Review reads every PR first and loops with the coding agent until it is clean.
- You stay the last step: check the proof and the product decisions, then merge.
