2x, not 10x: coding with LLMs in 2026

TL;DR Highlight

LLM coding became useful via feedback loops, but the author sees about 2x productivity, not 10x.

Who Should Read

Backend developers who use LLMs to write code but don't see the productivity gains they expected and want to know why.

Core Mechanics

LLMs got useful thanks to feedback loops
- The author's hypothesis is that adoption rose in 2026 because LLMs became reliable enough to run in automated feedback loops.
- They can build a button, click it, and verify it works, moving toward the goal in meaningful steps.
Staircase analogy: one step is enough
- You need to be tall enough to climb one step at a time, and being able to take two or three matters much less.
- So further model gains should have a much smaller productivity impact than before.
Strong where acceptance criteria are verifiable
- LLMs are useful for code that meets easily and objectively verifiable criteria you state explicitly.
- They still can't predict well whether code is maintainable or docs contain the right information.
A working implementation went from 80% to 20% done
- A working implementation used to mean the task was about 80% done.
- Now it's more like 20%, and the author keeps underestimating iteration time.

Community Reactions

Coding is only part of the job
- A commenter cited a split of 25% planning, 25% coding, 25% testing, 25% review/rework.
- A 2x coding speedup is then a small gain overall.
Review takes longer than writing
- One commenter said Claude does the work in 1/10 to 1/4 the time, but proper review takes 2-3x as long as writing it by hand.
- They say this pushes people toward committing and hoping.
Multiplier depends on expertise
- A commenter split it into 0.5-1x when learning, 2-3x with working knowledge, and 10x+ when mastered.
- A non-programmer reported 100x from automating scripts they never would have written.
Agreement and pushback on no-comments
- One commenter reached the same conclusion after Claude kept adding wordy comments.
- Another argued comments help the model too since it reads files in small chunks.

How to Apply

Add a no-docs rule to project instructions
- Today, add "Never write READMEs, docstrings, or comments" to CLAUDE.md or your system prompt.
- Run the same task before and after to compare how many needless comments disappear.
Attach runnable acceptance criteria to requests
- In each request, state "build it, run it, and verify X works".
- Include the test command or click scenario so the LLM can iterate on its own.
Schedule human time for structure review
- After getting an LLM draft, block time for restructuring it.
- Estimate as if a working implementation means 20% done, not 80%.
Run agents in a sandbox
- Use an isolated environment so you don't approve permissions constantly.

Try It

copy & run

# Prompt to paste into Claude Code or ChatGPT (the article's method as a prompt)

Follow these rules for this task.
- Never write READMEs, docstrings, or comments. I will write those myself later.
- After implementing, run it yourself and check the acceptance criteria below; if they fail, fix and verify again.

Task: {{feature to build}}
Acceptance criteria (verifiable): {{e.g. clicking the button shows X, npm test passes}}

Next to try: when done, list 3 spots in the code structure with duplication or maintainability concerns.

Terminology

Feedback loopA cycle of writing code, running it, seeing results, and fixing. Automated tests act as the grader.

Acceptance criteriaA predefined "done when this works" standard. The more objectively checkable, the better LLMs hit it.

Vibe codingUsing generated code without reading or understanding it. The author has only tried it on non-work projects.

SandboxAn isolated environment where an agent can't do real damage. It removes constant permission prompts.