2x, not 10x: The Real Impact of Coding with LLMs in 2026

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

2x, not 10x: The Real Impact of Coding with LLMs in 2026

I argue that LLMs offer a realistic 2x productivity boost rather than the promised 10x, as they excel at automated feedback loops but struggle with code maintainability and documentation. While I use them to generate rough drafts, the heavy lifting of structuring and refining code remains a human task. Future gains will likely come from retooling workflows around current capabilities rather than waiting for model breakthroughs to solve fundamental limitations.

A working implementation used to mean a task was 80% done; now it's more like 20%.
  1. 5555watch

    I'm probably a weird outlier. Coming from academia, it's ranging from 1x to infinity-x (as in, certain tasks wouldn't even be touched if not for AI).

    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)

  2. pantelisk

    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.

  3. gashad

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

  4. lazopm

    The way I see it you should calibrate the way you work with LLMs based on how confident you are on that specific area, and if it's your responsibility to own/understand it. Here's how it feels for me:

    * 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

  5. tmsh

    I think it matters a lot to understand the kernel of AI in the past 10 years. It's the only way you can truly appreciate the exponential. It looks flat unless you see the dramatic leap in transformer architecture and scaling laws and reinforcement learning. I know it's been hyped to death but you have to see how those things are truly exponential at their core to appreciate how it's not just walking up one step or two steps faster and how it's walking up buildings etc.

  6. bthornbury

    for me, almost all of the work is specs

    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

  7. fg137

    I recently removed about 50% of code in a feature submitted by a colleague, because it's a pile of over-engineered mess that either never gets used or caused trouble for us. We probably would not have added the code in the first place if we actually discussed the design. With the code removed, the feature is now much simpler and more maintenable.

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

  8. Alwayshasbeeb

    Sometimes small tools are all you need, even if they're slop.

    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.

More from this day

2026-07-30