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

The way I see it you should calibrate the way you work with LLMs based on how confident you are on that specific area, and if it's your responsibility to own/understand it. Here's how it feels for me:

* Learning stage: 0.5x - 1x. I change my system prompt to teacher mode, taking the productivity hit for actually learning the system/tool pays off dividends later. I change my system prompt to "teacher mode" and slowly loosen it as I get more confident.

* Working-knowledge: 2x - 3x. Once I am ramped up enough I feel like I can get a decent productivity boost. Most of the time is spent at the planning stage. This is my mode for areas I don't really own or care about, just need to get work done.

* Mastered: 10x+ I have been doing web front end for 12+ years, I can quickly review plan/implementations and for my initial prompt I already know most of what I want built.

1x == my speed before AI

This reminds me of themes I recently saw in [Harness Engineering is not Enough: Why Software Factories Fail](https://www.youtube.com/watch?v=Ib5GBkD555M) (Warning: the last 3 slides seem like an advertisement). One thing I liked is how Dex has a little graphic he glossed over showing software development is

- 25% planning & aligning with other teams

- 25% coding

- 25% testing/verifying

- 25% code review/rework

One argument was that agentic coding speeds up that coding part a bunch. So maybe there's 2x speedup in coding. But that's only a small speedup in the totality of everything software engineers do.

Does the number × depend on how big your thinking is? If you are only 2× then you need to think bigger, aim higher, etc. I think the limit on the 2× is not the ai?

200x coding with LLM

I mean the "x amount" is relative to your existing skill level, right?

It's worth asking ourselves "why does the x amount matter?" I get the desire to define KPIs to estimate productivity gains. But this all seems to be—rather rapidly—leading to an increasingly dehumanized reality (both figuratively and literally) so we can...produce more software? I love building software, and I enjoy using LLMs to help me do it, but there's just this weird vibe I can't quite shake about how we're trying to quantify all of this.

0.25x because I scope bigger now and then I may get a few "free" React components but largely doing all that work of putting it together.

Wouldn't trade it though. Feel like I can overall do more with less time and energy.

At the end of the day, AI is making me work more (good thing). If you count that as productivity, then sure.

You still have to know what you’re doing. That came from years of doing it by hand. Where is that necessary experience going to come from for the current and future generations of juniors?

> 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.

This is quite validating as I came to the exact same conclusion myself. We’re required to use an LLM for every task at work that touches code†, and I was really struggling to get Claude to stop with the long waffly comments that reiterate the next few lines of code in 3x as many characters, making contextless references to subtasks in whatever harness du jour we’re using this week.

No amount of examples or explanation of what I wanted would make it stop. And then I realised of course, I’m asking something which has no concept of meaning (or, indeed, anything) to only add meaningful comments. More fool me I guess.

Of course, it’s ultimately pointless given all of my colleagues are regularly opening PRs with more comments than code anyway. 80% of my code review responses these days are just increasingly exasperated “pointless comment, please remove”.

† This is just as infantilising as it sounds, by the way

> Never write READMEs, docstrings, or comments.

I found that latest codes don't write comments in code by default. And when they do, they write stupid shit like "This was code that did X, it was now removed".

You have to explcitly prompt them to write comments in code. They are still useful for you, the user. But are arguably useful for the model, too, given how many of them (especially Claude) only reads small chunks of files. So I'd rather have code comments than it reproducing a picture from incomplete data.

>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

Tell me you just started with agentic programming without telling me you just started using agentic programming.

Look, don't get me wrong: new folks learning tech should absolutely write articles about it! But their claims might very well change once they learn more .. and I strongly suspect that will be the case here.

This is a dated take to me. I think the next stage in unlocking productivity is so called "loop engineering"; figuring out how to effectively not read all the code while ensuring quality. To me that means implementing statistical quality control and formal methods.

Before I get there I have to figure out how to reliably audit plan adherence. The problem is that when the specs are in natural language, as they are, you need a fallible LLM to verify it.

> 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.

Weird… I would have said this was how it was about 2 years ago, but no way in 2026.

... the official return of pair programming! The best part: LLM's save you from having to argue with a human. Added bonus: now you get to master two tools instead of one.

My observation is that AI tools generally make people /less/ productive. They are more productive in that they produce more stuff, but they are less productive in that the stuff they are producing has lower inherent value delivery. The primary place where I see this in software teams as a Product person is in document creation. If you are using an AI tool to produce internal documents, this is likely a net-negative value activity that actually reduces the overall productivity of the team. Why? Because writing is thinking. By handing off document creation to an LLM for a document that's supposed to communicate important details between teams (e.g. technical design docs, requirements docs, strategy docs) you are actually handing off thinking, or rather handing off not-thinking as AI tools cannot "think". The outcome of is poorly "thought out" slop that generates more work for everyone involved to resolve /or/ everyone simply ignores the document and the previous processes stop being useful.

If anything, I'd say AI tools in /most/ enterprises as people are trying to use them now are at least a -30% of productivity. If used correctly for taking a human-written/thought requirements doc, converting it into an interactive prototype that can be critiqued and ultimately included as part of the solution alignment within the requirements doc, and then is handed to an engineering team that is effective at using humans and AI to produce code, then it's probably a benefit. But most businesses lack the internal rigor, quality culture, and data governance to support properly applying AI tools in a high context manner internal to their business.

Even this is overstating it IMO.

I already convert from multipliers to percentage of increase, so when someone claims 10x they very likely mean +100% productivity, and here 2x means +20% productivity, which seems about right. Nobody that was normally productive before LLMs has suddenly 10x'ed their output now.

The problem is that 20% productivity when it comes to generating code, really doesn't translate in 20% productivity increase overall, when you take into account the fact that the code quality is worse, the fact that writing code is actually not the majority of your time spent, and that people get burnt out from the usage.

[dead]

[dead]

Does a 60x speedup count? Are you still copying and pasting from chatgpt, because if so your definitely doing it wrong.