In 2026, developers are handing language models entire workstreams — splitting tasks into parallel streams, writing orchestrator instruction files, delegating to subagents like middle managers with a headcount budget. The same developers are also saying, in public, that they will never let those models write a README, a docstring, or a code comment.
Both things are true at once. That contradiction is the most useful thing anyone has said about writing with an LLM in the last year.
The split nobody advertises
Read the field reports and a pattern shows up fast. One developer, writing about coding with LLMs in 2026, puts it bluntly: never write READMEs, docstrings, or comments. I will write those myself later. And yes, I really mean this. Another, a staff engineer describing their actual workflow, says they almost always write their own PR descriptions, because LLMs over-communicate and are bad at expressing the core idea behind a change.
Notice these are not anti-AI people. These are the people running orchestration files and parallel task streams. They’ve given the model more rope than most teams would dare. And they’ve drawn the line in the same place, independently, which is why one of them called the other’s conclusion validating.
So the useful question is not “can an LLM write?” It obviously can produce text. The question is what kind of text falls apart under its hands.
Generation is cheap, compression is hard
Test code and PR drafts are areas where models get used heavily right now, and manual edits are still part of the deal. That’s fine. Test code is expansive by nature — more cases, more coverage, more surface area. Generating it is an act of expansion, and expansion is what these models are built for.
A README is the opposite job. So is a docstring. So is a good PR description. Those are compression tasks. You take a sprawling change and squeeze out the one sentence that explains why it exists. The model, asked to compress, expands anyway. It gives you four paragraphs that describe every file touched and never say what the change is for.
That’s the over-communication problem in a nutshell. It isn’t a prompting failure you can fix with a better system message. It’s what happens when something with no stake in the decision is asked to explain the decision. The model wasn’t in the meeting. It doesn’t know which of the six changes in your diff was the point and which five were cleanup you did because you were already in the file.
The signal you’re throwing away
There’s a second reason to write your own PR description, and it’s the one I’d put on a poster. Writing it by hand signals something to your reviewer. It says a person thought about this and decided what mattered.
That signal is getting scarce, and scarce things get valuable. When every PR body reads like it was inflated to fill space, reviewers start skimming all of them. Your carefully bulleted auto-generated summary trains people to ignore summaries. Two sentences you wrote yourself cut through, precisely because they cost you something.
Where the model actually helps you write
Flip the direction and it gets interesting. Instead of asking the model to produce prose, hand it prose you already wrote. One take on LLM architecture this year framed it well: your article, your checklist, your markdown — feed that in as input and ask the model to check it against your list, rather than reading all those things yourself.
That’s the move. The model is a reader, not an author. Same for orchestration: the instruction files people write for their orchestrators contain the operational rules — how to delegate, how to hand off. That’s a human writing specifications for a machine, not the reverse. The writing that makes agent workflows function is writing you do.
A working split
- Let it generate: test code, first-pass implementation, the expansive stuff where volume is the point and you’ll edit anyway.
- Let it read: your draft against your checklist, your spec against your diff, your docs against reality.
- Write it yourself: READMEs, docstrings, comments, PR descriptions. Anything whose job is to say why.
The part that stings
Nobody wants this answer. The whole appeal of writing with an LLM was skipping the annoying parts, and the annoying parts turn out to be the parts that carry meaning. Explaining your reasoning is slow because reasoning is slow. Outsourcing it doesn’t speed up the thinking, it just hides that the thinking didn’t happen.
Manual edits are still necessary in 2026 even on the tasks models handle well. On the compression tasks, “manual edits” means writing it yourself and pretending the draft helped. Skip the pretending. Save yourself the round trip, and write the four sentences that actually explain your change.
🕒 Published: