2x, not 10x. That’s the honest multiplier a lot of working developers landed on for coding with LLMs in 2026, and it’s the number I keep coming back to when someone tells me their agent setup replaced half their team. Two times faster is genuinely great. It’s also nowhere near the story being sold.
I build bots for a living. Orchestrators, subagents, task routers, the whole stack. And the thing that surprised me most this year wasn’t how much the models could write. It was how sharply the line fell between what I hand off and what I keep.
The rule that changed my workflow
One developer put it bluntly in their 2026 writeup: never let the model write READMEs, docstrings, or comments. They write those themselves, later. And they meant it literally.
I came to the same conclusion by accident, after a week of reading generated docstrings that described exactly what the function did and nothing about why it existed. The code was fine. The prose was noise with good grammar.
That distinction is the whole trick. Code has a specification. There’s a correct answer, or at least a testable one. Prose about code has intent behind it, and intent lives in your head, not in the diff.
PR descriptions are the sharpest example
A staff engineer writing about their 2026 workflow said they almost always write their own PR descriptions, because LLMs over-communicate and are bad at expressing the core idea behind a change. Writing the description by hand also signals something to reviewers.
Both halves of that matter, and the second half matters more than people admit.
Over-communication is a real failure mode. Ask a model to describe a change and you get a bulleted tour of every file touched. Technically accurate. Completely useless for a reviewer who needs to know that you moved retry logic out of the request handler because the handler was swallowing timeouts.
The signal part is subtler. A hand-written PR description tells your reviewer you thought about the change as a whole. It’s a small act of accountability. Generated descriptions flatten that. Everything reads the same, so nothing reads as considered.
Worth naming the tension here: LLMs are widely used for drafting PR descriptions in 2026. They’re also used heavily for generating test code. In both cases, manual edits are still necessary. So the practical question isn’t whether to use the model. It’s how much of the draft survives contact with your own judgment, and whether editing a bad draft is faster than writing a good one from scratch.
For test code, editing usually wins. For PR descriptions, I’ve found writing from scratch wins almost every time.
Where I actually point the models
My setup leans on splitting work into parallel streams. Once I have the workstreams mapped, I build an orchestrator instructions file for the task — operational rules for how the orchestrator delegates to subagents and how it hands results back.
That file is the most valuable artifact in my repo, and I write every line of it myself. It’s the one place where being precise about intent pays for itself across dozens of runs.
What the subagents get:
- Code generation against a clear spec
- Test code, with the understanding that I’ll edit it
- Mechanical transformations across many files
- Parallel exploration of approaches I’d otherwise try one at a time
What stays with me:
- PR descriptions
- READMEs, docstrings, inline comments
- Orchestrator instructions and task decomposition
- Anything a future human reads to understand a decision
The one writing task I do hand over
There’s an inversion here that took me a while to spot. Models are weak at generating prose that carries intent. They’re good at checking prose I already wrote.
Markdown turns out to be an excellent input format for this. I hand over a draft or a checklist and ask the model to verify every item holds, instead of walking through it line by line myself. One practitioner described exactly this move in a 2026 talk on LLM architecture — feed the article in, have the model audit the list.
Generation versus verification. Same model, wildly different hit rates. If your writing workflow only uses the generation half, you’re using the weaker capability and skipping the stronger one.
What 2x actually buys you
Two times faster on the mechanical work means the constraint moves. It’s no longer typing speed. It’s deciding what to build, how to split it, and what to say about it afterward.
Which is a strange outcome for anyone who expected writing to be the first thing automated. The code got faster. The words about the code got more valuable, because they’re now the part only you can produce.
So let the bots write the code. Keep the words. That’s not sentimentality about craft — it’s just where the use sits when everything else speeds up.
🕒 Published: