The Agent's PR Description Is a Diff Summary, Not a Risk Summary

The pattern

Every agent-written PR I've merged in the last six months follows the same template:

Added a new helper for parsing dates. Updated three call sites. Added unit tests. Fixed a typo in the README.

It's accurate. It's also useless for review. It tells you what the diff touches, not what the diff risks.

A human engineer who has been burned before will write something closer to:

Added a new helper for parsing dates. This changes how we handle timezones in the invoice export — if a customer's browser is set to UTC-3, the export will now shift by one day. I haven't touched the webhook consumer because that path is event-sourced and doesn't read local time.

That second version takes twenty seconds to write and saves a reviewer twenty minutes. Agents don't write it because nothing in the prompt asks them to.

Why this matters more with agents

With a human PR author, you can ask in the review thread: "does this affect the invoice export?" and they'll know. With an agent, the author on the other side of that thread is another agent call, and the answer it gives is the answer it has already decided.

The cost of a missing risk summary compounds:

• Reviewers trust the diff and merge on autopilot.
• The QA team catches the timezone shift three days later.
• The rollback is awkward because the helper is now imported in four places.
• Nobody writes a postmortem because "it was a small fix."

None of that is dramatic. That's exactly the problem. It's the slow bleed that adds up to a team that stops trusting agent PRs at all.

The cheap gate

I started requiring one sentence at the top of every PR description, regardless of who wrote it:

Blast radius: [one sentence — what shared state does this touch, what does it deliberately not touch, and what should a reviewer smoke-test before merge]

That's it. Not a template with six fields. Not a checklist. One sentence, written before the code is opened for review.

When an agent produces a PR that doesn't have it, I send it back with a one-line comment: "add the blast-radius sentence, then ping me." The agent rewrites the description in about thirty seconds. The second version almost always contains something I would have missed in the diff — "this changes the shape of the webhook payload," "this reads from a table that gets vacuumed nightly," "this only runs when the feature flag is on."

That sentence is the difference between a review and a rubber stamp.

The boundary that doesn't generalize

Worth being honest about: this gate works because the team I'm on ships mostly internal tools and B2B APIs. We don't have a ten-person SRE on call, we don't have a migration that takes four hours, and we don't have compliance sign-off baked into every PR. The one-sentence rule is proportional to our risk.

If you're shipping payment rails or a database migration, the blast-radius sentence is the floor, not the ceiling. You still want the rollback plan, the dual-write window, and the runbook. But even in those environments, forcing the author (human or agent) to write the sentence before review surfaces the obvious misses faster than any linter.

Where this turns into tooling

The natural next step is to stop asking the agent to write the sentence and start checking it. We're experimenting with a CI step that:

1. Parses the diff for files under src/webhooks/, src/jobs/, migrations/, and src/api/.
2. If any of those paths are touched, fails the build until the PR body contains a Blast radius: section.
3. Doesn't try to judge whether the sentence is correct — that's still a human call. It just enforces that the sentence exists.

For API-shaped changes specifically, we also re-run the local OpenAPI diff against the live endpoint as part of the same gate. A blast-radius sentence that says "no API change" while the spec drifted against production is the same failure mode in a different costume. The point isn't to be clever — it's to make the agent say out loud what it already did.

The boring principle

Most agent-coding discipline isn't about prompt engineering. It's about forcing the cheap artifact that humans already produce on autopilot: the one-sentence summary of what could break. Agents won't volunteer it because there's no reward in their training signal for surfacing risk. A gate that asks for it is worth more than a hundred additional review prompts.

Ask for the sentence. Read it. If it's empty, send it back. The whole system gets safer without anyone having to be clever.