2x, not 10x: coding with LLMs in 2026
101–110 of 260 posts
Re: 2x, not 10x: coding with LLMs in 2026
#102I spent 30min with Opus 5 generating some CSS and components for my Phoenix LiveView template project (which I use for starting new projects). Then I spent around 5 hours parsing and cleaning up the output. I could of course not have done that, but since it's my spare time project I can care about the code and quality. I did get wins for sure (and I did save time), and I'm sure most people wouldn't even spend five mi…
I suppose it's yet to be seen, but I'm seeing a lot of spaghetti code being dump into the codebase I'm working on at the moment by other devs. I don't think it's wrong per se, but human code would have thought more about the right abstractions and trade-offs for future maintainability.
There is a gap right now between what an AI can and can't do, and I don't think it's just a time and cost limitation either. It seems like current AIs are very good at writing good code at a surface level, but very bad code when you zoom out a little.
We have a lot of non-technical people committing code these days to constrained microservices and from time to time things break and I'll take a look and I'm always just like wtf am I reading? You see code so bad that you'd immediately fire a human engineer had the wrote it. Thing like explicit hacks to bypass errors that it should not be bypassing or mock data to fake some API that it wasn't able to access. Stuff which literally no human coder I've ever worked with would be contemplate doing...
I think it remains to be seen if the 2-10x speed up some are claiming to have today will persist if the junk code continues to grow.
Re: 2x, not 10x: coding with LLMs in 2026
#103While 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.
This has led to 3 parallel pieces of adjacent work that each speed up our build by quite a drastic margin. When combined, this is a massive improvement. None of this would have happened in the old days, as the research itself takes a long time to babysit and a lot of options to check.
So I very much agree - the activation energy can be a lot lower on some kinds of tasks, and some of those get big returns for small inputs. It's not all like that, but part of the game is identifying when you can spot those high return efforts.
Re: 2x, not 10x: coding with LLMs in 2026
#104This 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…
We built a conversational terraform platform at work, you describe what you need for your infra and it produces the terraform code following company standards and rules. What is important for us is the LLM never writes any code. It just extracts a structured spec from the conversation, and a deterministic engine (plain python, no LLM) renders the code from approved modules only. So there is no "code quality" discussi…
Re: 2x, not 10x: coding with LLMs in 2026
#105Earlier quoted context omitted.
> 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…
Not every engineering effort is a product in search of market fit or a community. Some things are already very useful as just a one shot. I just made a quick app to help me pack for a trip, it updated forecasts every day, let me know when rain entered the forecast at one of my stops and gave me a checklist that helped me quell my travel anxiety. The greatest thing that LLMs have done is allow many to achieve things t…
I think you misunderstood my point: by "legitimate stand-out products", I meant exactly that, with no connotation of commercialization. Maybe you can agree that having a high signal-to-noise ratio for (open source) projects is a desirable goal?
> Some things are already very useful as just a one shot.
I agree. I too have made or forked about a dozen apps and tools in the past few months. It would be dishonest not to consider the flipside, that this software is overfitted to the needs of a single person. Further, this hyper-bespoke software typically feature-complete within moments of the final prompt, and I have,on occasion, completely forgot about the tool/app I spent a weekend created, it clearly wasn't worth the effort I put in.
> The greatest thing that LLMs have done is allow many to achieve things that they couldn't have before.
Let's not pretend there isn't a cost to this.
Re: 2x, not 10x: coding with LLMs in 2026
#106And that's the second time this happened over the past few months.
Re: 2x, not 10x: coding with LLMs in 2026
#107While 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.
Re: 2x, not 10x: coding with LLMs in 2026
#108Earlier quoted context omitted.
I think the ideas worth pursuing still require substantial time and motivation, even with LLMs. Otherwise you just end up with a half-baked sloppy artifact that nobody will ever use or study, for a net negative benefit to humanity.
Well, I’m happy just to make half baked slop for myself. Highly personalized software that is poorly implemented and yet yields the result I desire. E.g. software that generates these models that I can print https://wiki.roshangeorge.dev/w/Blog/2026-06-30/Modeling_a_W... https://wiki.roshangeorge.dev/w/Blog/2025-12-01/Grounding_Yo... Or blog post authoring software https://wiki.roshangeorge.dev/w/Blog/2026-04-25/The_…
Agreed. I haven’t been this excited by computers since I got broadband DSL in 1998.
Re: 2x, not 10x: coding with LLMs in 2026
#109For 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)