Zero. That’s how many pull request descriptions I let a model write for me last year, even though the same models produced most of the diffs underneath them. If you only take one thing from this post, take that ratio. It’s not technophobia. It’s a deliberate split between the writing an LLM is genuinely good at and the writing where it quietly makes you worse.
Going into 2026, the common pattern is that models draft PR descriptions and generate entire pull requests, with the weight of the work shifting toward testing and review. That’s real, and I use it. But the same year has produced a counter-current worth paying attention to. Plenty of senior engineers write their own PR descriptions by hand precisely because models over-communicate and struggle to express the core idea behind a change. Hand-writing that summary also sends a signal to reviewers: a human understood this well enough to compress it.
Writing is the planning step, not the cleanup step
The most expensive mistake I see in bot-assisted development is going straight to code generation from a vague prompt. Addy Osmani has described the alternative clearly: brainstorm a detailed specification with the model first, then outline before any code gets produced. That’s the shape my own workflow has taken too.
In practice, the first artifact of a feature isn’t a file in src/. It’s prose. I open a chat and describe the problem in plain language: what’s broken, what the constraints are, what I already tried, what I refuse to change. Then I ask the model to restate it back as a spec and list what it thinks is ambiguous. That list is the actual value. Nine times out of ten it surfaces a decision I was hand-waving past.
The spec is where you want the model’s tendency toward thoroughness. Spec documents benefit from over-communication. PR descriptions don’t.
What a good pre-code writing pass covers
- The user-visible behavior change, in one sentence
- Files and modules you expect to touch, and the ones that are off-limits
- Test cases that must pass, written before implementation
- Open questions you want answered before generation starts
- Explicit rejection of approaches you already ruled out
Orchestrator instructions are a writing exercise in disguise
Once the spec splits into workstreams, I write an orchestrator instructions file. It holds operational rules: how work gets delegated to subagents, how results come back, what each one is allowed to touch. This is the part of bot building that people underestimate as writing. It reads like a technical memo to a team that takes everything literally.
Writing these files teaches you something about your own thinking. Vague instructions produce vague delegation, and you feel it immediately in the output. Ambiguity in an instructions file isn’t a style problem, it’s a runtime bug. If you want to get better at prompting, get better at writing procedures.
Two habits that help. First, write rules as constraints rather than encouragement — “do not modify the migration files” beats “be careful with migrations.” Second, keep the file in version control next to the code. When a run goes sideways, you want the diff of your instructions, not a vibe-based recollection of what you asked for.
The part where you close the chat window
Not every writing task wants a model in the loop. There’s a real thread of developers in 2026 deliberately keeping LLMs out of their workflow, and the tooling has quietly cooperated. LibreOffice, of all things, has become a reliable place to write, with the rough edges of years past smoothed out by the time people reinstall it on a new machine. No autocomplete leaning over your shoulder, no suggestion box finishing your sentence before you’ve decided what it means.
I keep that option open on purpose. Design docs I want to think through, postmortems where the honest version matters, PR descriptions where compression is the whole point — those go in a plain editor. The friction of typing every word is the feature. A model will happily produce three paragraphs describing a change that deserves two lines, and reviewers will read all three and learn less.
A split worth copying
The workflow I’d recommend to anyone building bots: use the model heavily for the writing that precedes code and the code itself, then take the pen back for the writing that represents your judgment to other humans. Specs, outlines, orchestrator rules, test plans — delegate freely and review hard. Summaries, rationale, and anything a teammate will use to decide whether to trust your change — write those yourself.
The models got good at generating pull requests. They did not get good at knowing what a change means. That gap is where your name on the commit still counts for something.
đź•’ Published: