In 2026, engineers routinely hand an LLM a task and get back an entire pull request, code and all. Those same engineers, in many cases, then sit down and type the PR description by hand.
That contradiction is the most useful thing I’ve seen in AI writing advice all year. The machine that can produce hundreds of lines of working code is the same machine you don’t trust with three sentences of explanation. If you understand why, you understand most of what there is to know about writing with an LLM.
Why the description is harder than the code
One staff engineer’s reasoning, which I keep coming back to, is that LLMs over-communicate and are bad at expressing the core idea behind a change. Both halves of that matter.
Over-communication is the failure mode you’ve already seen if you’ve asked a model anything. You get every fact, weighted equally, arranged in a shape that looks like a summary but functions like an inventory. Nothing was left out, which is precisely the problem. Writing is subtraction. Models are additive by temperament.
The “core idea” failure is worse because it’s invisible. A model can read a diff and tell you accurately what changed. It cannot reliably tell you why that change was the right one, because the why lives in your head, in a conversation from three weeks ago, in a bug report someone mentioned in passing. The model fills that gap with plausible reasoning. Plausible reasoning that happens to be wrong is more expensive than no reasoning at all.
There’s a second reason that engineer mentions, and it’s the one people skip past: writing the description by hand signals something to reviewers. It says a human held this change in their head long enough to compress it. That signal has value independent of the prose quality.
Where the model actually earns its keep
Notice that the same workflows rejecting AI-written PR descriptions lean on LLMs heavily earlier in the process. Addy Osmani’s workflow starts by brainstorming a detailed specification with the AI, then outlining from there. He flags the opposite approach as a common mistake: going straight to code generation from a vague prompt.
That’s the pattern. The model is good at the messy expansion phase, when you have a half-formed intention and need to see it in more shapes than your own brain will generate. It’s bad at the compression phase, when you need to decide what the one thing is.
Some practitioners formalize this. One workflow involves breaking a task into workstreams, then building an orchestrator instructions file containing the operational rules for how the orchestrator delegates work to subagents. That’s not writing with an LLM in the sense most people mean. It’s writing at an LLM, authoring the rules that govern how machine work gets divided. It’s also still a human writing the spec.
The practical split
- Use it to expand. Brainstorming, spec drafts, listing the approaches you didn’t think of, arguing against your own plan.
- Do the compression yourself. The thesis, the summary, the PR description, the thing that tells a reader what matters.
- Write specs before code. The vague-prompt-to-code path is where you burn the most time on the least useful output.
- Treat output as a draft under review. The generated-PR workflows all pair generation with heavy testing and review. That pairing is not optional. It’s the whole reason the workflow functions.
The unglamorous counterpoint
There’s a genre of 2026 writing advice that consists of keeping LLMs as far from your workflow as possible, and one of its recurring notes is that LibreOffice quietly got good. Someone reinstalled it on a new computer and found the problems they’d previously had simply weren’t there anymore.
I find that funny and slightly bracing. A lot of AI writing tooling is sold against a baseline of friction that may no longer exist. Free software got better while nobody was watching. If your writing problem is “my tools annoy me,” an LLM is an expensive solution to a solved problem.
What I’d tell you if we had thirty seconds
The model is a strong first-draft engine and a weak editor of intent. Every workflow that works in practice puts the human at the two ends: setting the spec at the front, and writing the summary that tells other humans what happened at the back. The middle is where delegation pays.
If you find yourself asking an LLM to write the sentence that explains your own thinking, you’ve either delegated too far or you haven’t finished thinking. Usually the second one. That’s an uncomfortable thing to learn from a tool, but it’s the most valuable thing these tools reliably do: they show you exactly where your idea stops being clear.
🕒 Published: