Simon Willison hides agent-written PR descriptions behind a summary

Simon Willison, a developer who writes widely about AI tools, published a short post on 9 November 2026 describing how he handles pull requests written by coding agents. He says most changes to his projects now come as PRs opened by Claude Code or Codex, and that he uses the PR as his unit of work: commits bundled together, iterated on until a feature is done, then merged.

The problem he describes

Willison says agents write PR descriptions that are accurate and comprehensive: the problem, the detailed solution, the steps taken to verify it. His complaint is that this is too much to absorb. In his words it is not necessarily slop, but it reads like slop, and his first reaction to an obviously AI-written PR is that he is not going to read all of it, even when he is the person who drove the agent.

The fix

He keeps the agent's full text but folds it away. The opening paragraph of each PR is chosen as the shortest text that gets a reader up to speed on what the PR is for and whether it deserves more attention. He sometimes adds a screenshot. The full agent-written description follows inside an HTML details element, with the model name, and often the effort level, as the visible summary line, such as "Claude Opus 5.5 Medium".

Willison says this works because details and summary are supported in GitHub Markdown, so the tags can be pasted straight into a PR description or an issue comment. GitHub then shows the summary line with an expansion arrow and hides the rest.

The promise to the reader

Willison says he does not always write the opener himself; sometimes the agent has already produced what he needs, buried in its longer text. His stated rule is that the short opener represents his human judgement about what is worth the reader's time. He lists several recent Datasette PRs where he used the pattern, with the opener he chose for each.

What the post does not say

• It is one maintainer's practice on his own open-source projects, not a team policy or a study.
• It reports no measurements, such as time to review, review defects caught or merge rates.
• It does not address whether reviewers will skip the folded section, which is where an agent's caveats or risky changes may sit.

For a team rolling out coding agents, the pattern is cheap to try: ask authors to write or approve a short opening, keep the agent's text behind a fold, and name the model in the summary so reviewers know what produced it. Whether it improves review quality is something a team would need to measure for itself.