What if the most valuable thing you can do with a writing-capable machine is refuse to let it write?
I’ve spent enough time reviewing tools in this category to notice a pattern that runs against the sales pitch. The people getting the most out of LLMs in 2026 aren’t the ones generating the most text. They’re the ones who’ve drawn hard lines around what the model is allowed to touch. And prose is usually the first thing on the wrong side of that line.
The rule that keeps showing up
One developer’s operating instruction for their model is blunt: never write READMEs, docstrings, or comments. They’ll write those themselves later. And they mean it literally, not as a soft preference.
A staff engineer writing about their 2026 workflow lands in the same place from a different direction. They almost always write their own PR descriptions, because LLMs over-communicate and are bad at expressing the core idea behind a change. There’s a second reason too, and it’s the more interesting one: writing the description by hand signals something to the reviewer.
Two independent practitioners, same conclusion, arrived at separately. In tool-review terms, that’s about as close to a reproducible result as this field gets.
Over-communication is the actual failure mode
Notice that the complaint isn’t “the output is wrong.” It’s that there’s too much of it and the center is missing. That’s a specific defect, and it explains why so much LLM-assisted writing feels simultaneously exhausting and empty.
A PR description has one job: tell the reviewer why this change exists. The model doesn’t have access to that. It has access to the diff. So it describes the diff, thoroughly, at length, in bullet points, and the reviewer still doesn’t know why you did it. You’ve traded a paragraph of intent for a page of restatement.
Same problem with docstrings. A docstring that narrates the function signature back to you is worse than no docstring, because now there’s something to maintain. Comments follow the same logic. The comment you actually need explains the constraint that isn’t visible in the code, and that constraint lives in your head.
So where does it earn its keep
Drafting. Not finishing. LLMs are genuinely used for drafting PR descriptions and generating test code in 2026, and manual edits remain necessary in both cases. That’s the honest framing: the model produces a starting position, you produce the thing that ships.
The code side is where the tooling has matured furthest. Developers lean on these models for code generation and orchestration, splitting work into parallel streams to move faster. One workflow I’ve seen described involves building an orchestrator instructions file once the workstreams are identified, containing the operational rules for how the orchestrator delegates to subagents. That’s real engineering. It’s also notably not “writing.”
The expectation to calibrate against is 2x, not 10x. That framing comes from someone who works this way daily, and it matches what I see when I test these setups myself. Doubling your throughput is a good outcome. It’s just not the outcome anyone is advertising.
The inversion worth trying
There’s one use of these models for writing that I think is underrated, and it flips the usual direction. Instead of asking the model to produce your document, hand it your document and ask it to check.
The setup is simple: you have an article, a list, a set of requirements. Markdown is good input for a model. So rather than manually verifying every item against every claim, you pass the whole thing over and ask it to make sure things line up.
That plays to what the technology is genuinely good at. Reading a lot of text carefully and consistently is a mechanical task. Knowing what you meant is not. Most people have these two assignments backwards, which is why their output reads like it was generated, because the interesting part was outsourced and the boring part was kept.
What I’d actually recommend
Write the human-facing prose yourself. PR descriptions, READMEs, commit messages that explain intent, anything a person reads to understand your reasoning. These are short. They’re not the bottleneck. And the cost of getting them wrong is a confused reviewer or a future maintainer who trusts a stale comment.
Give the model the volume work. Test scaffolding, first-draft implementations, parallel workstreams with clear boundaries, verification passes over documents you’ve already written. Expect to edit all of it.
The tools have gotten better. The division of labor is what most people still get wrong, and no model update fixes that. It’s a decision you make before you open the terminal, and the practitioners who made it deliberately are the ones producing work that doesn’t need an apology.
🕒 Published: