Why I think we should write our own PR descriptions | Laravel - The clean stack for Artisans and agents

Agents can write your PR descriptions, but they shouldn't. Here's why writing them yourself makes you a better engineer and a better teammate.
I think we, as developers, should write our own pull request descriptions, even when an agent has done most of the implementation.
Not because Claude or Codex can’t write them. They can, and they’ll normally produce something far more comprehensive than I would.
I think we should write them ourselves for two reasons:
Writing the description forces us to understand and explain the change we’re putting up for review.
The person reviewing the PR needs context from us, not a summary of the diff from the agent that wrote it.
Many developers are handing the actual implementation of our work over to agents, which is not necessarily a bad thing. They’re good at it. Really good in most cases.
But as we hand over more of the writing of the code, I think it’s important that teams find ways to stay in touch with that code and the changes being made.
Pull request descriptions are one of those ways.
If an agent has written the code, the tests, the commit message, and the PR description, where exactly are we forcing ourselves to understand and explain the change?
Hopefully, we’re all reviewing the code our agents produce, and I’m certainly not suggesting that using an agent-generated description means you don’t understand your changes.
But writing the description yourself creates a kind of natural checkpoint.
“What actually changed here?”
“Why did it change?”
“Are there any consequences that aren’t obvious from the diff?”
“What does the person reviewing need to know?”
If you can’t answer those questions without asking the agent to explain its own work back to you, that’s probably a sign that you need to spend a little more time with the change.
There’s also something that I’m now calling “Claude confidence.”
Claude is incredibly confident. It'll make a change, run some tests, and then tell you that everything is correct, robust, backward compatible, and ready to ship.
And to be fair, quite often it’s right. But “Claude is confident” and “I understand this change” are two different things.
It’s easy to inherit the agent’s confidence, particularly when it wrote both the implementation and the explanation of why that implementation is correct.
As these tools improve, I think we need to be conscious of that. It’s easy to become good at describing a problem, sending an agent on its way, and then evaluating the result at a fairly high level.
There’s a more practical reason here too. The descriptions that Claude generates are comprehensive, telling you what changed, why it changed, which files changed, how it was tested, and what’s… load-bearing, for some reason.
A pull request description is not there to contain every detail about a change. That’s what the diff is for.
A pull request description is there for another human to read. It should give them enough context to understand:
how it fits into the wider piece of work
anything weird, risky, or non-obvious
anything you'd particularly like their thoughts on
It should be brief, but useful.
Here’s a slightly exaggerated version of the kind of PR description you often get when an agent opens a PR:
This PR improves the workspace deletion flow by adding validation to prevent users from deleting a workspace while it has active deployments.
Added hasActiveDeployments check to deleteWorkspace
Added a new WorkspaceHasActiveDeploymentsError
Updated the workspace deletion API handler to return a 409 response
Added unit tests covering workspaces with and without active deployments
Updated the API response types
Added error handling to the workspace settings UI
Added a user-facing error message when deletion is blocked
The deleteWorkspace function now queries the deployments repository before performing the existing deletion logic. If one or more active deployments are returned, the function throws a WorkspaceHasActiveDeploymentsError. The API layer catches this error and maps it to a 409 response...
Added unit test for deletion with no active deployments