So the comparison is not only "built with and without LLM" but "would you even build this if you didn't have the LLM?". The gap in productivity in this case is much more wide.

For stuff that I'm used to (R) I can write nice and compact spaghetti (long %>% pipes). I'm not comfortable when a working script doesn't fit the screen (plus a few scrolls max). My style is probably easy only to me. When I teach, I don't teach it in particular.

AI gives me thousands of lines of codes for those. 10k once. It's cool if it suffices to source it all, but working with that is not pleasant.

But if I can reproduce a paper in a one-shot (it used to be an hour, but recently it got so much better), that's a task that would not have been even attempted years ago. And I'm talking about a methods paper with no available Github (or, as often happens, when the existing Github is useless)

So my two choices are basically “YOLO, LGTM” and hope I can revert if it breaks something, or to just write all the code by hand from the start. With the increased pressure for output, I’ve noticed both myself and coworkers tending more toward “commit and hope it works” over time. It’s sort of perverse incentives in a 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.

* 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

Actual problem: he typed in the wrong password

And that's the second time this happened over the past few months.

I am no longer:

- reading docs for hours and hours

- typing (barely at all)

- writing code

- manually doing tight debug loops

- using an IDE

to do this I had to give up reading or even controlling the code and focusing on behavior/design-level control (not superficial, still dictating overall technical architecture)

i have agents doing everything from writing the code, verifying the code, hardening, increasing test coverage, analyzing behavior, algorithmic perf improvements, managing/deploying to cloud resources, etc... (pretty much everything)

and I am accomplishing projects that would take months or years in a fraction of the time.

that's way more than 10x.

somehow, this is harder and more cognitively demanding than writing code

The 2nd thing is, how do I measure that.

---

In my case, the details of my work (Kinda DevOps, kinda Senior Dev) makes it that having an LLM to do the heavy lifting allows me to do things not only faster, but better, and across domains I do not hold expertise on.

An example of the effect of LLMs in my daily work is that I'm in the middle of a PHP upgrade for a rather large legacy application, and the "heavy lifting" is really out of the scale, letting me concentrate on what really matters, while at the same time if I do keep "the harness" tight I'm certain the results are the correct ones. Also correcting course is just as cheap.

Not having to worry on the tooling on exchange has the incredible desirable result of my velocity being incomparable to what it was before.

Then we have the side effect of how easy to do transfer knowledge: Rather than telling the QA guy how to do the work specific for this task, I defined a set of files (.md documents, skills, an off-the-shelf customised MCP server) that assist QA into doing the work in a way that helps me do my job better and faster.

There's also a clear possibility that what I'm doing will expand to the rest of the team I am in, completely altering the way in which we approach development.

If we take 'x' as 'mileage', yours might vary. Mine has, and I'm baffled at the positive net results I AM getting.

Also, this what I do (coding?) is extremely fun again.

Being able to work close to the speed of thought is the best high.

Between "stable" and "extinct" are many stages of software engineering labor market change, continually more difficult (for labor) as we move toward the latter state.

Software engineering is likely to become a skill/tool attached to another harder to automate ability going forward rather than a vocation/craft on its own.

To the extent that software engineers are employable, they will likely need some other x-factor adjacent to software skills, whether in the science, business, creative/artistic, or social domain. I've already seen this trend emerging in the startup world.

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.

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.

There is a lot of reason to suspect that at most companies, especially more established non-startup ones, there will close to zero bottom line benefit, because these companies already have free paid-for developer capacity (developer down time between project cycles) that presumably they would be utilizing if there were reason do to so. In a startup environment where there is zero down time, then productivity may at least show up in reduced time to market.

I think Uber's current experiment of limiting AI spend to 10% of salary per developer is interesting since it implies that spending more will not even recoup the extra token cost, although it does remain an experiment. Maybe they will see a revenue increase related to AI spending and choose to tweak that limit up, but it's also entirely possible that all they are doing is reducing developer workload by giving them a productivity tool, and there will be no financial benefit.

> 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

i think LLMs are only a useful multiplier if you’re working on the plumbing parts, it’s never useful if you’re doing anything novel really.

if this bothers you, i am sorry and i wish you the best with your reddit trained auto complete. i write new code

We all have a limit after which we lack the attention (or attention to detail, or time, or energy, etc.) to meaningfully manage it.

Similarly, a manager may be able to handle a team of two very well but end up poorly managing a team of 20.

It used to be that knowing how to write code was a big factor in productivity. Now it is less of a factor compared to the many other cognitive and metacognitive faculties that working with agentic teams demand.

Semiconductors following Moore's Law increased their density, which is a reasonable metric for effectiveness, by 40% a year for several decades. Leaving aside projections of AGI in two years, it's still a substantial impact if we can figure out how to increase coding productivity by 40% a year for two or three decades. I don't think that gets us to AGI or the Singularity, but it's similar to the impact of the steam engine, steel, or electricity.

These are "normal technologies" that were transformational, and that may be the path we are on with LLMs.

Is that really from improvements in LLMs, or from improvements in the feedback loops?

From a firm that has fully embraced agentic engineering, they offered topline stats on their measurements of a 4x boost from November to February, and 8x on top from February to May. That's 32x since November 2025, coding with LLMs.

And like whatever, this is second hand and I'm not going to disclose the source. Actual hard, published, and peer-reviewed research is needed here to backup quantitative claims. 2x, 10x, 32x, whatever.

In projects that are so big that no single coder or no small group of coders is sufficient to grasp I don’t have personal experience, but my guess would be that they are just a cluster of other small projects.

About a month ago I pirated an Argentinian movie and the only subtitles available in my language were out of sync and at a different speed/framerate so adjusting for delays wasn't enough. I was unsuccessful at fixing it with VLC and every other "online tool" I could find.

Knowing a srt file is just text with timestamps I vibe coded a python script to take in sample times throughout the movies so it could recalculate the rate and shifts and replace them in the file. It worked on the first try using only the deepseek web chat interface and my terminal.

Without AI I theoretically could have sat down with a pen and paper to figure out the math adjustment, then looked up python input handling syntax which I already forgot, typed something out and then hammered it into shape through trial and error over a few hours. But the friction and time investment of doing that would have been so great I would have just given up on watching the movie instead.

Really depends on the task, my the project and on, and honesty, my instrest and availability at the moment.

The precise and rigorous practice of “engineering” in 2026.

It's become a lever that allows me to learn as I go while tackling problems that are far beyond what I already know. I know a lot, I've programmed for decades in a lot of languages in a lot of domains. But, with the current crop of the best LLMs, I can reach for bigger problems...and actually make progress. I've read books about DSP for audio, and have done little toy projects in the past, but with LLMs, I'm building complex and working synthesis engines in a couple of weekends. That would have required a few months of study and experimentation before. So, that's a huge multiple. Like 100x.

For things in my area of expertise? Probably still just 3x, maybe 4x, because it makes fewer mistakes I have to fix in code review. It still writes terrible docs, as the post mentions...they don't understand user desire, so they simply can't write documentation for a user to actually use. You can't prompt them to make really good docs, but I can usually prod their docs into coherence a bit faster than writing it myself.

But, it's the lever for doing things I've never done that is such an addictive thing. Which, I imagine is how non-technical people feel shipping their first web app or whatever with these things. For basic work, I think we're at a point where almost anyone can use an LLM to make working software (not necessarily secure or stable software, but working). But, I think we're also at a point where an expert can make that lever really do something, and I hope that means we'll begin to see extremely ambitious new software in addition to all the throwaway junk that's been proliferating at a frightening pace.

In short: Maybe don't make another fucking "memory" system for your chatbot so they can be your friend who remembers your birthday, and instead work on something meaningful.

Then I would use Claude to make a small fix, write a unit test (write a unit test, not suggest what they unit test should be) or write some less important UI code. It just felt like old school development, with some assistance. I think we may see a shift back to a "copilot" mode and by the way, I still use GitHub Copilot. The $19 subscription includes $30 worth of credits and the autocomplete in VS code that uses some cheap model is completely free. This autocomplete is very good and I would like the market to focus more on IDE integrations. The agentic thing is either ahead of its time or it will never have time. Time will tell. I think the LLM can only be as good as the training data, so it will always excel at small chunks, but to implement entire projects of which there's such variety, I would question that. And also, how using it to implement entire projects means the developer does not hold the program model in the mind, which leads to more issues long term.

By the way, in this way of working, I see no difference between Sonnet and Opus. Sonnet is good enough to use as an aid.

Sailing into the relms of lesser explored area are painful.

It's like an intern but never learns, only getting replaced by better interns.

This made me chuckle. I do think we are seeing exponential improvements over the years and that we don't always notice it happening because we're right in it.

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.

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.

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

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.

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.

I'm two weeks into a project that has been interesting and also has confirmed the above yet again. I am porting a Windows application written in Python to C# using Avalonia UI.

I have never used C# or Avalonia UI. I've written Windows applications in other languages, never C#. I don't know the language, libraries, etc.

At first I told Codex: Here's the source code, port it. I just had to run that test.

Well, it didn't end well. I'll describe it as a frustrating set of prompts that seemed to result in the implementation going in circles with constant problems being introduced, breaking-fixing-breaking, etc.

I then started again with a clean repository and played the role of the architect with full documentation in the form of code. File-by-file, I had it port modules to effectively develop an operational foundation for the classes, methods, properties, abstractions, hardware interfaces, etc. in the original Python program. That went well, was very fast and a good experience. I am running Codex in JetBrains Rider and the integration is excellent. The native OpenAI Codex application is an absolute dog...it pegs all my cores at 100% while doing nothing.

Once all the underlying infrastructure was ported and, to the extent possible, individually tested, I threw UI integration at it. This happened quickly and OK from it's-ugly-but-I-can-use-it perspective. Codex seems to be way out of its element when it comes to UI/UX understanding. Funny examples like placing a button on top of an image with the image covering the button because it had a higher z order. Or finally placing the button at the correct z order but making it transparent on-hover. Funny stuff when you are moving slowly and you see it happen. It just proves that there is no understanding whatsoever.

With all of that and the experimentation, I'll estimate that a six month project will be cut down to three to four weeks. Another month and it will probably be a much better program with new features and more advanced capabilities.

And I have not touched a single line of code. Developing solid prompts is the absolute key, something that you can only really learn by doing and through lots of experimentation.

Yes, of course, I fed it working code. I think it could be very different if I were to start something from a blank slate.

What you are using it for? What language, what framework, how many LOC, what domain, how much docs can the LLM read, etc etc.

What are you optimizing for? Cost? Human knowing how your code works? Getting something out the door?

How Good You Are at Prompting the LLM for THAT specific set of parameters?

I find AI can save me like 5x time on something, and in other cases it's wasted 5x time. Overtime I'm hopefully learning how to use it better.

I did get wins for sure (and I did save time), and I'm sure most people wouldn't even spend five minutes cleaning up, but this is definitely one place where people talk about different things regarding whatever x speedup they get.

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.

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.

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.

I'm not sure about 1x, 2x or 10x increase as these metrics are about code written but that isn't a productivity metric (something pretty much every half-decent programmer would agree with before LLMs - remember stories about Bill Gates saying that more LoCs being good for software is like more weight is good for airplanes or Bill Atkinson's story about adding -2000 LoCs to improve QuickDraw?).

But they can certainly help "get you going" faster in that if you're stuck on something (for whatever reason - including "that feels too much drudgery") or have issues starting something, you can have an LLM take a stab at it and it'll produce "something". Sometimes it is enough by itself, but more often than not it'll need tweaks (either directly or having the LLM do it). I got to make a bunch of things i couldn't convince myself to do - e.g. an image viewer that doesn't suck (based on my arbitrary judgement), a game database, a script to convert a git repository into static html pages that kinda look like GitHub, etc.

They can also help find (and sometimes fix) bugs or other "code smell" issues. They're not that great for exact results (without tool calling -and knowledge on how to use them effectively- at least) but when it comes to fuzzy / vague stuff like "check out this code <code dump here> can you spot any issues?" they always tend to find some stuff (even if it is hallucinations :-P but sometimes they find actual issues too or whatever hallucination they come up with reveals some actual issues with the code that you didn't spot by yourself). I've been dabbling with Rust recently and asked Qwen 3.6 35B-A3B to judge my code and it wrote "6.5/10, will compile but looks like C in Rust" :-P.

The article says:

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

And sure, LLMs aren't that great about those (i do let them leave whatever comments they want though and remove them later myself - i think those comments help during the generation/prediction - basically how they "think", kinda like the reasoning phase), but they can be very good at things like "here is the code, here is the documentation for it, spot discrepancies" (i had Devstral Small 2 do this and it hallucinated a few discrepancies but also found real stuff i missed in the docs).

I've tried to use Devstral Small 2 for some API docs but found it'd sometimes make assumptions about what function do or how. One approach that might work, but i haven't tried yet, is to write the "guide" myself, then have the LLM write the function docs using both the guide and the code as reference. The reason i think this will work is because it got things 95% correct just having access to the function code alone (and without the rest of the codebase), so the "guide" would help it reach 99%. I do not expect it to get to 100% so a manual edit pass will need to be done anyway (and i have an idea for a tool to assist in the manual edit pass for that - a tool that i'll probably get an LLM to write - BTW good luck coming up if all that stuff would increase or decrease productivity for an actual product and not some random stuff i'm toying with :-P).

One other thing i've also found LLMs useful recently is to have them use the stuff you make and see how they try to use it. I have an old project, a GUI toolkit i've been hacking on every now and then since 2011 or so, though it was never a priority. Yesterday i decided to dump all the header files to Qwen 35B-A3B (i use 4bit quantization that gives me a 256k context - it isn't particularly smart but it is neat to not have to micromanage context size like i have to do with Devstral Small 2 or Qwen 27B where both of them aren't very usable speedwise at anything above 32k context sizes).

Then i asked it to just make a few small programs and it did[0] (the shot shows a paint app, a calendar, a todo list and a unit converter). Pretty much every program found bugs in the library :-P and gave me ideas on how to improve things.

In general i get the impression that LLMs aren't great at architecting things but if you do the architecture yourself and write them a framework to use, they should do a fine job at it.

[0] http://runtimeterror.com/pages/iv/images/d50c436990db203a07f...