Live data from Hacker News

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

obryant.dev

131–140 of 260 posts

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

#131
Even if that 2x were a representative number (although another HN story today says 1.1x - 10% improvement), what really matters is whether companies are overall seeing any AI spending return on the bottom line.

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.

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

#132
I'm probably in the 5x-10x range, but we are a very small team, and we've been accumulating a backlog of ideas over the years. I drive the architecture, and have almost complete autonomy over the work I do. I think someone in my shoes will see a greater result than someone trying to do the same thing in large team, with all the usual process and ceremony, only wanting to go faster.

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

#133
post #46

Earlier quoted context omitted.

AI is great because my job is a lot easier, but it produces some extremely crappy code that would've NEVER passed a code review 1 year ago. 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 skepti…

I read this a lot, do you have examples of this? Last year the code produced by LLMs was pretty sloppy, but recent SOTA models seems pretty good to me. I'm curious if I'm missing something or it's folks using different models or difficulty levels.

From my experience, a snippet of code will look good.

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.

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

#134
I can accept the author's premise that LLMs double coding productivity today.

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.

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

#135

While I agree with the premise, I think this angle only applies on work one was going to do no matter what. The real power of these tools is that there are so many ideas people would like to try, but never have the time or motivation to pursue. 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.

> The real power of these tools is that there are so many ideas people would like to try, but never have the time or motivation to pursue. This can be a negative multiplier: code I thought I wanted that gets immediately abandoned is a net-negative if no one else wants it (lets face it, this is the safest default posture for software of unknown providence). In isolation, instant-abandonware takes up hdd space, burns d…

> This can be a negative multiplier: code I thought I wanted that gets immediately abandoned is a net-negative if no one else wants it (lets face it, this is the safest default posture for software of unknown providence).

obviously not ? negative result is still a result, just like in science. It adds new information ("approach X does not work" / "is useless") which is the only thing that matters

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

#137

I'm probably in the 5x-10x range, but we are a very small team, and we've been accumulating a backlog of ideas over the years. I drive the architecture, and have almost complete autonomy over the work I do. I think someone in my shoes will see a greater result than someone trying to do the same thing in large team, with all the usual process and ceremony, only wanting to go faster.

Where as I'm stuck in a big team with a legacy codebase and lots of business rules, performing small incremental changes. So I spend my days banging the Esc key and shouting "Shut the f**k up!".

Luckily I work remote. I'd turn it off again, but my usage is monitored and I don't want to look like a Luddite.

So may be .75x to .8x range.

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

#138
I think for small projects you need to scale the coders mental model, which afaik works in the fastest time, when you let ai do the exploration and planning, but coder needs to write the code itself and then ai verifies. That generates the best of world codes and the coder at least has written the code. It’s scalable.

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.

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

#139

While I agree with the premise, I think this angle only applies on work one was going to do no matter what. The real power of these tools is that there are so many ideas people would like to try, but never have the time or motivation to pursue. 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.

> The real power of these tools is that there are so many ideas people would like to try, but never have the time or motivation to pursue. This can be a negative multiplier: code I thought I wanted that gets immediately abandoned is a net-negative if no one else wants it (lets face it, this is the safest default posture for software of unknown providence). In isolation, instant-abandonware takes up hdd space, burns d…

You made me do a double take with "providence". I think the word you wanted is "provenance", which comes from latin "provenire" (pro -> forth, venire -> come). English has too many similar words.

Unless you only run code that's protected by God. That's probably not a bad policy if you can verify it.

edit: Oh right, there's an OS for that https://en.wikipedia.org/wiki/TempleOS

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

#140
post #5

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…

The other hard to measure part is that I see/hear a lot of LLM usage going towards dev work that was never prioritized before. 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…

You missed documentation. There was never time for that until now.
Post reply on HN