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

Something I've learned about myself over the past 6 months is that if I ever discover Harry Potter is nonfiction and magic is real, my reaction will be approximately "OK that's interesting, but is this magic stuff good for anything more complex than writing unit tests?"

LLMs have certainly passed that threshold of usefulness, though as of July 2026 and based solely on my own direct observations, they still have fundamental limitations such that I have not yet taken up woodworking as a contingency plan for "Software Engineer" becoming an extinct profession. Based on my mental model of why LLMs have become useful, I'm not sure that will change any time soon. Here's my hypothesis:

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.

An analogy is that 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.

LLMs are useful for coding because you can tell them "make a button that does X, then click the button and make sure it does X." They're able to iterate toward that goal in meaningfully sized steps instead of thrashing, and they're able to reliably predict when a human would say "yes the button now does X" or "no the button does not yet do X." As such, LLMs are useful for producing code that meets easily and objectively verifiable acceptance criteria which you provide explicitly.

And that is incredible. Stupendous. Life-changing. Maybe even a 2x improvement. However, there are still important questions in this line of work for which the answers cannot yet be predicted by an LLM with sufficient accuracy to be, in my opinion, useful. Such as:

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

As such, I use LLMs mainly to produce a rough draft of the code which I then iterate on heavily, at least until I like the general structure. I've been a little sloppy when it comes to readability of individual lines/functions. (I have to include this hedge in case my coworkers read this post). And even with the line-level sloppiness, I still consistently underestimate how long that iteration is going to take. A working implementation used to mean a task was 80% dtheone; now it's more like 20%.

As for documentation, I've found this simple instruction to vastly improve LLMs' output:

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

A potentially reasonable reaction to these limitations would be to say "LLMs have improved a huge amount over the past year and thus future improvements over the next year will likely make them much better at writing good documentation and maintainable code." But if you accept my staircase hypothesis, that reaction is a lot less certain. Being able to climb up a tall staircase doesn't mean you can swim.

So my current guess is that further model improvements alone are unlikely to get us to a 10x productivity boost over the dark ages of 2025. Instead I think most of the productivity gains in the foreseeable future will come from the industry retooling around the model capabilities we already have today.

I'm not an early adopter in this space. So far I've gone from using LLMs as a glorified search engine/Stack Overflow replacement (RIP), to having them code via interactive chat, to writing declarative specifications of the end state I want. Sandboxed environments have also been an MVP so that I don't have to grant the LLM permission to do something every 30 seconds. There's lots of work to be done in refining the workflows and tooling around this stuff.

I've also done some vibe coding (which I'm defining as "generating code without reading/understanding it all") for non-work / non-production things. I'm interested to explore that area more outside of work, and of course plenty of other people have been enthusiastically forging ahead. It's hard to know how viable that approach can be in the long term since there hasn't been a long term yet. But you know, maybe there's something there; maybe certain test practices/tooling and such will make it safe to rely on black-box LLM code even for operating critical infrastructure. Maybe we can get to a 10x improvement by routing around LLMs' fundamental weaknesses.

But in the mean time, I'll stick with my hand-crafted READMEs.