Live data from Hacker News

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

obryant.dev

181–190 of 260 posts

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

#181

Earlier quoted context omitted.

Interesting. Framing it as 1x to infinity-x matches my experience too. I've have good success with it reproducing papers with existing code, but not such much with one-shotting new code. Do you have any particular setup for this i.e. special validation prompts or multi-agent stuff or do you just ask something like reproduce paper X until it gets results Y?

I used to chat with "the paper" until both me and the AI were roughly on the same page at what's happening. It's important, as a "full read" of the "full paper" is not always used efficiently if not discussed, I've noticed. I then ask it for a detailed step by step realization (of the algorithm, or the paper/section/whatever), plus some context. Then I pass this as a prompt to a fresh new instance, and task it to imp…

Thanks a lot for sharing! I'll try the discussion to unpack context, that sounds interesting. I end up having such discussions in separate chats anyways to understand what's happening so it makes sense to do it upfront.

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

#182

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.

Yes but I’ve seen some devs waste a lot of time using AI to build something that was a bad idea to begin with. Without AI they might have first spent more time validating the idea was worth it.

Isn’t it better to be able to quickly test ideas and see what works and what doesn’t?

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

#183
post #178

Earlier quoted context omitted.

Those sort of ideas are unlikely to yield major benefit, though. This is basically replicating the plight of the solo open source dev, writ large. Individual programmers have long built the thing they've cared about on their own time (essentially "for free" because, despite kindergarten economics theory, a programmer cannot usually monetize a marginal hour). And it usually goes that the project never gets adopted any…

I don't think this is the right framing, because I think it confuses the means and the ends. Its like making a jig in woodworking. The measure of the jig's success is not whether it gets re-used or widespread adoption, its whether it made it easier to achieve some actual objective. Because the jig is a means to some other end. Lots of these "we wouldn't have done it otherwise" applications are means, not ends.

That is true, but that suggests that the value of software is reverting to the value of a jig. Software that gets deployed to millions of people gets a large valuation because it provides small convenience times a million. In the era of bespoke software, you’re basically 100x-ing the production of a millionth of the value of commercial software. That’s why it isn’t all that impactful in the end and I think it’s worth highlighting.

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

#184

Earlier quoted context omitted.

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…

Thanks! Many of your issues sound more agent / LLM specific than LLMs in general. At least compared to my experiences.

It also aligns with what I saw from Claude & Claude Code when I used it last year for a while. Now I use Codex and don't see (nearly) as much of that sort of behavior.

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

Yeah that's probably the weakest point of LLMs still. GPT-5.6 Sol got much better at this for me. I still usually end up doing 2-3 iterations of prompts and exploration to clean up various things but usually it's pretty light work now.

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

Okay Claude definitely seems to have an issue there. From what I've seen from coworkers using Claude it generates reams of endless docs. I resist the urge to `rm docs/planning*.md`! I don't think they get how bad Claude is at that.

A month back I tried the latest DeekSeek and it made reams of text back and forth with itself, but the code it output was reasonable and it didn't make pages of markdown files either.

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

That's a bummer. I found that once the models start having problems that it cascades.

I've also been able to keep steady progress on a 70k+ LOC GUI side project without the endless whack-a-mole of bugs using Codex and Sol. Squash a bug, review architecture, move on, etc.

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

#186
> I have not yet taken up woodworking as a contingency plan for "Software Engineer" becoming an extinct profession

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.

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

#187
I have a weird issue with using AI for coding. I can code something entirely by myself at my baseline speed; call it 1x. Or I can use Claude to do it, and it does it in 1/10 - 1/4 of the time. The problem, however, is that to review Claude’s code properly takes 2-3x the amount of time it would have taken me to write it all by hand.

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

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

#188
post #154

Earlier quoted context omitted.

> it produces some extremely crappy code that would've NEVER passed a code review 1 year ago 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”

Code review has always been pointless

I’m glad somebody said it!

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

#189

I have a weird issue with using AI for coding. I can code something entirely by myself at my baseline speed; call it 1x. Or I can use Claude to do it, and it does it in 1/10 - 1/4 of the time. The problem, however, is that to review Claude’s code properly takes 2-3x the amount of time it would have taken me to write it all by hand. So my two choices are basically “YOLO, LGTM” and hope I can revert if it breaks someth…

The models are good enough these days that I see it like managing a team of juniors. The LLMs need guidance and oversight, and about the same amount of time I'd spend reviewing code from a junior I spend on the LLM output. I think generally it's best practice to work in a way that "commit and hope it works (because it passes all the CI/CD automated testing and verification, and it's a change gated behind feature flags and has an identified and minimal blast radius, etc)" is possible

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

#190

I have a weird issue with using AI for coding. I can code something entirely by myself at my baseline speed; call it 1x. Or I can use Claude to do it, and it does it in 1/10 - 1/4 of the time. The problem, however, is that to review Claude’s code properly takes 2-3x the amount of time it would have taken me to write it all by hand. So my two choices are basically “YOLO, LGTM” and hope I can revert if it breaks someth…

This is what I've seen. There has been a middle-ground though, that I've seen. I was using Jetbrains' AI Assistant, or whatever it's called, during an interview for the (nearly) first time, and I only used it as auto-complete, but it was consistently, surprisingly, very accurate. I literally did write it faster. I scanned the literal next line, in the context of what I was writing, with all that context in my brain, and I saw what it wrote and went "yeah, that looks good". I'm a very fast typist (~> 100 wpm) and I still found it beneficial for writing out work fast. Further, since everything is still in my mental context and I can evaluate it at the same time, I feel like I can trust that type of code more.

But maybe that's just me.

Post reply on HN