It’s 6:40 on a Thursday evening. You have a 380-line diff that touches three services, a migration, and one deeply cursed retry loop. The PR description box is empty and blinking at you. So you paste the diff into a model and ask for a summary, and eleven seconds later you have nine bullet points, two subheadings, a “Motivation” section, and a sentence explaining that the change “improves maintainability and aligns with existing patterns.” All of it is true. None of it is the point. The point is that the retry loop was double-counting timeouts, and everything else in the diff exists to make that fix safe.
That gap — between accurate output and the actual idea — is the most instructive failure mode in applied language models right now, and it tells you more about how to write with these systems than any prompt guide will.
Why models over-communicate
Ask a staff engineer how they use LLMs in 2026 and you’ll often hear a version of the same answer: almost always write your own PR descriptions, because models over-communicate and are bad at expressing the core idea behind a change. I want to be precise about why that happens, because “the model isn’t smart enough” is the wrong diagnosis.
Writing a good PR description is a compression task with a hidden input. The compression part the model can do — it can read a diff and produce a shorter representation of it. The hidden input is the part it can’t reach: your beliefs about what the reviewer already knows, what almost went wrong during implementation, which of the five changes is load-bearing and which four are consequences. None of that is in the diff. It lives in your head, in the Slack thread from Tuesday, in the incident you remember and the model never saw.
So the model does the rational thing under uncertainty about what matters: it keeps everything. Enumeration is what generation looks like when salience is unknown. Length is a symptom of missing context, not of verbosity as a personality trait.
There’s a second effect worth naming. Writing the description by hand signals something to reviewers — that a human read their own change and formed a judgment about it. That signal is cheap to fake and expensive to trust once faked. Which means the value of hand-written prose goes up as machine prose gets better, not down.
Where the models actually earn their keep
The same year in which engineers stopped handing off PR descriptions, they started handing off whole pull requests — generated end to end, then put through thorough testing and review. That looks contradictory until you sort the work by whether salience is known in advance.
- Before the code exists, salience is undefined and expansion is useful. This is why so many workflows now start with brainstorming a detailed specification with the model and outlining before any code gets written. Going straight to generation with a vague prompt is the common mistake, and it’s a mistake precisely because you skipped the step where you decide what matters.
- While the code is being written, salience is encoded in the spec, so delegation scales. Practitioners describe breaking work into workstreams and writing an orchestrator instructions file — operational rules for how the orchestrator delegates to subagents and supervises them. That file is the artifact that carries intent downward.
- After the code exists, salience is known only to you, and expansion becomes noise. This is the PR description. This is the design doc conclusion. This is the one paragraph your manager will actually read.
Read that way, the orchestrator instructions file and the hand-written PR description are the same kind of object: both are human-authored compressions of intent, placed at the exact points where the system would otherwise guess. Everything in between can be generated.
The unglamorous corollary
My favorite data point from this year comes from the other end of the spectrum. Among people deliberately keeping models out of their workflow, LibreOffice comes up as the reliable choice for writing — the old complaints about it having quietly stopped being true somewhere along the way. I find that genuinely funny and also genuinely useful, because it isolates the variable. A text editor with no model in it still produces good writing when a person with a clear idea sits in front of it. The model was never the source of the idea.
So the practical advice is narrower than you’d hope, and more durable. Use models to expand before you know what you think, and to check your work after. Do the compression yourself. When the output feels padded, stop editing the prose and go find the context you failed to supply, because that’s the actual bug. And when you sit down to write the three sentences that explain why a change exists, write them. That part was always the job.
🕒 Published: