* 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
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.
Weird… I would have said this was how it was about 2 years ago, but no way in 2026.
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.
> 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
- 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.
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.
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.
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.
This really needs to be calibrated to the type of work and complexity.
I can actually believe that LLMs would speed up basic web dev work in small, simple codebases 10X for simple requests.
These conversations usually turn into people talking past each other because they’re working on different things. For other less routine and more complex work, expecting a 10X productivity boost is not realistic at all. It doesn’t matter how good you get at writing prompts and reviewing plans. LLMs just don’t solve everything for you in a good way. Some times the true nature of the problem is revealed while implementing it and by deferring everything to an LLM you spend days throwing tokens at the wrong thing. There is a lot of work where the LLM speed up comes from helping you quickly search docs and codebases and double check your code, but handing the entire thing off to an LLM isn’t reasonable. These tasks aren’t going to reach this mythical 10X productivity boost that is genuinely achievable for much simpler work.
I have tried to shut it down, it immediately nullifies the docs and make it genuine slop.
I truly believe that documentation should be human written and human readable. It's all of the stuff that AI does NOT pick up on. Small inconsistencies, only the necessary details. IE: Don't just rewrite the code that we have into readable english (We are software developers after all. We can read code.) - comments / documentation to me has always been the "in between the lines" stuff that can't be put into the code.
Why not just write the code in the prompt so LLM can paste it.
[0] https://github.com/chrisvariety/branch-fiction/blob/deb37f2b...
Amdahl's Law should be familiar to anyone with a 4y computer science/engineering degree. Why aren't they applying it to their own throughput?
You could argue that it speeds up development by 5X or more, but then it slows down testing/verifying, code review, and in many cases it makes it impossible to review/rework by hand.
I just do what I'm told at work but even though I'm sure I'm in the minority I'm extremely skeptical that LLMs can produce any good-quality code.
Looks to me like we've just lowered the bar--by a lot--and stopped looking at the code that goes out. Every time I look into how Claude implemented something it's completely insane, with no way to refactor it or maintain it in the future.
Take that, you mere 10x-ers! Your days are toast!
Recent LLMs struggle with the author's stated issues only inline: they're entirely capable of going back and evaluating codebases to find architectural issues and LLM slop signatures, especially when you use other models to check one model's output. This wasn't true until Fable-class models, but it's true now.
Like always. This is why the average carpenter you hire in 2026 still won’t do a perfect job, despite carpentry having existed for thousands of years.
- 25% planning & aligning with other teams
- 25% coding
- 25% testing/verifying
- 25% code review/rework
I'd say that thanks to LLM assistance I'm 10x faster at coding, code review/rework, and testing/verifying. (LLMs can partially automate testing/verifying too, and the code is higher quality now as well so less testing/verifying is necessary).
So that leaves us with:
- 92.5% planning & aligning with other teams
- 2.5% coding
- 2.5% testing/verifying
- 2.5% code review/rework
Obviously, that makes zero sense as a split. If you saw any organization doing that, you'd suggest having fewer teams, more silos, etc. Maybe you have designers produce code, instead of showing the designs to coders and having the coders implement it. Maybe you force all your engineers to dogfood the product that way they can identify issues themselves rather than needing QA teams to do it. And so on. so the last category, "planning & aligning with other teams", falls too.
1) because they’re not doing those others spheres of work
2) because they don’t think about the work
nor how tired they are afterwards
3) they’re proselytizing AI work as the future and
that conflicts with that vision
4) the other shoe hasn’t dropped
5) they really don’t see it
6) some people genuinely hate programming and this
helps them skip that.
Agents left alone tend to create so much tech debt, that once the program becomes so messy that they can't fix one bug without creating two new bugs, it's too late to even clean that up.
The program will be super tidy in superficial aspects that linters catch (everything neatly formatted and verbosely commented), and roughly appear to do what it's supposed to do, but everything in between will be "I can't even".
We need something else than formal methods, because the problem is usually in lack of simplicity - you get four versions of the problem solved in four times in four in different ways, each uniquely flawed and just incompatible enough with the others that unifying them is too big and hairy for the agent, and will result in eight different glue adapters written in the process.
Suddenly devs who were cranking out features with no interest in infrastructure are attacking giant refactors to make the code more understandable to the LLM.
Other devs are using LLMs to build themselves quality of life SDLC tools completely separate from the core code base.
Plenty of other examples of this.
The 10x speed up comes from the fact that we have all given up on properly reviewing each others code and we just say “meh, it will be fine, lgtm”
10x or 60x of a negative value is a 10-60x bigger problem than that initial negative value. We all regularly commit things that are actually net negative.
Finally, 10x or 60x more productivity channeled into yet another static site generator, CMS, or programming language doesn't really help in improving products or developing new interesting features.
In short: LLMs offer real productivity gains, but they are still tools, and they are very new, so we misuse them a lot, in various ways (not limited to examples above). Unless they replace programmers and can consistently produce better than average code (even if they fail catastrophically in a few cases), they won't fundamentally change programming. They did change a lot, but not enough to get the result you're describing.
If you look at the code the LLM spat out (and you really, really should!) you will immediately notice that its shape is not what you thought it should be. You might not notice immediately if you're learning, but if you really "mastered" the domain, you will "just" see it. You will also recognize the problem with your assumptions, and immediately (or after some research) correct the prompt.
Looking at the diffs for everything the LLM does slows you down, of course. Not looking - or looking and not recognizing problems, for one reason or another - can be initially faster, but a single pathological case can eat both the time saving and tokens. For domains you truly "mastered", the current models can generate code as if they read your mind (because you can be that precise in the prompt, and quickly), so it's really glaring and very hard to miss when they somehow misread your mind.
It only works at the "mastered" / "unconscious competence" stages, and only in those narrow domains you truly mastered, but it does seem to work. Is it 10x? No idea, but there is a marked change in the speed boost when crossing from conscious to unconscious competence area, with everything else (harness, model) staying the same.
And I've also seen the other side, where vibe coding on projects that had bad code quality to start with leads to bug riddled messes. Projects with beautiful and elaborate test harnesses, that break seconds after contact with a real human user
Of course, the main issue is that they’re completely undebbugable now. My bash scripts used to be a sequential list of commands, now they’re 500 lines of variable laden functions.
Is my life any better? Dunno. But it’s satisfying (until there’s a bug)
But LLMs seem to have a hard time getting the big picture and reusing code that is already implemented and ALMOST does what you want vs. rewriting everything from scratch.
AI code is extremely difficult to read and follow. 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.
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.
After a few passes of that, with duplicate code with no underlying coherent vision, hundred of thousands of lines of documentation written as walls of text in markdown and weird coding decisions, your codebase is impossible to work out for a human.
I use Claude Opus 5 at high to plan, Claude Opus 5 at low to execute the plan.
I make it build things in small changes, I give very specific instructions about the architecture, and I make sure to point out existing functionality that can be used instead of writing something from scratch. But it's a lost battle because Claude can't learn and it's basically a black box.
It pretty shitty, but that's what they pay me for so I just do it.
BUT, to me if we hadn't lowered the bar MASSIVELY, it would NOT be fine.
I've seen people at my work that will push or even deploy features that don't do what their main purpose is and they just dismiss the issue saying it's a bug. As an example, a button that's supposed to open a modal window if you click on it. If you go test it and the modal doesn't open, they'll say "oh, there's a bug".
You developed or even deployed something that is wrong and completely useless. Just one year ago, this would be unheard of and you would've gotten a really hard time for it. Now it's just a bug and part of how we're doing things.
Like I said, I just do what I'm told at work but to me this is just wild. There's no way it won't come back to bite us.
I use AI all the time, it gives a tremendous boost in speed for many tasks and it is most certainly here to stay, but there is something off about certain things, like code comments. Like a weird person.
TBH i expect it'll take several years before people largely settle on what works good and what works bad (or doesn't work) and that's assuming things wont chance in a massive way during that time.
And this isn't really anything new, people rarely come up with some new way of programming and have everyone learn and understand best uses from the start - it takes years (and that is assuming everyone will agree that'd be something worth bothering about).
A node glob() or a regexp string.replace call is probably easier to read than spaghetti shell.
And your llm might do a much better job of creating clean, readable and testable code.
Well, that means the quality actually dropped then :). Looking impressive isn't equal to quality, understandability and reliability is
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:
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% done; 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.