A Solo Dev's HN-Topping Post Says LLM Coding Gains Are 2x, Not 10x. His Staircase Theory Explains Why the Next Model Upgrade Won't Change That.
On July 25, Jacob O'Bryant published a short post called "2x, not 10x: coding with LLMs in 2026." Within days it was #1 on Hacker News. The claim that got it there isn't "AI coding is overhyped" and it isn't "AI coding is transformative": it's a specific, falsifiable hypothesis about why LLMs became useful for coding, and that hypothesis has an uncomfortable implication: the next model upgrade probably won't matter as much as you think it will.
I've spent the past week testing his framing against my own workflow, and I think it's the most useful mental model I've read all year for deciding where to spend effort in the next 12 months.
The staircase hypothesis
O'Bryant's core argument is this: "LLMs' increased rate of adoption in 2026 is largely due to them becoming reliable enough to run effectively in automated feedback loops. Now that they've passed that threshold, further improvements in model performance will have a much smaller impact on productivity than they have had previously."
His analogy is a staircase. To climb it, you need to be tall enough to get up at least one step at a time. Being tall enough to skip two or three steps at once is a nice bonus, but it doesn't change whether you can climb the stairs at all. You already could. The hard, threshold-crossing part was becoming tall enough for one step.
For coding, that threshold is being able to iterate against a check a human can verify. As O'Bryant puts it, LLMs are useful because you can tell them "make a button that does X, then click the button and make sure it does X." They can iterate toward that goal in reasonably sized steps instead of thrashing, and (this is the part that actually matters) they can reliably predict when a human would say "yes, the button does X" versus "no, it doesn't." That's the step they climbed. Everything since has been refinement of a capability that already existed, not a new capability.
I find this persuasive because it matches what building with Claude Code has actually felt like this year. The jump from "unusable for real work" to "I can hand off a scoped task" happened once, roughly a year and a half ago. Since then, model upgrades have made things smoother, faster, a bit more reliable. But I haven't felt another threshold crossing. That's exactly what the staircase theory predicts.
Where the theory says LLMs still fail
The flip side of "useful for objectively verifiable acceptance criteria" is that LLMs are still bad at judgment calls without an objective pass/fail. O'Bryant names two directly: "Is there a more maintainable way to structure this code?" and "Does this documentation include the right information and omit extraneous information?"
Neither of those has a checkable answer. You can't write a test for "more maintainable." You can't script a pass/fail for "the docs cover the right things." Those require the kind of taste and context-holding that comes from actually understanding a codebase's future, not just its present state, and that's precisely the category of judgment the staircase model says won't improve just because the underlying model gets smarter. As O'Bryant puts it: "Being able to climb up a tall staircase doesn't mean you can swim." Structural judgment and documentation quality are a different skill, not a taller version of the same skill.
This tracks with my own experience shipping features on Solo Operator Stack. The LLM will happily produce a working component. Whether that component's file structure will make sense to me in six months is a question I still have to answer myself, every time.
The workflow tax nobody budgets for
Here's the part of O'Bryant's post I think is most underrated: the accounting problem. He writes that he uses LLMs mainly to produce a rough draft of the code, which he then iterates on heavily, "at least until I like the general structure." And even accepting some line-level sloppiness, he says he still consistently underestimates how long that iteration takes.
His number: "A working implementation used to mean a task was 80% done; now it's more like 20%."
That's a real reversal of intuition, and it's the single most practical thing in the post. When a human writes the first draft of a feature by hand, getting something working genuinely is most of the effort: the remaining 20% is mostly polish. When an LLM writes the first draft, "it runs" tells you almost nothing about how close you are to done, because the LLM cleared the low bar (does the button do X) without clearing the high bar (is this the right shape of code to live in your codebase for the next two years). The gap between those two bars is where all your remaining time goes, and it's easy to forget that gap exists when you're staring at a green checkmark.
If you're a solo operator estimating how long a feature will take because "the AI wrote it in ten minutes," O'Bryant's ratio is the correction factor you're probably missing.
The technique worth stealing
O'Bryant's one concrete tactical recommendation is worth quoting in full, because it's the kind of thing you can adopt today with zero setup cost: "Never write READMEs, docstrings, or comments. I will write those myself later. And yes, I really mean this."
The logic follows directly from the judgment-call problem above. Documentation quality is exactly the kind of "does this include the right information and omit extraneous information" call that LLMs can't reliably make. Left to their own devices, they tend to produce comments that restate the code line by line, or docstrings padded with boilerplate that adds noise without adding understanding. Telling the model to skip that step entirely, and doing it yourself once you actually understand what you built, produces a better result than letting the LLM guess at what future-you will need to know.
I've started doing this in my own repo and the difference is real. The comments I write after I've iterated on a piece of code are shorter and more useful than anything the model generated on the first pass, because I'm writing from the vantage point of having actually finished the thing.
What I'd actually do
Budget your next 12 months assuming the model in your terminal today is close to the model you'll be using a year from now, in terms of what it changes about your workflow. Don't wait for the next release to solve your structural judgment problems. It won't, according to O'Bryant's framing, because that's a different capability than the one that's been improving. Instead, spend your effort on the parts of the loop that are still manual and expensive: reviewing structure, writing your own docs and comments after the fact, and building tighter feedback loops (sandboxed environments, better test harnesses, faster iteration cycles) so the "make X do Y, then verify" loop runs faster. O'Bryant's own adoption path (search engine replacement, to interactive chat, to declarative specs, to sandboxed agents) is itself evidence that the tooling layer, not the model layer, is where his own productivity gains have kept coming from.
The honest counter-take: O'Bryant is explicit that this is his hypothesis based on his own direct observations as of July 2026, not a controlled study, and he says so himself. It's also possible that "maintainability judgment" and "documentation judgment" turn out to be closer to the coding-loop threshold than he thinks: a model that gets meaningfully better at holding a large, evolving codebase in context could start making decent structural calls, not because it got smarter at abstract reasoning but because the codebase itself became more checkable (better types, better tests, better lint rules acting as proxies for "maintainable"). If that happens, the staircase gets a new step nobody budgeted for. I wouldn't plan my year around that possibility, but I wouldn't bet the whole thesis is permanent either. Plan for 2x. Be pleasantly surprised if it's more.
Author
Lukas
@lukcombinator