AI Won't Make Your Senior Engineers 10x Faster

The AI Productivity Gap

AI Won't Make Your Senior Engineers 10x Faster

Despite AI's promise, senior developers save only about 15% of their time, while juniors gain 25%. The reason: coding is a small part of the job. Most time goes to design, debugging, reviews, and meetings—areas AI hasn't transformed. Ironically, leaders who think AI replaces juniors are wrong; juniors benefit most, especially when using AI as a learning tool.

Being a good coder is table stakes.
  1. matthorse

    Writing code is a small part of everyday's job of a software engineer. The article's table reflects this fairly well.

    AI compresses implementation time for an individual engineer, but architecture decisions, design reviews, integration, testing, deployment, and production validation remain largely serial activities. If code generation speeds up by 5x while those bottlenecks don't, you've mostly increased the team's work queue rather than its throughput.

    With the current capabilities, models still need constant babysitting and course correction. An engineer who lacks the skills to guide them can end up creating more work for the rest of the team. AI makes it easy to generate code faster than you can understand it, and that cost is paid during code review, debugging, and maintenance by colleagues, whose confidence in that engineer's skills may be affected by his use of AI.

    What looks like a productivity gain for one engineer can become a productivity loss for the team as a whole.

  2. moezd

    Writing code is cheap. Coming up with a plan to stay updated on specs and verification are not so cheap, and you need more attention there than ever, because an LLM will take your half-assed spec and claim victory as it prints linted code that compiles and passes a few token unit tests while being under (500 or 1000) LoC.

    That's PoC-level, happy-path-only engineering and LLMs are very dangerous at inserting subtle hardcoded values and cheats along the way, which makes it really hard to spot them later on. You need a system to whack them before they infect your codebase terminally, be it hyper vigilance, more SCA, more TDD, SDD... Otherwise you'll wake up one day with a production incident at 3 am and wonder how that code was even allowed in the release bundle.

  3. PostOnce

    Pre AI and Post AI code review hours are both 0.75 in this made up example. I find that implausible.

    Even with the same amount of code, AI code is less trustworthy* and requires more attention... but we know it won't be the same amount, it will be more. This means it will take longer to review, or there will be unforeseen consequences of not spending that extra time.

    *meaning no human eyes have looked at it and said "this doesn't make sense", or "this is cheating", or "this doesn't meet requirements", and won't be caught until code review if at all.

  4. laszlojamf

    What I have noticed in my own work that a lot of the time that used to be for coding is now just waiting. I have three agents working on three different features in parallel, and I'll go back and forth with all of them, correcting things and steering etc, but then I find myself with three busy agents and nothing to myself except stare at the screen while they code away. There is a mental budget for me where I can't have more than those three running at the same time and still keep track so what I end up doing is just scrolling HN...

  5. orwin

    The two last hire we got a year ago still don't have any ownership of anything. Even the project they coded 'themselve' where we involved them in the design and let them cook almost on their own, we are the one chasing bugs and defucking everything six months later because, probably unlike them, we actually read the PR (I'm mean, they probably did read it too, but today I'm extremely pissed, I'm at the point of calling a meeting to figure it out, it cannot continue like this). I've never took more than 4 months to at least understand most of the code, I feel like a year later their level of understanding is still the same. They are basically ai overseers at this point, but while I do more code review than ever before, I feel like they learn around the same as LLM, basically nothing.

  6. Diti

    How to get rid of every highly-skilled-but-unmedicated neuroatypical developer (could be people like Xe Iaso or Soatok):

    > hiring someone who is a good coder, but has trouble reasoning about systems, has no patience for working through hard problems with others, and can’t break down vague requirements into tangible action items.

    Why not hire the excellent developers for the highly-technical skills they bring, and match them with architects/product managers who are the ones who have the big picture? Am I crazy to think like this?

  7. dwedge

    > There’s no doubt that AI has already improved the productivity of engineering teams, and will only get better in the coming years.

    They lost me by begging the question in the very first sentence.

  8. k1e

    Its too early to measure. Agentic coding harness'es arent mature yet. People try different approaches (with sub-agents, or without etc). Productivity will likely increase in near future even if new LLMs will hit the ceiling.

More from this day

2026-08-03