· DYNOKORE TEAM

When a colleague's AI-generated pull request lands on you

When a colleague uses an agent to write a large change and asks you to review it, the cost of that change moves to you. Engineers describe huge pull requests, intent that doesn't match the business, and authors who can't explain their own code. Stricter review alone doesn't fix it; the review needs something fixed to check against, and a limit on what can be submitted.

What we found

We went through about 7,000 Hacker News comments from the past year about working with coding agents, and kept 178 in which an engineer described something that actually went wrong for them. In 23 of those, the problem wasn't their own agent. It was AI-generated work from someone else (a teammate, a contractor, a manager or an open-source contributor) that they were expected to review, fix or take over. We rated 6 of those 23 as high severity, more than any other theme in the sample.

The same patterns came up again and again:

  • Size. Pull requests of thousands of lines, every day. One engineer spent hours on a single 3,800-line shell-script change from a contractor who couldn't answer basic questions about the system. (source)
  • The wrong problem, solved confidently. Teammates fed half-finished code to a model and sent back versions that got the business requirements wrong. (source)
  • Work that doesn't fit. A feature from another team had to be stripped down and redesigned for more than a week before it fit the main API. The engineer who did the fixing was the one who looked slow. (source)
  • Proof that isn't proof. Scripts that print what the author expects to happen, instead of demonstrating that it does. (source)
  • Debt merged under deadline. A lead let contractors' fast AI code through to hit a budget, and is still cleaning it up. (source)

Open-source maintainers described the same thing at larger scale: a flood of generated pull requests acting like a denial-of-service attack on their attention. (source)

What people tried

Most responses fell into three groups:

  • Review harder. Raise the bar, reject "AI slop", read every line. It works until the volume grows, and it makes the strict reviewer unpopular.
  • Restrict who can use agents. New hires limited to planning mode until they understand the codebase. Some engineers stopped using agents altogether.
  • Remove the source. One lead let the contractors go.

Each of these puts the whole load on the reviewer's judgement, at the end of the process, after the work is done. None of them changes what arrives for review.

What actually helps

The common thread in these stories is that the reviewer has nothing fixed to check against. They have a diff and a description, both written by the same person (or the same agent), and they have to work out what the change was supposed to do before they can decide whether it does it. These are the changes that help, whatever tools you use:

  1. No pull request without a stated requirement. Before work starts, write down what the change is for and how you'll know it works, precisely enough that a test can check it. The reviewer then checks the change against that, not against a guess.
  2. The author can't move the target. If the acceptance criteria live somewhere the author (or their agent) can't edit, nobody can make a change pass by quietly redefining "done".
  3. Proof means running checks. A test that exercises the behaviour, in CI. Not a script that prints a success message, and not the author's say-so.
  4. Cap the size. A change too big to review isn't reviewed, whoever or whatever wrote it. Split it, or send it back.
  5. The same gate for everyone. Human-written, agent-written, contractor or senior engineer: one set of checks. Then the argument stops being about who used AI, and becomes about whether the change does what was asked.

How we handle it

At DynoKore most of our code is written by agents, so "someone else's AI output" is our normal day. We built DynoKore Keel so that what arrives for review is already anchored. Requirements, acceptance criteria and tasks are versioned records, and every change traces back to them. Tests must prove those acceptance criteria, and the coding agent can't change them. An independent reviewer agent checks every merge request, including any change to tests. A task can't be marked done until its requirement chain exists and passes Keel's readiness check.

We're a small team, and our "colleagues" are mostly agents. We haven't yet seen how this holds up across a large organisation with many human authors. That's what our design partners are for.

The short version

If AI-generated work keeps landing on you, the fix isn't reading harder. Agree what "done" means before the work starts, keep that definition out of the author's reach, and send back anything that doesn't prove it.

This is part of What Breaks, our series on what actually goes wrong when teams build with coding agents. If this matches what you're seeing, or doesn't, tell us at [email protected]. We're opening DynoKore Keel to a small group of design partners: dynokore.ai.