Most people prompt too early.
That’s the single biggest pattern I keep noticing when I watch non-technical folks try to write with an AI model. They open a chat window, type a sentence and a half about what they want, and hit enter. Then they spend the next twenty minutes wrestling with a draft that’s technically about their topic but somehow says nothing they actually meant.
The interesting thing is that the people who use these tools most heavily — engineers who work with them all day, every day — have landed on almost the opposite habit. And their workflow translates surprisingly well to anyone writing an email, a report, or a blog post.
Start with the plan, not the prose
Addy Osmani, who writes about his coding workflow going into 2026, names the mistake directly: going straight to generation with a vague prompt. His first step isn’t producing output at all. It’s brainstorming a detailed specification with the model, then outlining from there.
Swap “code” for “words” and the advice holds. Before you ask for a draft, ask for a plan. Tell the model what you’re writing, who reads it, what they already know, and what you want them to do afterward. Then ask it to propose a structure. Argue with that structure. Cut the sections you don’t need.
This feels slower. It isn’t. A bad outline produces a draft you have to rewrite from scratch, and rewriting someone else’s flabby paragraphs is genuinely harder than writing your own.
What this looks like in practice
- Describe the audience and the goal before asking for text
- Ask for an outline or a list of points, not paragraphs
- Push back on anything that looks like filler
- Only then ask for prose, section by section
Some things you should still write yourself
One detail from a staff engineer’s 2026 writeup stuck with me. He almost always writes his own pull request descriptions — the short summary explaining what a code change does and why. His reasoning: models over-communicate, and they’re bad at expressing the core idea behind a change. Writing it by hand also signals something to reviewers.
Both halves of that matter, and neither is really about code.
Over-communication is the characteristic failure mode of these tools. Ask for a summary and you get five paragraphs where two sentences would land harder. Ask for the point and you get context, caveats, and a recap of the context. The model doesn’t know which idea is load-bearing, because it didn’t do the thinking that produced it. You did.
The signaling part is subtler and, I think, underrated. When you write the short, high-stakes thing yourself — the summary, the apology, the note to your team — people can tell. Effort is legible. A message that reads like it was generated in four seconds communicates exactly that, whatever the words say.
So my rough rule: the shorter and more consequential a piece of writing is, the more likely you should write it yourself. Use the model for the long, structural, grindy work. Keep the sentences that carry your judgment.
Testing and review aren’t optional extras
In 2026, models are being used to generate entire pull requests, not just descriptions of them. The practitioners doing this pair it with heavy emphasis on testing and review. Nobody serious is shipping unreviewed generated work.
Writers don’t have test suites, but the equivalent exists. Read the draft out loud. Check every claim that sounds specific. Ask yourself whether each paragraph earns its place. If a fact appeared in the output that you didn’t put in the input, treat it as unverified until you’ve checked it, because models will produce confident-sounding detail that came from nowhere.
Review is the part people skip, and it’s the part that determines whether the output is usable.
The unfashionable option
There’s a counterpoint worth taking seriously. One writer documenting how to keep these tools as far from their workflow as possible landed on LibreOffice — a plain, free word processor — and found it simply works now. Problems they’d had years ago had quietly been fixed.
I don’t read that as anti-technology stubbornness. I read it as a reminder that a blank document and your own attention remain a completely valid setup. Not every piece of writing needs a collaborator, and the tool that stays out of your way has real value.
What I’d actually tell a friend
Use the model for the parts of writing you dread: structuring a mess of notes, generating options when you’re stuck, breaking a big thing into pieces. Do the thinking before you prompt, and do the judging after. Write the short important stuff yourself.
The goal isn’t to produce more words. It’s to spend your attention on the ones that matter.
🕒 Published: