2x, not 10x: coding with LLMs in 2026
The one and onlyOpinions on any topicWhat are you doing here?How much wood should a woodchuck chuck?You look like you need some sunClojure is an esoteric language that attracts esoteric peopleThose are my cousins the guinea pigs!The turtleneck is the most flattering thing a man can wear.Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.Calvin Klein's no friend of mineIt's quinoa time!(got? :lisp)Breaking changes are for the weakThe hardest problem in computer science is avoiding stale jokes.
The one and onlyOpinions on any topicWhat are you doing here?How much wood should a woodchuck chuck?You look like you need some sunClojure is an esoteric language that attracts esoteric peopleThose are my cousins the guinea pigs!The turtleneck is the most flattering thing a man can wear.Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.Calvin Klein's no friend of mineIt's quinoa time!(got? :lisp)Breaking changes are for the weakThe hardest problem in computer science is avoiding stale jokes.
2x, not 10x: coding with LLMs in 2026<br>Something I've learned about myself over the past 6 months is that if I ever<br>discover Harry Potter is nonfiction and magic is real, my reaction will be<br>approximately "OK that's interesting, but is this magic stuff good for anything<br>more complex than writing unit tests?"
LLMs have certainly passed that threshold of usefulness, though as of July 2026<br>and based solely on my own direct observations, they still have fundamental<br>limitations such that I have not yet taken up woodworking as a contingency plan<br>for "Software Engineer" becoming an extinct profession. Based on my mental model<br>of why LLMs have become useful, I'm not sure that will change any time soon.<br>Here's my hypothesis:
LLMs' increased rate of adoption in 2026 is largely due to them becoming<br>reliable enough to run effectively in automated feedback loops. Now that they've<br>passed that threshold, further improvements in model performance will have a<br>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<br>up at least one step at a time, but being so tall you can take two or three<br>steps at once matters a lot less.
LLMs are useful for coding because you can tell them "make a button that does X,<br>then click the button and make sure it does X." They're able to iterate toward<br>that goal in meaningfully sized steps instead of thrashing, and they're able to<br>reliably predict when a human would say "yes the button now does X" or "no the<br>button does not yet do X." As such, LLMs are useful for producing code that<br>meets easily and objectively verifiable acceptance criteria which you provide<br>explicitly.
And that is incredible. Stupendous. Life-changing. Maybe even a 2x improvement.<br>However, there are still important questions in this line of work for which the<br>answers cannot yet be predicted by an LLM with sufficient accuracy to be, in my<br>opinion, useful. Such as:
"Is there a more maintainable way to structure this code?"
"Does this documentation include the right information and omit extraneous<br>information?"
As such, I use LLMs mainly to produce a rough draft of the code which I then<br>iterate on heavily, at least until I like the general structure. I've been a<br>little sloppy when it comes to readability of individual lines/functions. (I<br>have to include this hedge in case my coworkers read this post). And even with<br>the line-level sloppiness, I still consistently underestimate how long that<br>iteration is going to take. A working implementation used to mean a task was 80%<br>dtheone; now it's more like 20%.
As for documentation, I've found this simple instruction to vastly improve LLMs'<br>output:
Never write READMEs, docstrings, or comments. I will write those myself<br>later. And yes, I really mean this.
A potentially reasonable reaction to these limitations would be to say "LLMs<br>have improved a huge amount over the past year and thus future improvements over<br>the next year will likely make them much better at writing good documentation<br>and maintainable code." But if you accept my staircase hypothesis, that reaction<br>is a lot less certain. Being able to climb up a tall staircase doesn't mean you<br>can swim.
So my current guess is that further model improvements alone are unlikely to get<br>us to a 10x productivity boost over the dark ages of 2025. Instead I think most<br>of the productivity gains in the foreseeable future will come from the industry<br>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<br>glorified search engine/Stack Overflow replacement (RIP), to having them code<br>via interactive chat, to writing declarative specifications of the end state I<br>want. Sandboxed environments have also been an MVP so that I don't have to grant<br>the LLM permission to do something every 30 seconds. There's lots of work to be<br>done in...