Run the two-lane merge policy

Your product manager can write code now. So can your designer, your analyst, and the person who runs your support queue. Not good code necessarily, but working code, in volume, without asking you first.

This is either the best thing that has happened to your team or the worst, and which one it turns out to be is not determined by their skill. It is determined by what you built before they started.

Here is the state of the industry as it stands. Only about half of teams have any guardrails specific to AI-generated code, while well over half still require a human to manually review every line of it. Meanwhile the volume has gone up sharply: across twenty-two thousand developers, incidents per pull request have risen roughly 243 percent, median review time is up over 400 percent, and 31 percent more pull requests now merge with no review at all.

Read those together. Half the industry has no rails, and the other half is trying to hold the line with human attention that has already run out. The reviews are not happening. They just still look like they are.

The move

Nobody pushes to a protected branch. Agents and non-engineers open pull requests. A human who owns the touched paths reviews and merges.

That is it. That is the whole policy, and it is the single highest-value afternoon of work available to you right now.

It is not a new idea. It is the oldest idea in team software development. What is new is that the population of people opening pull requests has just expanded to include everyone in the building plus a fleet of agents, and most repositories were configured for a world where it did not.

One company that rolled this out properly, epilot, went from zero to 40 pull requests from 11 non-engineers in 60 days. They also had the incident: a non-engineer bypassed CI and deployed straight to production. Nothing was damaged, but the policy they wrote afterwards is the one worth copying, and it is exactly the sentence above.

Two lanes, not one gate

The mistake is treating all contributions the same. If a copy change needs the same ceremony as a payments change, one of two things happens: either you drown, or people route around you.

So split the repository by blast radius, not by author.

Lane A. Content and configuration. Marketing pages, translation files, feature flag defaults, documentation, analytics event names, design tokens. One owner approval, green CI, merge. This is where most non-engineer contributions will land, and the worst realistic outcome is an embarrassing typo in production for twenty minutes.

Lane B. Everything that can lose money or data. Authentication, billing, database migrations, permissions, infrastructure, anything touching PII. Two engineer approvals, plus whatever security checks you run. No exceptions, including for you.

CODEOWNERS

/src/content/      @content-team @eng-any
/locales/          @content-team @eng-any
/config/flags/     @product @eng-any
/docs/             @anyone

/src/auth/         @security @platform
/src/billing/      @payments @platform
/migrations/       @platform @dba
/infra/            @platform

Then turn on the three things that make it real: branch protection with no direct pushes, required status checks, and a merge queue so CI tests the merged state rather than the state of each pull request in isolation. That last one matters more than it used to, because a higher volume of concurrent small changes means more pairs that pass individually and fail together.

Why this is your job specifically

Because it is the thing on this list that a product manager categorically cannot do for themselves.

They can describe a feature. They can now, with a good agent, implement a plausible version of it. What they cannot do is design the containment: decide which paths are dangerous, encode that in ownership, and set the gates so that their own enthusiasm cannot take down checkout on a Friday.

This is worth being clear-eyed about. Every one of these guardrails is also a constraint on you. That is the point. A rule you exempt yourself from is not a rail, it is a suggestion with extra steps, and the first time you merge to main directly to fix something quickly, the policy is over.

Try this week

Open your repository settings and answer one question: can anyone push directly to main?

If yes, that is your afternoon. Turn on branch protection, require one approval, require your existing CI to pass. You do not need CODEOWNERS or a merge queue on day one.

Then write the two lanes down somewhere people will see them, in plain language, listing the paths. Not as a policy document. As four lines in the repository README that answer the only question a non-engineer actually has, which is “am I allowed to touch this?”