91–100 of 206 posts
The hell with with whatever speed boost I might get. I still write all my code by hand every day, and own what it does. I know it. And I don't have to worry about atrophy. Could've outsourced a long time ago to humans, if I wanted to deal with reading code most of the time instead of writing it.
I am a student who will be starting my first job this summer. A lot of what is written in the blog is something I have been feeling subconsciously, the joy is being sucked out of programming and idk if I will even have a job in a few years. Most of my seniors from college tell me that they are just prompting in their jobs. I don’t know how I will be able to build intuition for code I don’t write just “understand”
I've read hundreds of books. It may be thousands if you count the multiple series I devoured as a bookish child. I think my understanding of my mother tongue is probably in the top decile of native speakers.
But I haven't ever written a book. I'm not sure I would want to write a book, though I'm reasonably sure it wouldn't be the linguistic skills that would keep me from finishing one if I did.
Not having written any books doesn't keep me from knowing whether a book I'm reading was written well or poorly. I can tell that from my extensive experience reading a variety of books of different quality.
Maybe that's what's coming for computer languages. Maybe people who like reading, interacting with, and understanding computer languages will become highly skilled readers, with the ability to recognize well-written and poorly-written code. Perhaps they'll be the ones guiding the models to improve the code generation, or finding the structural changes that would improve the code for companies making truly important projects.
Or maybe we're just going to end up with incredible amounts of poorly written drivel that works well enough for some niche audience and makes a few bucks for the person who spins it up, and most software won't ever matter on any sort of large scale, just like most books aren't ever read. Maybe there will be some pockets that really care about writing very well and producing excellent things, and they'll hire the people who love bringing that about, and the rest of the people currently developing software will have fun little hobby projects that only their friends and family ever bother to use.
This doesn't seem that different from what has happened with written human language to me.
"Anthropic’s CEO predicted AI would write 90% of code within three to six months of March 2025. None of this happened as predicted." – oh it absolutely did happen!
"Anthropic’s CEO predicted AI would write 90% of code within three to six months of March 2025. None of this happened as predicted." – oh it absolutely did happen!
I don't think we're even seeing 90% now, and we certainly weren't in June or September of last year, which was when it was predicted.
Hi HN, I've been using Claude Code heavily for the last year. Recently I've noticed a shift in sentiment among peers, here on HN, and over on /r/ExperiencedDevs. I wrote down some thoughts on the hidden costs of using AI too much that are not obvious, yet there's no concrete data yet. I tried to pull together data from a few different places to articulate something I think a lot of us are experiencing right now. I'd…
Here's some of the literature I dug up when looking at what is the potential risk to cognition when you don't enjoy what you are doing.
Working memory is "gated"; you selectively process information relevant to a goal - or why you need to turn the radio off to reverse a car. (Numerous papers take it as a given, can't find a specific one developing the exact model of gating)
On working memory and trainability: https://www.nature.com/articles/nrn.2016.43 Working memory is (potentially) dopamine responsive, and expanded by use/training.
On building mental models, writing something down activates more of your brain than typing (cognitive offloading): https://www.scientificamerican.com/article/why-writing-by-ha...
I would argue that typing is better than just reading, and programming requires some extra elements - as you cut and paste to rearrange, run tests, iterate, spatially navigate to where various areas of your code is; so is likely closer to the findings around handwriting than the study. But I don't have specific studies on that.
On reward ($) as a proxy for enjoyment/flow state; and motivation; these two used similar basic designs to experiments https://www.nature.com/articles/s41598-025-09949-1
"Participants performed a delayed-estimation orientation working memory (WM) task with reward cues indicating reward levels at the beginning of trials. The results revealed that motivational incentives significantly improved WM performance and increased pupillary dilation during maintenance. These findings provide evidence for the modulation of WM maintenance by reward through enhanced top-down cognitive control processes."
https://www.jneurosci.org/content/39/43/8549 > "During the task, the prospect of reward varied from trial to trial. Participants made faster, more accurate judgements on high-reward trials. Critically, high reward boosted neural coding of the active task rule, and the extent of this increase was associated with improvements in task performance"
You can also infer from their experiments that low reward = less care exercised.
I feel like a lot of these papers aren't really surprising, but they do measure something that many people have probably felt is true but can't prove.
While these papers don't talk about AI or decline in skills specifically, it's reasonable to say you don't get many of the benefits when it is low reward/passive task execution; where you are leaving review comments that are just reprompting a machine - you know it's not a person, so it feels even lower value to engage than a standard code review might.
I think overall, the rule of thumb around when to use AI should be closely linked to how painful / low reward a task is likely to be. Debugging something with a 10 minute build/test loop and a mystery problem that is not easy to control? AI party. Writing a complex but fun set of business rules? Run it on your wetwear while it is still giving you a sugar hit. An "easy" bug you have stuffed up fixing three times in a row? Push through a bit of discomfort and frustration; but fall back to tooling when you have invested reasonable efforts and are starting to feel slightly fatigued.
I think it's important to be conscious of skill atrophy, but I don't see a problem with it if what you're offloading to AI isn't your area of focus. For instance, I don't necessarily want to always know what tricks the compiler is using to compile my program, even if they are pretty smart.
I doubt it's possible to draw a concrete line between in domain, and out of domain. Would you mind trying with a specific example? Because so much of engineering is understanding the interactions between systems. While I cant enumerate the exact asm codes, I do need to understand how the compiler is going to rewrite my function if I want to understand if a cast is safe, or if this function call order needs to be rewr…
Have we really reached the limit of how much we can reliably automate these things via good old metaprogramming and/or generator scripts, without resorting to using unreliable and expensive statistical models via imprecise natural language?
> Refusing to use AI out of principle is as irrational as adopting it out of hype.
I'm not sure about this. For some people, holding consistently to a principle may be as satisfying, or even necessary, as the dopamine hit of creation mentioned in the article.
I think it's important to be conscious of skill atrophy, but I don't see a problem with it if what you're offloading to AI isn't your area of focus. For instance, I don't necessarily want to always know what tricks the compiler is using to compile my program, even if they are pretty smart.
I doubt it's possible to draw a concrete line between in domain, and out of domain. Would you mind trying with a specific example? Because so much of engineering is understanding the interactions between systems. While I cant enumerate the exact asm codes, I do need to understand how the compiler is going to rewrite my function if I want to understand if a cast is safe, or if this function call order needs to be rewr…
Earlier quoted context omitted.
"so as long as I maintain my ability to reason about code…what’s the issue?" It seems like that is the open question. The article suggests that people don't maintain this ability: "The AI group scored 17% lower on conceptual understanding, debugging, and code reading. The largest gap was in debugging, the exact skill you need to catch what AI gets wrong. One hour of passive AI-assisted work produced measurable skill…
The problem is that that is an incorrect interpretation of the study. The entire task of that study was specifically to learn a brand new asynchronous library that they hadn't had experience with before. As a group on average, those who used AI failed to learn how to use explain and debug that async library as well as those who hadn't used AI on average had, but that doesn't mean they lost pre-existing skills. It's l…