2x, Not 10x: What Coding With LLMs Actually Delivers in 2026

An essay titled "2x, not 10x: coding with LLMs in 2026" made a deliberately unglamorous claim in a year full of 10x and 100x productivity talk — and it pulled 228 points and 180 comments on Hacker News, one of the sharpest AI-coding-productivity threads of the summer.

The core argument: LLMs got reliable enough to run in automated feedback loops — that threshold crossing is what unlocked real usefulness — but the author estimates the resulting boost at roughly 2x, not the 10x figures circulating elsewhere. And crucially: further model improvements are unlikely to multiply that much further, because the remaining hard problems aren't the kind an LLM can verify against.

TL;DR — the argument and the pushback

The staircase hypothesis

The essay's central model, in the author's own words:

"To walk up a set of stairs you need to be tall enough to get up at least one step at a time, but being so tall you can take two or three steps at once matters a lot less."

Applied to coding agents: LLMs became genuinely useful once they got reliable enough to iterate toward an explicit, verifiable goal — "make a button that does X, then click it and confirm it does X" — without thrashing. That's the step that mattered. Once cleared, further raw capability increases (a smarter model, a bigger context window) help less than the framing "more capable model = proportionally more productive" would suggest.

The corollary is the part that generated the most disagreement: the author argues LLMs are useful specifically for "producing code that meets easily and objectively verifiable acceptance criteria you provide explicitly" — and two categories of question resist that framing entirely:

• "Is there a more maintainable way to structure this code?"
• "Does this documentation include the right information and omit extraneous information?"

Neither has an objective pass/fail an LLM can check itself against the way "does clicking the button do X" does.

"Never write READMEs, docstrings, or comments"

The essay's most-quoted line, and the one that split the thread hardest:

"Never write READMEs, docstrings, or comments. I will write those myself later. And yes, I really mean this."

This landed because dozens of commenters had independently arrived at the same instruction. deergomoo described trying "no amount of examples or explanation" before realizing the deeper issue: an LLM has no concept of meaning to select what's worth commenting on — it can only pattern-match toward "comment-shaped text," which produces paragraph-length restatements of the next few lines rather than genuine explanation.

openasocket put the failure mode precisely: "Each sentence makes sense, but the overall thing does not" — technically fluent, structurally incoherent. kaffekaka called it "like a weird person" — competent locally, off globally. That's the documentation-specific version of the essay's broader claim: fluent local output, unreliable global judgment.

Not everyone agreed the fix is "never write comments" — troupo noted recent models write almost none by default and that comments still help the model itself re-orient across large files, so the better fix may be explicit per-repo comment conventions in CLAUDE.md rather than a blanket ban. That's consistent with explainx.ai's coverage of the ASD-STE100 SimpleEnglish skill, which tackles the same verbosity problem from the opposite direction — constraining how the model writes, rather than banning writing outright.

The review-time tax

The sharpest structural critique came from Xcelerate, describing a trade that shows up across the thread in different words:

"I can code something entirely by myself at my baseline speed... Or I can use Claude to do it, and it does it in 1/10 to 1/4 of the time. The problem, however, is that to review Claude's code properly takes 2-3x the amount of time it would have taken me to write it all by hand."

The resulting choice, per Xcelerate: "YOLO, LGTM" and hope you can revert if it breaks, or write the code by hand from the start. serial_dev named the actual industry behavior directly: "The 10x speed up comes from the fact that we have all given up on properly reviewing each other's code." altern8 went further — describing colleagues shipping features whose core function visibly doesn't work, dismissed as "just a bug," in a way that "one year ago... would be unheard of."

This is the counterweight to every raw-generation-speed claim in the thread: if review time isn't accounted for, the multiplier is fiction. Several commenters (jaggederest, elcritch) reported that explicit values statements in their system prompts — "I value correctness over getting things done" — measurably reduced this problem over 3-4 months of iteration, suggesting the review tax shrinks with better prompting discipline, not just better models.

Where the real multiplier lives: work that wouldn't have happened

The strongest counter to "2x" wasn't a bigger number — it was a different comparison. pantelisk framed it cleanly: "The real power of these tools is that there are so many ideas people would like to try, but never have the time or motivation to pursue." The honest comparison isn't "built with AI vs. built without AI" — it's "built at all vs. never attempted."

rayiner described vibe-coding a native Mac PDF viewer with specific search features no existing app had, in an hour, without reading a line of generated Swift — a tool they wouldn't have built otherwise because learning AppKit for a personal itch wasn't worth a week off their actual job. arjie and 5555watch (an academic reproducing methods papers with no available code) both explicitly rated this class of work as "0x to infinity-x" rather than a fixed multiplier, since dividing by "time it would have taken otherwise" breaks down when the honest denominator is zero.

moron4hire pushed back hard on treating this as unambiguously good: solo-dev projects that never get organizational buy-in tend to go nowhere regardless of how cheap they were to build, echoing the long-standing pattern of abandoned open-source side projects — AI lowers the cost of creation, not necessarily the cost of the promotion and maintenance that makes something matter.

Amdahl's Law: why 2x might be the ceiling regardless of model quality

whateveracct raised the sharpest structural objection, invoking Amdahl's Law — total speedup is capped by the fraction of the job you're actually accelerating. gashad supplied the breakdown from a conference talk: software work splits roughly

• 25% planning & aligning with other teams
• 25% coding
• 25% testing/verifying
• 25% code review/rework

ChadNauseam ran the math literally: even a 10x speedup on coding alone, applied to that split, caps total throughput far below 2x once the other three quarters stay fixed. Commenters who reported genuinely large gains (metalspot, SwellJoe) did so precisely because they'd restructured all four categories around AI — automated testing loops, AI-assisted planning, AI-assisted review — not just the coding slice. That's the practical version of the essay's own conclusion: further gains come from retooling the process, not a smarter model doing the same 25% faster.

The "it depends" consensus underneath the noise

Once you sort the thread by what people were actually building, the disagreement mostly dissolves:

lazopm's three-tier framing (learning-stage 0.5x-1x, working-knowledge 2x-3x, mastered 10x+) is close to the median position once you strip out the extremes on both sides — and it matches the essay's own staircase logic: the multiplier isn't fixed, it's a function of how cheaply you personally can verify the output, which is exactly the "objectively verifiable acceptance criteria" bar the author opened with.

What this means for your own AI-coding workflow

1. Stop asking "what's the multiplier" and start asking "what can I verify cheaply." That's the actual predictor of your real-world speedup, per both the essay and the thread's mastered-domain commenters.
2. Budget real review time, not zero. Xcelerate and serial_dev's "commit and hope" pattern is a silent productivity tax that doesn't show up in generation-speed benchmarks.
3. Retool the other 75% of the job, not just coding. Per Amdahl's Law commentary, teams seeing 5x+ gains restructured planning, testing, and review around agents too — see explainx.ai's loop engineering guide for how that looks in practice with Claude Code.
4. Count the work that wouldn't have happened otherwise. If you're only measuring "faster at what I already do," you're missing the category several commenters called the actual killer feature.
5. Set explicit values in your system prompt — jaggederest and elcritch both reported that stating "correctness over speed" explicitly, then iterating the instruction over months, closed much of the review-tax gap. This is the same instinct behind the ASD-STE100 SimpleEnglish skill for docs — specific, testable rules beat vague vibes-based prompting.

Summary

"2x, not 10x: coding with LLMs in 2026" argues frontier models crossed a real usefulness threshold — reliable enough for automated feedback loops on verifiable tasks — but further model gains deliver diminishing returns because the hardest remaining questions (maintainability, good documentation) aren't objectively checkable the way "does the button work" is. The 228-point Hacker News debate it triggered ranges from 0.25x (review overhead eats the gain) to infinity-x (work that would never have happened without AI at all) — and the disagreement mostly resolves once you separate task type, domain mastery, and whether review time is actually being counted. The practical convergence: the real 2026 productivity story is workflow and verification discipline, not raw model capability.

Related on explainx.ai

• GitHub stacked pull requests — public preview explained
• Airgapped QR file transfer — fountain codes, and the prior-art pile-on
• Loop engineering — coding agents with Claude Code
• ASD-STE100 SimpleEnglish agent skill — fixing AI writing slop
• Claude Code — model vs. effort: knowing more vs. trying harder
• Top 10 open and closed-source agent harnesses (2026)
• Agentic fatigue — the vibe-coding productivity paradox
• "Programming is low-intelligence work" — kache's X debate explained
• The AI Aesthetic — why AI apps look the same

Source: "2x, not 10x: coding with LLMs in 2026" · Hacker News discussion

Quotes and figures reflect the essay and its Hacker News discussion as of July 31, 2026. Individual productivity multipliers are self-reported and vary widely by task, codebase, and reviewer discipline — treat any single figure as anecdotal.