Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- > Myth 3: Lines of Code Written by AI...
how come lines of code (or expressions) by an engineer aren't a good way to measure progress (Gates point etc) but GenAI tokens must count and be paid for?
by al_be_back - That's a good point. They're not selling progress, they are claiming to enable progress by selling you (tokens in -> tokens out), making it your responsibility to connect the two. Filling that gap is part of your expertise that you can get paid for.by dxdm
- > f developers spend only about 15 percent of their time typing in the editor
I think this is missing an important detail. Lots of time was spent on non-coding stuff, because coding used to be more committal and hence expensive. With how quickly one can code up a quick prototype or even production-ready code these days, the code becomes the communication tool as well.
by levmiseri - I can't remember of any product in my lifetime that was more over hyped than AI.
It's a huge piece of shit and if I wasn't forced to use it at work I would never use it.
It writes dumb, throw-away code and adds thousands of dollars/developer in costs. All this crazy code that we're adding to our projects will come back to bite us in the future, there's no way it won't.
by altern8 - |--------|-------|------|------|-------|------|
|Contract|Product|Design|Coding|Testing|Deploy|
Writing Code Isn't the Bottleneck, until writing code is the bottleneck, until it's not again.
by Supermancho - Getting a usable PRD is often the bottleneck.by pstuart
- You forgot to add "coordination" to that pipeline. That is easily far and away the biggest source of delays.
That includes talking to vendors, meetings with every layer of stakeholder when just one person digs their heels, etc.
That is truly the final frontier for "AI", and one that it will likely never cross. That would be when even the execs and upper management feel threatened by "AI". But, since they also delegate so much, you often see someone at the bottom of the totem pole in those meetings. This is why nobody is getting replaced by "AI". We really need to move this discussion away from the scifi stupidity already. There is no singularity or godlike AGI about to take over the world.
I hate to use awful terms like "synergy" and "teamwork", but they do have a lot more substance and truth to them than any perceived threat from "AI".
by sublinear - I don't understand Myth 1 (Developers Spend Most of Their Time Writing Code).
They quote a study in which developers report to spend 11-14% of their day coding. The rest is stuff like solution design and meetings. The insinuation is that AI can at most automate 14% of your day.
The problem with this argument is that once you have code, some (not all) of the precursors to code go away.
by kylecazar - I don't know about others, but at work, the reason I only spend like 14% of my day coding is because I'm lazy, not because I'm actually doing other stuff.by deadbabe
- Also AI is now drafting design docs, generating PLC work products, entering it all in Jira, characterizing and root causing bugs... It's speeding up the 86% of my job that isn't coding. The article is a bit myopic and frankly contradicts itself.by 01100011
- Yeah, this seriously drives me nuts.
That meeting that you spent an hour in to understand the requirements? You don't need that meeting if you're not writing the code. That sync up with the QA engineer you did to hand it off to them? Don't need that meeting if you're not writing the code. That half hour you spent installing vim extensions? Don't need 'em if you don't open vim anymore.
There are engineers whose jobs go well beyond coding, of course. Staff engineers and principal engineers have had their jobs radically change because of AI, but not because it's writing all their code.
But there are also a lot of engineers -- your standard mid-level engineer, or even senior engineers at a lot of orgs with title inflation -- whose job is almost entirely about delivering code, and who spend all day either writing code or engaging in scaffolding around code-writing activities. Let's not pretend that automating away that code writing is a 15% boost.
by mkozlows - If Claude told you to work on a task that you don't want to work on, or make a design choice that you think is wrong, would you do it? If not, then it can't really replace things like design or meetings. (Note that this is subtly but importantly different than the "vibecoding" model, where you just don't bother to supervise Claude's decisions.)
- Okay.
Show me the evidence that AI has an impact on productivity when doing design work. Or reducing meeting load.
My own experience is that AI doesn't tighten the design cycle, and in fact might extend it by encouraging gold plating.
- This reads like a critique of 2023 tooling published in 2026. Their Amdahl-style arithmetic (speed up a 14% slice, cap your gains at 14%) holds only if "AI" means autocomplete. Current frontier models do far more than that: research, code comprehension, review, test authoring, debugging, exploratory prototyping, ideation. That's most of the rest of the working day or "86%".
The only point that still holds is that organizational policies and procedures that automate AI use and lower the barrier to entry are more efficient than leaving it up to each individual. Every other point they make is either stale or was never true to begin with.
by armitron - > Myth 2: Writing Code Is the Bottleneck
Writing code is indeed the bottleneck for same resource constrained companies.
Rapid code development creates more opportunities for trial and error, providing companies with more information for decision making, that previously might have been addressed by meetings.
Of course, this might bring other problems, but it might not right to generally speaking that writing code is not a bottleneck.
by langs - I’m very suspicious of this objection, because when Claude first landed the same people now saying “code is not the bottleneck” were saying “the generated code doesn’t work.” Smacks of moving goalposts.
The only solid objection to “AI is going replace developers” is “AI is an accelerant.” It helps developers move faster. I haven’t seen anywhere it has fully replaced developers.
Whether this leads to a large number of job losses depends on whether you think we can increase software output by the same factor as the acceleration and still be profitable. I think we can, latent software demand is extremely high. I also think we’re nearing the limit of capability with current models.
Situation could change if more advanced models emerge, but some of the more foreseeable advances probably have compute requirements beyond today’s hardware.
- Like many others in the comments, I feel there are a lot of assumptions in this piece. Before, coding is only 14% therefore, small slice. I think that's a very superficial assumption. That was because coding was expensive and we needed to be sure we didn't code the wrong thing. If code is as cheap as it is now, we will optimize differently, we will structure around it. Instead of so many meetings we will code 5 different versions of the same thing and choose, etc.by lz400
- So you're suggesting that coding will take more of the PRD phase?
- > Before, coding is only 14% therefore, small slice.
But also, no, because they write:
> “coding” (not including bug fixing, testing, etc.)
What if bug fixing includes "coding", or "writing code", or however one would want to define that? Especially in the enterprise setting they evoke, a lot of work will not be "coding" in the sense of churning out new features, but "coding" in the sense of fixing bugs. I know a lot of my "coding" is in this category. But we're not given a number for it. I suspect the slice would be bigger if they included this type of "coding".
by derdi - > That was because coding was expensive and we needed to be sure we didn't code the wrong thing.
Coding has never been expensive as it is nothing more than a reification of a solution to a problem as it is understood at that time.
It is the underlying understanding of the problem which has always been expensive and remains so.
by AdieuToLogic - I feel like all you need to know about how seriously to take this is that they cite that ancient early-2025 METR study, and describe it in the text as "recently one even found..."by mkozlows
- I felt the same and why didn’t the authors look over METR’s recent material?by CompoundEyes
- Same thought - 80% through reading it occurred to me to check the citations. A few items from 2025 and most well before that.
So much has changed since late 2025 one can’t really draw any conclusions from this.
In fact, I’m guessing things will continue to move so fast that by the time one were to execute a survey of developers, many of the responses and findings are no longer relevant.
by katzgrau - I've found that using LLMs for significant amounts of code generation completely drain the result from any dopamine I would get doing it myself.
Have others noticed this as well? This is going so far as to me losing interest in side projects because I have "lost touch" with the code base.
by mfru - Yep. ADHD very strong in this one, so LLM code generation takes pretty much all joy out of coding. It’s like watching a computers play chess. Yeah, no thanks.
- With GenAI, we can now produce something without caring about it - or while caring about it very little.
And the parts we don't care about aren't necessarily worse, they are just... arbitrary. Could be good, could be bad, no one knows, because no one really cares.
I find that if I care about something a lot, it's a pretty similar time investment than pre LLMs. And it makes me feel invested and proud in the result, motivated to show it and improve it.
If I care about something very little, in the past I just wouldn't have done it at all. Now I might, but I feel that same disconnect you mentioned.
I think being strategic in what we do and do not care about is likely the key skill we'll have to build to actually make the best of the tech.
by fhd2 - > We already know developers don’t actually spend most of their time writing code, with studies at Microsoft and elsewhere showing it’s closer to 14 percent.
Anyone else finding they're spending more time writing code (or at least driving agents to write code) now?
14% used to feel about right for me - I'd spend the rest of the time researching approaches and libraries, planning things out in issues, or sometimes just thinking really hard about problems I ran into.
Now... I still do those things, but I'm doing many of them faster - and I'm often doing them while my coding agents are churning away on code.
There's also this weird effect where the harder a problem is the more I can get done in parallel with it, because an agent might need to spend 20 minutes on it without my involvement.
by simonw - Yeah. I spend most of my day driving agents to write code, verifying the results, orchestrating work streams, and so on. The rest of the time, a Fable agent is organizing work in Linear/Jira and making sure coworkers are getting their stuff done in a way that won’t conflict.
- Does the code get reviewed? How do you deal with increased amount of code that may need to be looked at?by geraneum
- I used it to write SQL and make dashboards. Back in the day, I would spend a lot of time doing that, then I changed roles. I dipped my toe in it recently and used AI exclusively. I would send a prompt, see the output, decide if that is what I wanted or not. I kept my brain in "what-if mode" and I let the LLM handle the technical specs.by geoduck14