TL;DR
The short version
A Notion AI engineer showed Every how he ships features without reading the first draft of the code. The interesting part isn't that an agent writes it — it's how he structures the review: slice each change by domain, assign specialist reviewer agents, run them across two models, and loop until clean.
That structure is an org design, and designing it is now the engineer's real job. The leverage isn't a better prompt; it's a better structure around the agent.
Built on Every's interview of Ryan, a Notion AI engineer. The performance numbers are a single self-reported demo; the orchestrator-workers pattern is documented in Anthropic's Building Effective Agents.
The job moved from writing to structuring
Ryan, a software engineer on Notion AI, kicked off a real migration task on camera. He talked the task out loud, handed it to an agent on a cloud VM, went to meetings, and came back to a finished pull request with CI passing.
I'm spending all the time planning… and it's completely eliminated basically the busy work.
Ryan, Notion AI
The human work didn't disappear — it moved up a level, to environment, constraints, verification steps, and how the output gets checked. For anyone running a team, that's the shift worth copying.
The review swarm is an org chart
The centerpiece is a "review swarm" skill that Ryan runs before he ever reads the generated code. It works like a small org:
- Slice by domain. Take the change set and split it — say, a frontend change and a backend change.
- Assign specialists. Each slice gets two reviewers with different jobs: a correctness reviewer hunting bugs, and a maintainability reviewer asking whether the code reuses existing patterns or will implode at scale.
- Run it twice, on different models. Every slice is reviewed by both GPT and Opus, on the bet that different models catch different problems.
- Aggregate and loop. A top-level agent collects every finding into one report of things to action, and the agent loops until the work is clean.
Read past the enthusiasm — this is a Notion-produced demo — and the transferable idea is the shape: fan work out to narrow specialists, then fan the findings back in to one coordinator. That's the orchestrator-workers pattern, and it maps directly onto how you'd staff a human review.
One surface, so there's no context to manage
The second move is consolidation. Ryan runs the whole loop inside Notion and treats it as the source of truth for the spec, the task, and a living work journal the agent updates as it builds — his skill explicitly tells it to "take notes."
The payoff he names is subtraction, not addition. He no longer babysits whether his local repo is current, whether the tool is connected to the right environment, or which app holds which piece of context.
What to copy, and where to stop
The minimum viable version doesn't need Notion or an internal VM. It needs three decisions:
- Split the review by concern. Correctness and maintainability are different reviewers with different instructions. Don't ask one agent to do both in one pass.
- Use more than one model. A second model on the same diff is cheap insurance against a shared blind spot.
- Give it a self-verification loop. Ryan's agent monitors CI and fixes its own type errors and failing tests rather than kicking them back to him.
Now the boundary. Every number in the demo — the roughly 94-minute unattended run, the "hour and a half, two hours" saved — is Ryan narrating his own screen once. It's an anecdote, not a benchmark. And a swarm that runs two models across every slice inherits real cost; the people who build agents for a living, like Cognition, argue that parallel agents without shared context can make conflicting calls a single agent wouldn't. Treat the pattern as a starting design, not a settled answer — and keep a human on the merge until the review swarm has earned the diff you stopped reading.
