Five red flags in agent pull requests, and where each shows up in a diagram

GitHub's engineering blog lists five red flags in agent-written pull requests: CI gaming, code reuse blindness, hallucinated correctness, agentic ghosting, and untrusted input in workflows. Four of the five leave a mark on the structure of the change, which means you can spot them in a diagram before you read a line. The fifth does not, and it is worth being clear about that. The stakes are set by LinearB's 2026 benchmarks: across 8.1 million pull requests, the acceptance rate for AI-generated pull requests was 32.7 percent against 84.4 percent for manual ones.

I use PR Lens for this, so treat the specifics as one implementation of a general point: any drawing of a change that keeps the untouched system on the page will do the same work.

CI gaming looks like a struck-through test runner

GitHub's first red flag is the agent weakening the build to make it pass. Removed tests, skipped tests, a lowered coverage threshold, a workflow that stopped running on forks, a step that became conditional. The agent is not being malicious; it was told to make the tests pass, and there are two ways to do that.

This is the easiest one to see drawn, because a removed or modified build component shows up in the same colour language as everything else. Green is new, amber is changed, red and struck through is gone. A test runner in red with a line through it is not a subtle finding.

Look at the infrastructure lane there. Two components struck through. In a diff, those two are a few hundred deleted lines somewhere in the middle of a file list, and deleted lines are the ones reviewers skim hardest. In the picture they are the second thing your eye lands on.

If your change touches .github/workflows at all, read those files first, before the application code. GitHub puts this at minute two of a ten-minute review, ahead of everything except classifying the change.

Code reuse blindness looks like a new box beside an old one

The second flag: agents look for prior art, find a pattern in the codebase, and replicate it without checking whether a utility that already does the same thing exists somewhere else. You end up with a second date formatter, a second retry wrapper, and eventually a second validation helper that disagrees with the first one about what an empty string means.

This is the flag a diagram is best at, and it is entirely because of one design decision: the parts the pull request did not touch stay on the page. A new green component sitting in the same lane as an existing untouched one that does a similar job is visible in about a second. In the hero render above, the broadcast composer at the left was never touched by that pull request. It is on the page so the new batch path underneath it has something to be judged against.

A diff cannot do this. A diff shows you the file that was added. It has no opinion about the file next to it that already existed, because that file has no changed lines and therefore is not in the diff at all. That absence is the whole reason reuse blindness survives review. I have written more about drawing the untouched system in blast radius diagrams.

Hallucinated correctness has no shape

The third flag is code that compiles and passes tests while being wrong: an off-by-one in pagination, a permission check missing on an untested branch, a race that only appears under load.

No diagram catches this. A picture of the structure cannot tell you that the loop bound is wrong, and anyone selling you a drawing tool as a correctness tool is selling you something else. The research is blunt about the underlying risk. In "Is Vibe Coding Safe?" (arXiv 2512.03262), of the solutions produced by SWE-Agent with Claude 4 Sonnet, 61 percent were functionally correct and 10.5 percent were secure.

What the diagram does is decide where you spend the read. GitHub's checklist gives you three minutes, from minute five to minute eight, to trace one critical path end to end. The value of a data-flow render is that it hands you the path to trace, in order, instead of making you find it.

Pick the path that touches money, auth or user data, and read every line on it. Skim the rest. That is a real strategy, and it only works if you know what the paths are.

Agentic ghosting looks like sprawl

GitHub's fourth flag is behavioural: large, unstructured pull requests correlate with the agent abandoning the thread or drifting, and reviewers burning rounds of comments without progress.

You can see this coming. A change that lands in six lanes with no dominant cluster, touching a bit of everything, is a change nobody drove to a point. Compare that with a change that puts four new components in one lane and modifies two things around them.

That one is drawable and still legible, which was the point of building the renderer to handle it. It is also a pull request I would not want to receive. Seeing the sprawl in five seconds, before you have invested three rounds of comments, is worth more than any individual finding in it.

Untrusted input in workflows looks like a new edge to an external lane

The fifth flag is prompt injection and its neighbours: unvalidated user input interpolated into a prompt, an overprivileged GITHUB_TOKEN, model output executed as a shell command, secrets exposed to an agent step. It is the flag on the list I would least want to skip.

Drawn, this appears as an edge. Renders put external services in their own lane, so a new arrow from something inside your system to something outside it, or from an untrusted source into a component that calls a model, is a line you can point at. The diagram gives you the boundary crossings for free. The judgement about whether each crossing is safe stays yours, and it needs the file open.

How to use this in the ten minutes you actually have

The order below is GitHub's checklist with the diagram slotted in where it saves the most time.

1. Open the picture. Classify the change: one lane or six, focused or sprawling.
2. Read the CI and workflow diffs. Look for struck-through build components first.
3. Look for a green box next to an untouched box that does the same job.
4. Follow the external lane. Note every new edge that crosses out of your system.
5. Pick one critical path and read it line by line.
6. Ask for test evidence that the new tests fail against the old code.

Six steps, and only two of them involve reading code.

The longer version of this method, including where drawn review sits against automated finders, is the pillar for this cluster: reviewing AI-generated pull requests. If you would rather have it as something you can paste into a repository, there is a code review checklist for agent-authored code, and if the pull request in front of you is already 400 lines long, the ten-minute routine is the one to follow.