PMs and designers are opening AI-written pull requests: how much review do they add, and do you need a senior hire?

Non-engineers open a small share of pull requests, about 5% at Amplitude and 6.4% at epilot, but each costs more review per line. Size the load in reviewer hours before you open the repo. We'd start with low-risk lanes, no direct pushes to protected branches and one named engineer per non-engineer, and hire a senior only if measured review hours exceed your seniors' slack.

The constraint is reviewer time, not who's allowed to type code. For wider context on running a team through this shift, see our engineering management guides.

How big is the non-engineer stream, really?

Smaller than the headlines suggest. GitLab's write-up of Amplitude's overhaul says non-engineers went from essentially zero to roughly 5% of pull requests during a six-month overhaul. It also says validation and review became the stoppage points once agents removed the generation bottleneck.

epilot, writing on DEV Community, reports 629 merged PRs in 60 days. 40 came from 11 non-engineers and 589 from engineers, across a company with 40+ product engineers. That's 6.4% of merged PRs.

Both are one company's reported share, so yours may run higher or lower. Your own Git log tells you: count merged PRs by author role over the last 60 days.

How many reviewer hours does it add to your week?

StepTo's governance guide says reviewing non-engineer code costs more per line than reviewing an engineer's. Its advice is to estimate PRs per week, measure review time and staff for it.

None of epilot, StepTo or Manager.dev gives reviewer minutes per non-engineer PR, so you measure it. Time the first 20 non-engineer PRs: open to merge, reviewer minutes, and number of review comments. Then:

PRs per week x measured minutes per PR / 60 = reviewer hours

A worked example

Take epilot's numbers. 40 non-engineer PRs over 60 days is about 8.6 weeks, so roughly 4.7 PRs a week. Suppose your first 20 PRs average 30 minutes of reviewer time each (an assumption for the example, not a published figure). Then 4.7 x 30 / 60 is about 2.4 reviewer hours a week, which one senior can absorb.

Signadot, a vendor selling preview environments, claims volume could rise two, five or even 10 times. At 5x that's about 23 PRs a week, and the same assumed 30 minutes makes it roughly 12 hours, more than a day of a senior's week.

Which changes should non-engineers be allowed to open?

StepTo splits work into four lanes. We'd drop its sandbox lane, for prototypes that never touch production, and keep three, and you should adjust the edges to your codebase.

The low-risk lane

Manager.dev's author would start non-engineers with copy, pure UI and prompt changes with evals. We'd add documentation and styling. This is also where you learn your real minutes per PR.

Product logic with an engineer owning it

Behaviour changes are fine when an engineer co-owns the work from the start, not at review time. The reviewer's job shifts from catching errors to confirming the intent matches the code.

The restricted lane

Authentication, payments, permissions, migrations, infrastructure and personal data. StepTo puts these out of bounds for non-engineers, and we agree. A non-engineer can file the request, and an engineer writes the change.

Who reviews, and who answers for it?

One engineer per non-engineer. Manager.dev describes pairing each PM and designer with an engineer who owns their PRs, and says the review and mentoring takes a lot of time. Plan for that cost in the engineer's week, not as a favour.

The rule that matters most comes from epilot's incident. A non-engineer with full GitLab push access bypassed CI and deployed to production without review. The fix: non-engineers and agents open PRs, engineers review and merge, and nobody pushes directly to protected branches. Make that access rule your first control.

The owner should be able to explain the change before it merges. We cover that in one owner per merge and an explain-it gate. Tool and plan rules belong in your AI acceptable use policy for engineering teams.

When does the review load justify a senior hire?

Hire when measured weekly review hours exceed the slack of the named seniors, and not before. Three triggers tell you:

The measured hours from your first 20 PRs, scaled to your weekly volume, are more than your named reviewers can give without dropping their own work.
Requests for restricted-lane changes are queueing because only a few engineers can safely handle them.
One engineer owns all non-engineer PRs and has become the bottleneck.

If none applies, cap the lanes or pair fewer people instead. A lane limit is quick to change and a hire isn't. If one does apply, the hire is a senior reviewer-owner, not more seats (our judgment), and HighCircl can shortlist candidates.

What this means for your review capacity

You have three decisions. Choose which lanes non-engineers may open PRs in. Name the owner for each person and write that owner's review time into their week, since Manager.dev's pairing takes a lot of it. Turn off direct push for everyone who isn't an engineer.

Then run the 20-PR measurement before you hire anyone. If the hours fit in your seniors' slack, policy has solved it. If they don't, you have a number for the hiring conversation. In our judgment a new hire also takes some review time from your seniors while they ramp. The maths for a mid-level hire is in how much review time a hire takes from your seniors.

FAQ

Should non-engineers be allowed to open pull requests?

Yes, in a low-risk lane with a named engineer owning each person's PRs and no direct pushes to protected branches. epilot's production incident came from push access, not from the PRs.

Who should review a PM's or designer's AI-written PR?

The paired engineer who owns that person's work. Engineers review and merge; the non-engineer never merges their own change.

How many review hours do non-engineer PRs add?

Nobody publishes it. Time the first 20 PRs, then use PRs per week x minutes per PR / 60. epilot's reported volume works out to about 4.7 non-engineer PRs a week.

Do non-engineer PRs mean I need to hire a senior engineer?

Only if measured review hours exceed what your named seniors can spare, or restricted-lane requests are queueing. Otherwise cap the lanes or pair fewer people.

What should non-engineers never touch?

Authentication, payments, permissions, migrations, infrastructure and personal data. They can request the change, and an engineer writes it.