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

What they are saying is there are domains where there's no such thing as an expert who has the unconsious competence to immediately notice the LLM made glaring mistakes.

Totally depends. The real question is what's your average productivity increase?

I had a task to completely gut out a codebase to share with a vendor. I gave them my estimate - 2 weeks. Asked Claude to do it, and was done in an hour. Reviewed the changes, and it was perfect. This is an outlier of course, and it was a pretty basic codebase. But it's real world stuff.

Overall though, if I had the mental fortitude to work for 8 hours straight, I could easily average 5x my "normal" performance. But most days I can't perform at that level. Also I admit I am not a fast developer, I do a lot of testing and verifying as I'm paranoid.

I recently, with the help of Claude Code, made a tool which involved a database, two separate apps surfacing and interacting with various aspects of the data, and a user base of dozens, with some semi-specific domain knowledge on my part and an intention of re-using and building upon the minimum viable result.

OP's description very much mirrors my experience. I was able to do many things much more quickly with the help of the LLM, but there is no substitute for actual users interacting with the tool, saying, "I like this," or "no, this is wrong or needs work," or even, "here's something none of us thought of before, but now this tool makes me think XYZ would help us and might be achievable." That whole interaction takes real time and I don't know how you replace it with coding agents.

Secondly, on the matter of code structure, just on a qualitative level, I can see that claude will do things very efficiently on the way to a goal I give it, but it can't read my mind and know that I may want to repeat a specific pattern across two client apps. Or that its shortest-distance solution makes extensibility or broad applicability difficult. That I might want to share code and structure things in a certain way. Not without me saying so or, in many cases after it has built something workable, duplicating refactors I make with an eye for reusability or maintenance. Making those changes in time is important if you don't want to burn tokens later as the LLM tries to unravel its own spaghetti. And again, whether I am coding those intentions directly, or writing out detailed instructions in english, all of that takes time.

> It's littered with hundreds of lines of comments and notes, often referring to other notes in other parts of the codebase, and often extremely out-of-date.

Adjustable by tooling and prompts - my favorite is a ban on comments >2 lines, a tagged index system for effectively in-repo RAG with short documents on each tagged topic like INFRA-DATABASE-SETUP.md - enforce with tooling that the tag matches the doc and vice versa. Enforce that any PR that has a tag change in it has the relevant doc changes.

> Claude seems to me to still focus on getting things done vs. doing it properly, so from my experience it would pretty often mess up your whole codebase just to be able to finish its task, vs. stopping and rethinking the approach.

Tell it your values - "I value correctness over getting things done, and getting things done properly over speed" solves many of those problems. I've actually spent a portion of today rejiggering my values documents because the models have improved enough I no longer need to be quite so careful about scoping.

I was having those same problems, but particularly using Fable / Sol to do the meta-work has largely eliminated them over the last ~3-4 months. Codebase is now a lean mean token-conserving machine.

Skimmed, it's using the word llm a lot, no instances of the word Agent, codex, claude. The person writing this isn't using LLMs correctly.