How to merge AI code safely on a busy team

Triage the diff before you read it

To merge AI code safely, sort the change into three buckets and give each a different level of attention. Mechanical edits, renames, import reordering, formatting, get a skim and a green pipeline. Logic changes inside existing functions get a careful read. Anything touching auth, money, permissions, data deletion, or an external boundary gets read line by line, out loud if it is late in the day.

Doing this consciously beats the default, which is reading the first thirty lines carefully and the remaining four hundred with rapidly declining attention.

The bugs that get through

Generated code fails differently from hand-written code, and review habits tuned for humans miss the difference.

• Plausible but wrong constants. A timeout of 30 seconds where your infrastructure uses 5, a retry count copied from a generic example.
• Silently swallowed errors. A try block wrapping more than it should, with a log line and no rethrow.
• Duplicated helpers. A new utility that already exists two directories away under a different name.
• Tests that assert the implementation rather than the behaviour, so they pass and protect nothing.
• New dependencies added to solve something your standard library already does.

The fourth one is the most expensive because it looks like diligence. When a diff arrives with generous test coverage, check that at least one test would fail if you deleted a line of the new logic. If none would, the coverage is decorative.

Automate the checks humans are bad at

Human attention should go to intent, because machines cannot judge it. Everything else belongs in the pipeline. Run a secret scanner in pre-commit. Print the lockfile diff into the pull request body so a new package cannot arrive unnoticed. Enforce a coverage floor rather than a target. Fail the build on new lint suppressions, since a stray eslint-disable is one of the more common quiet workarounds in generated code.

Then add the cheapest control of all: a size cap. Pull requests over a few hundred changed lines get split. Not because large diffs are wrong, but because review quality falls off a cliff and everyone knows it.

Ask the author to explain one thing

Our favourite review practice needs no tooling. Pick one non-obvious block in the diff and ask the author why it is written that way. If they can answer, they read it. If they cannot, you have learned something more useful than any static check could tell you, and the fix is a conversation rather than a policy.

This works because it is not adversarial. Nobody is being accused of anything. It simply makes reading the code the path of least resistance, which is the entire goal.

What to do next

Write your team's three-bucket triage rule into the pull request template this week, with your own list of always-read areas. Then pick the single automated check you are missing, most teams are missing the lockfile diff, and ship it. Those two changes cover more risk than a policy document will.

If you want help putting this into practice, talk to us.