Your team has used AI for a year. Output went up. And every change still lands on the same one engineer's desk before it can ship.

You know the name. On some teams it is two names. They review most of the pull requests. They get pulled into every design call. When production breaks at 4:40 on a Friday, they are the ones who open the logs.

AI was supposed to spread the work out. Instead it stacked more of it on them.

More Code, Same Reviewers

A year ago your team had five people who could ship a feature. Now everyone can. Product managers open pull requests. Junior developers finish tickets in an afternoon when it used to take them a week.

But the number of people who can tell whether that code belongs in your system did not change. It is still the two seniors.

So the pull request queue grew. The review comments grew with it. And the seniors spent less time on the work only they can do, because they were busy writing the same comment for the twentieth time.

I have led engineering teams for a long part of my 29 years in software, including as CTO at multiple companies. I have been the name on the review queue since before anyone called it a pull request. I know what it costs. You lose your best architect to a job that is mostly proofreading.

The fix is not to skip review. The fix is to look at what the senior writes in those reviews and sort it.

One Pull Request, Four Comments

Here is a pull request. Every comment on it is one I have written myself, more than once.

A mid-level developer used an AI tool to add an endpoint that lets a customer approve an invoice. Clean diff, 300 lines, tests pass. The senior opens it and leaves four comments.

Comment 1. "This endpoint returns a raw string on failure. Use OperationResult like every other endpoint in the API."

Comment 2. "The service catches the exception, logs it, and returns null. The caller cannot tell it failed. Let it fail or return a failure result."

Comment 3. "No integration test on the new endpoint. Every endpoint gets one."

Comment 4. "This puts the approval rule inside the payment service. Approval and payment change for different reasons, and finance already asked for approvals that do not trigger a payment. Split them now, while it is 300 lines and not 3,000."

Read those four again. Three of them share something. One does not.

Two Piles

Comments 1, 2, and 3 are Repeat Review. A Repeat Review comment is one your best engineer has left before, on a different pull request, for the same reason. The senior did not need to be senior to write it. They needed to remember the rule. Search that repo's review history for "OperationResult" or "integration test" and you will find the same comment with different dates on it.

Comment 4 is Judgment Review. It depends on things the senior holds that no file holds yet: what finance asked for last month, how the payment service grew, what it cost the last time two concerns shared one class. Nobody else on the team could have written that comment. And the AI that wrote the code could not have written it either. It had never heard of finance.

The senior is worth their salary for comment 4. Comments 1 through 3 are why they aren't satisfied with their jobs any longer.

Now count. On that one pull request, three quarters of the senior's review effort went to rules the team already agreed on. That ratio is normal. On many teams, it is worse.

Want to see the count for your own repo? One prompt reads 30 days of pull requests and hands you a short report with links to the evidence.

Move the Repeat Pile Out of the Comment Box

A Repeat Review comment is a rule that was never written down where it counts.

The team knows the rule. The senior knows the rule. The AI tool that wrote the code does not, because the rule lives in the senior's head and in 40 closed pull requests. So the AI guesses, the guess is wrong the same way every time, and the senior types the fix into a comment.

Move it. Two steps.

Write the rule where the AI reads it. Your AI tool loads instructions from a file in the repo. Put the three rules there, as three lines. "Endpoints return OperationResult." "Services do not swallow exceptions." "Every endpoint gets an integration test." The next pull request from that same developer, with that same tool, comes in without comments 1, 2, and 3. Not because the developer got better. Because the tool finally knew the rule.

Back the rule with a check that runs. A written rule is a request. A rule with a check is a rule. An analyzer catches the raw string return. A test that walks every controller catches the missing integration test. The build fails and no human types a word. The senior never sees the pull request until it passes.

Now look at what is left in the review queue. Comment 4. The judgment call. The thing the senior is for.

Review did not disappear. It got smaller and it got harder, which is what senior review should be.

The Repeat Review Test

Here is the test, and you can run it on your next review without asking anyone.

Before you post a comment, ask one question:

Have I written this before, on a different pull request, for the same reason?

If no, post it. That is your judgment, and the team needs it.

If yes, do not post it as a comment. Post it as a rule. Put the line in the file your AI tool reads, and open a ticket for the check that will enforce it. Then post the comment one last time with a link to the rule.

One comment at a time, the repeat pile drains. Six months in, your best engineer reviews fewer pull requests and every one of them needs them.

Find the Repeat Work in Your Repo

You can do this on a napkin with your own memory. Or you can let your AI tool read the review history and count.

I wrote one prompt for that. Run it against one repo. It reads the last 30 days of pull requests and review threads and looks for three things: work waiting on review, the same correction made in separate changes, and fixes for defects an earlier change caused. It hands you a short report: up to three findings, a link to the evidence behind each one, what each may mean (with the other explanation that would change your mind), and one next step or one question for your team this week. It also tells you what it could and could not check. When the records do not support a finding, it says it found no strong signal and stops. No developer rankings. No invented hours saved. No sales pitch at the end.

One prompt. One repo. A short report with links to the evidence. The form is at the bottom of this post.

Where This Fits in Intelligent Engineering

Intelligent Engineering is the operating model for engineering organizations in the AI era. It is what comes after vibe coding. Your developers have AI. Your organization does not, and that is why the backlog still grows and the tech debt piles up. Intelligent Engineering gives the organization the AI. Your architecture, standards, and decisions live in one place, reach every tool and every session, and cannot be overruled from a developer's machine. Work runs from the backlog, so you can see it and manage it. Every change is proved by a check that runs, so you can answer for it. The result is software your team can trust, support, and scale.

Repeat Review is the smallest version of that model. One rule, written once, read by every tool, held by a check. Your best engineer stops being the check and goes back to being the judgment.

Your Best Engineer Is Not the Bottleneck. The Missing Rules Are.

When every change waits on one person, the easy read is that the person is the problem. Hire another one. Split the queue.

That misses what they are doing all day. Most of it is Repeat Review. The rules exist. Nobody wrote them where the AI and the build could read them, so a human reads them out loud, one pull request at a time.

Write them down. Add the check. Give your best engineer back the work only they can do.

Chad

If you want the prompt that finds where reviews and rework hold up your team, the form is below.

If you ran it and did not like the report, that is worth a conversation. Book the Intelligent Engineering Assessment. It is free, and it is two calls. The first is a diagnosis: how your team builds today and where the review load is piling up. The second is a prescription: the best path forward I can see, and whether I have a role in it. Sometimes I do not, and I will tell you so.