2x. Not 10x. That’s the multiplier a growing number of working engineers are putting on their LLM-assisted output going into 2026, and it’s the most useful number I’ve seen all year. It’s honest. It’s repeatable. And it quietly explains why the most productive people I know hand parts of their writing to a model and stubbornly refuse to hand over the rest.
I build bots for a living. That means I spend my days writing prompts, orchestrator files, and specs, then reading what comes back. Over time I’ve landed on a split that keeps surprising people: I let the model write a lot of code and almost none of my prose. Turns out I’m not alone. One of the rules making the rounds this year is blunt about it — never write READMEs, docstrings, or comments with an LLM. I’ll write those myself later. And yes, I really mean this.
The split that actually works
Here’s how the division falls out in practice for most developers I’ve compared notes with in 2026:
- LLM territory: PR descriptions (for some people), generated test code, detailed specifications, step-by-step plans before any code is written, and increasingly entire PRs that need minimal edits.
- Human territory: comments, docstrings, READMEs, and — for a lot of staff-level engineers — the PR description itself.
That last one deserves attention because it’s the most contested. Plenty of teams happily generate PR descriptions. Plenty of senior engineers refuse. The reasoning I find most convincing is that LLMs over-communicate and are bad at expressing the core idea behind a change. A model will tell you every file it touched. It will not tell you why the change exists, because that lives in your head, in a Slack thread, in a bug report you read three weeks ago.
There’s a second reason, and it’s social. Writing the PR description by hand signals something to your reviewer. It says: a person thought about this, and that person is accountable for it. When a reviewer opens a PR and sees a wall of generated bullet points, they read differently. They read defensively.
Why comments are the wrong job for a model
Comments and docstrings fail for the same reason PR descriptions do, only worse. A generated comment describes what the line does. You can already see what the line does — it’s right there. The comment you actually need explains the thing that isn’t in the code: the API that returns nulls on Tuesdays, the retry count someone tuned by hand after an outage, the reason this function is uglier than it should be.
A model has no access to that context. So it produces the comment equivalent of narration. Worse, generated docs rot silently. Nobody feels ownership over text they didn’t write, so nobody updates it, and six months later your README describes a system that no longer exists.
Where LLMs earn their keep
The upstream work. A common mistake is going straight to code generation with a vague prompt. The better pattern, and the one most experienced practitioners describe, is brainstorming a detailed specification with the AI first, then outlining the steps, then generating code against that plan.
This is where the 2x comes from. Not from typing faster. From thinking out loud with something that responds instantly, catches the case you forgot, and produces a written plan you can argue with before a single file changes.
My own setup leans on that. Once I’ve broken a task into workstreams, I build an orchestrator instructions file — the operational rules for how the orchestrator delegates work to subagents and how it should behave when things go sideways. That file is effectively prose I wrote for a machine audience, and writing it by hand is the whole point. It’s where my judgment lives.
A workflow you can copy today
- Spec first. Talk through the problem with the model until you have a written specification detailed enough to disagree with.
- Plan second. Break the spec into ordered steps. Review them. Reorder them.
- Generate third. Code and tests, against the plan, not against a vibe.
- Write the prose yourself. PR description, comments, README. Last, by hand, when you understand what you built.
The pattern underneath all of this: use the model for volume and structure, keep the parts where meaning is compressed into a few sentences. Code is verbose and mechanical, which is exactly what LLMs are good at. A README is short and dense with intent, which is exactly what they’re bad at.
2x is a good number. It’s what you get when you stop expecting the model to know why your project exists, and start using it for everything else.
🕒 Published: