Good writing is a boundary problem.
Not a talent problem, not a speed problem. When people ask me how to write with an LLM, they usually want a prompt. What they actually need is a line in the sand: which words belong to the machine, and which words belong to them. And the most interesting place to look for that line right now isn’t in marketing or journalism. It’s in software, where developers have spent 2026 quietly working out what they’ll hand over and what they won’t.
Two kinds of writing, two very different answers
If you look at how developers actually use these tools in 2026, a pattern shows up. LLMs assist with things like PR descriptions (the short note explaining a set of code changes) and generating test code. But developers still write their own comments and READMEs, the explanations that sit inside the code and the front-door documentation that tells a newcomer what a project is for.
One developer put it about as bluntly as you can: “Never write READMEs, docstrings, or comments. I will write those myself later. And yes, I really mean this.” That’s an instruction to the model, not to a human colleague. It’s a fence.
Translate that out of software and it lands somewhere useful for the rest of us. The machine can produce the scaffolding, the variations, the repetitive material. The parts where you explain why something exists, in your own voice, to a person you’re picturing? Those stay yours.
Where the disagreement lives
Here’s something I find genuinely clarifying: experienced people don’t agree on where the fence goes. Some use LLMs to help write PR descriptions. A staff engineer writing about their 2026 workflow takes the opposite position, saying they almost always write their own, because LLMs over-communicate and are bad at expressing the core idea behind a change. Writing it by hand also signals something to reviewers.
Two observations sit inside that. First, over-communication is the characteristic failure mode. Not errors, not nonsense. Too much. The model gives you eleven accurate sentences where two would land harder, and it doesn’t know which two those are because it doesn’t know what you were actually trying to do.
Second, writing something yourself is a signal. The effort communicates care to the person reading it. That holds for a code review note and it holds for a message to your team, a note to a client, or a condolence card.
Plan first, and stop reaching for the output
The most transferable habit I’ve seen has nothing to do with prose quality. It’s about sequence. A common mistake is going straight to generation with a vague prompt. The better pattern is to brainstorm a detailed specification with the model first, then outline the steps, and only then produce the thing.
For writing, a specification looks like this:
- Who reads this, and what do they already know?
- What single idea do they need to walk away with?
- What am I not covering, so the draft doesn’t sprawl?
- What tone would feel wrong here?
Sort that out in conversation before you ask for a single paragraph. It’s slower at the start and dramatically faster overall, because you stop rewriting drafts built on the wrong premise. Most bad LLM writing isn’t badly written. It’s well-written material aimed at nobody in particular.
Minimal edits are possible, on the right material
Some developers now produce entire PRs with minimal edits from the model. That’s real, and it’s the natural endpoint of good specification work. But notice what that applies to: structured, verifiable output, where you can check whether it’s correct.
Your writing rarely has a test suite. A paragraph can be fluent, plausible, and completely off the mark, and nothing will tell you except your own judgment. So the minimal-edit approach fits the parts of your writing that have obvious right answers — formatting, summaries of material you’ve supplied, reworking one thing into five variants. It fits the parts carrying your judgment much less well.
A practical starting point
If you want one habit to try this week, try this. Before your next writing session, write down two lists: what you’re delegating, and what you’re keeping. Then tell the model your keep-list explicitly, the way that developer did. Models follow instructions about restraint far better than most people expect, mainly because almost nobody gives them any.
The people getting real value out of these tools aren’t the ones who found a magic prompt. They’re the ones who decided in advance which sentences they’d be ashamed to outsource, and then protected those. That decision is yours to make, and honestly, it’s the interesting part of the work.
🕒 Published: