Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- It's like you just made up those numbers and then developed your thesis around that.by raver1975
- That’s exactly what was done.by steelkilt
- That’s a wildly uncharitable read.
Empirical evidence through observation or self-reporting, sampling in some meaningful way, would obviously be preferable but is also often just not practical.
Guessing at numbers to check whether your thesis even works with some plausible assumptions is a meaningful first step and to my mind a good way to reason through something like this and make it discussable.
A possible outcome of such an exercise is also that for your thesis to work out you need to make wildly implausible assumptions, so that helps you to discard that thesis.
From my perspective this is a very useful way to approach a hypothesis where empirical evidence is scarce or at least hard to get. No reason to dismiss it immediately – especially since the fact that those are guesses was never hidden.
by arrrg - It doesn't really matter how much more productive a developer is if all other roles at the company don't follow suit. Before a developer picks up something to work on a series of roles had to set their eyes on work to be done. Project/product leads, tech leads, business people stamping and deciding on priorities. Then there's all the work that happens after a developer finishes work which tends to be manual as well. Review, QA, education, ops changes, marketing material, education articles, webcasts, showcasing features to end users and lets not forget end users actually making good use of the amazing new features shipped and likely many more largely sequential processes depending on company size and product/project type.
There's no real way to get to a 10x developer nowadays. Even if a company somehow achieved the magic productivity increase in all employees you still need a 10x consumer to gulp it all down.
by crnkofe - The exception here is probably in very small companies. I'm curious to see if LLMs can usher in a new golden age of the one-programmer-one-designer-one-sales indie teams that typified so much of the 80s and 90s...by swiftcoder
- "We can disagree about the specific numbers here, but if you think this is wildly off, you’ve probably never been a senior developer"
I'd even say the productivity gap is even smaller, if not negative in some areas...
by mawadev - I think juniors and fake seniors are a lot more productive because they were never really able to measure their productivity so spamming LoC and trusting AI output makes sense to them.by dwedge
- I've had similar conversations with a client recently while discussing estimates for a large project. Senior leadership has a mental model where AI makes everything X% faster, but that's very wrong. Some things get sped up by an insane amount and basically go to zero, some others not so much. Entirely new tasks emerge, such as directing agents to provide them the context they need, setting loops, etc.
It's a very O-ring problem.
by qsort - Based on personal observation, a lot of productivity has been thrown out of the window with unneeded refactoring, rewrites and "what-if" scenarios that the AI agent will spot.by vb-8448
- "... unneeded refactoring, rewrites and "what-if" scenarios ..."
Like so many senior developers I have encountered. That stuff is good for CV.
by dude250711 - > Reading and Debugging 1.5 1.0 > Code Reviews 0.75 0.75
Since these numbers are made up, I may as well throw my personal anecdote in the ring. I find reading and reviewing far harder with coworkers who are using AI. Tickets contain about 5x as much meaningless junk as they used to, and testing notes - while far more thorough - are often now multiple pages in length. Reviews also contain much more code, people try to do more drive-by fixes because the models can generate those fixes so quickly, and people understand the code they're submitting far less clearly because the model is able to generate fixes they simply couldn't previously.
I feel less productive than I was a year ago, and I don't see my team shipping more features than they were previously. But everyone reports that they're far more productive. I don't get it.
by tempfile - You don't get it? It's like this:
"Make me a picture of a house".
> AI proceeds to draw a house.
"No that's not right, it should be a red bricked house. Not a brown one."
> AI redraws a red bricked house.
"No. It should have a 2 car garage, sit on top of a hill. Also it should have a front porch, and have a tree right in front."
> AI then draws a red bricked house on top a hill with a 2 car garage with a front porch and a tree right in front.
...
The issue is that people think AI should automagically create some vague idea in of theirs, without having to do the work of spelling out all the exact details. So AI (like people) must make some assumptions about what wasn't specified. Like since you didn't specify a "red bricked house" in your initial prompt, but merely a "house"... it had to come up with something as to the color, and did as you otherwise asked, but it didn't know you actually wanted a "red bricked house", since you never specified that detail. Hence why it failed to do what you wanted, and you had to "review and correct it".
Again this isn't solely an intelligence problem, but an inherent problem in language/communication, of unsaid assumptions/specifications. Of being unaware of what you don't know, unaware of your own assumptions, sometimes even being unaware of what you even want. It's why AI can't fully get rid of jobs in software.
But sometimes people just don't care. They just want a picture of a house made. Anything remotely resembling a house will do, not necessarily a solid one, or one that can withstand a magnitude 8 earthquake. You know... like something people can put up in minutes so they don't have to do hard work... such as a shabby old tent. And AI is very good at generalizing, so it can in fact achieve this. So everyone reports they are far more productive now, putting up tent after tent. Meanwhile, the people responsible for the slop have a nightmare to review...
by Rury - Your process engineering is lacking. Just throwing AI at existing workflows seldom produces good results. Processes have to be reengineered to benefit from the strengths and cover for the weaknesses of AI systems, with observability at the right inflection points being fundamental to success.by K0balt
- The numbers are completely made up. Jr developer 2.5 vs 1.0 while "regular" is 1.0 and 1.0? The more senior the bigger the work. It's the same across both, worst case.
0.75 to 0.75? Rework from review is also much faster. Now you don't have to tell a peer to rework a bit here and there for obvious reasons and spend time on a new loop. The review process isn't atomic.
Our production pipeline is faster across our very large organization, after implementing AI processes.
> Tickets contain about 5x as much meaningless junk as they used to
This is a process problem. Developers should be able to answer questions about their PRs, or you reject it. It's not a daunting blanket issue.
by Supermancho - > 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.
by dwedge - 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?
by Diti - You're looking at the forest, OP is looking at the trees.by ramon156
- > no patience for working through hard problems with others, and can’t break down vague requirements into tangible action items.
These are very convenient and vague enough excuses to single out whoever honestly says your architecture is stupid.
by wannabe44 - No. There is this persistent belief in the industry that programmers should be good at everything, not just programming itself: communication, product management, design, sysops, UX, coaching, management, testing and so on. The most visible product of this belief was the once hyper hyped role of “full stack” developer.
The really is that you could have experts in each area doing what they’re good, which means letting programmers actually program most of the time, and let business analysts figure out requirements, product owners decide features, designers decide UX and design, QA perform in-depth testing… sure , every programmer will have to manage some of this themselves to not get blocked the whole time waiting for someone to decide something, but that is NOT the same as just having programmers handle everything!
I think that if you only ever hire programmers who are also kind of people person, you definitely have to accept missing out on the antisocial but genius ones who are very likely the only ones capable of tackling the really hard problems! Unpopular view, I know, but it takes a certain type of person to achieve excellence in some areas. Just look at the most successful artists, writers, actors and especially CEOs. Programmers are clearly in that category. I’ve seen “normies” trying to write a little code. They don’t last an hour before they decide it’s bullshit that you need a semicolon precisely placed for the code to not explode, or that they can’t compile on this system until you’ve installed some tool chain that requires a bunch of commands no one knows by heart but you just need to make sure to follow exactly, otherwise hell may break lose.
by brabel - 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.by orwin
- This is the new normal now that computer science based SWEs are being replaced with "LLM whisperers". Being 10 times more productive with AI necessarily means you're going to have 1/10th of the understanding of the code you're producing. It physically couldn't be any other way.by ryandvm
- 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...by laszlojamf
- I find myself in the same situation, baby sitting AI agent, monitoring them. It's like l've become a coordinator.by pop3zxcv
- Which is why, when I can get away with it, I only use AI for improved code completion, or generating the initial boilerplate.by pjmlp
- You need loops so they run longer and use less of your context and brain power. Then (and this is where WFH is a super power) do stuff like walk, daydream, come up with killer ideas like a Madman episode laying on the office couch.by hahahaa
- This has been my observation too. Because I'm chatting it feels like I'm not working, so any output can be "productive" in that context but I'm hyper aware of all the negative time here. Correcting, pushing it back to the prompt, reminding it that it doesn't have full context so do what I told you not what you think, and then verifying it and correcting it (always) seems to take longer than just doing the work myselfby dwedge
- It reminds me of multitabling at online poker. More tables translates into more revenue even if the ROI per table is lower as you don't dedicate as much attention, until it collapses from not being unable to do the right decisions on time and keep tabs on each player. The main difference is, with agents you might be creating (technical) debt.by fer
- I stopped using coding agents after more than one and a half year of active use, it really started to become way too boring, and I’m t a point where I just hate having to babysit them and for the 200th time make it understand what the actual goal is… and to be honest, going back to writing code by hand without assistance is really hard at first you continuously have that little voice telling you how simple that would be with an agent. Then after a little bit you’re back to being productive, but I still get that voice in my mind. I’m wondering if that’s how addiction feels (way lighter of course).
That whole experience of going deep for a while into LLM coding, then trying to leave it behind made me pretty pessimistic about the future of our profession. We are creating a whole industry of people delegating their ability to work to a software stack currently controlled by basically 2 companies (that both have very sketchy financials). Doesn’t feel healthy
by dgellow - 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.
by PostOnce - at big tech the numbers seem about right. at smaller firms - you've less admin, less meetings - so the coding part is higher.
mind you most of the stuff posted here is in regards to big tech - even though it's 'hacker' news.
by dzonga