this post was submitted on 19 Sep 2026
42 points (97.7% liked)
Asklemmy
55603 readers
388 users here now
A loosely moderated place to ask open-ended questions
If your post meets the following criteria, it's welcome here!
- Open-ended question
- Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
- Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
- Not ad nauseam inducing: please make sure it is a question that would be new to most members
- An actual topic of discussion
Looking for support?
Looking for a community?
- Lemmyverse: community search
- sub.rehab: maps old subreddits to fediverse options, marks official as such
- !lemmy411@lemmy.ca: a community for finding communities
~Icon~ ~by~ ~@Double_A@discuss.tchncs.de~
founded 7 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I mean I still prefer writing code by hand and I still write higher quality code faster by hand than others on my team who use LLMs to write code for them. Writing good, production intent, software is not about wpm, nor is more code necessarily better. Concision (as long as it doesn't sacrifice readability) is a virtue.
I watch a streamer who game devs without AI because I appreciate watching him discuss his thought process & learning more about how I could write it manually. For context, I’m a game designer who knows some code, not an engineer. There’s real concern around skill atrophy without people doing some of these more manual ways of doing things.
My point about WPM is moreso about how the scale impacts velocity. I do think the speed impacts the old adage about software & pregnancy.
There was a quality of software development where work takes the time needed, and sometimes throwing more bodies at something wouldn’t alter the time. A good engineer could maybe shave some time off, or the patterns they used were more resilient or production ready on the first pass. Now, that engineer could genuinely deliver that feature much faster.
Here’s another trap I forgot to mention: our human read speed is always faster than our write. We may write up to 330 wpm, but your read speed is 400-1000 wpm. AI read speed is like 11m / wpm. The gap between our write v. read suggests it’s faster to describe a plan, read what the AI wrote & triage it, rather than the alternative.
I mention John Henry because in the story Henry wins but dies in the process. Going fast is not the only goal, but the scale of the velocity change happening is really difficult to overcome mechanically on paper.
Finally, to be clear, I say this stuff as a bitter pill I don’t want to swallow either. :/ I have my own emotional qualms with the whole situation. There’s big business risks around becoming captured markets & beholden to token costs. I think part of the AI acceleration is about creating that dynamic, and it greatly concerns me.
Reading speed is not equivalent to code review speed in the slightest! A good case study: https://static0.smartbear.co/support/media/resources/cc/book/code-review-cisco-case-study.pdf Tl;dr the ideal rate of code review is something like 300 lines per hour.
As someone who writes software for a living, these tools are simply nowhere near as good as a seasoned developer in terms of code quality. Getting them to write code at that level takes so much babysitting and tweaking that it is faster to just write it by hand. If you are not a full-time developer and are just writing some code on the side here and there, then yes, an LLM will probably do a better job. And thats ok! I've used them plenty and thought about this a lot as well. So I don't say this out of denial. But, at least for now, they are nowhere near a good as someone who knows what they are doing if you account for quality, and not just how fast the machine can spit out lines.