This is a wonderfully balanced and accurate take. I have been looking for the right medium of using AI to assist me. Cannot agree more on the three patterns to implement and there to avoid.
If the three good patterns are adhered to, these AI tools can help us become more knowledgeable, productive.
We get to retain our cognitive abilities and the desire to pursue code development as a means to solving hard problems.
Adopting the anti-patterns, on the other hand, could lead to over-reliance on AI, anxiety when the tools go down (this happens! ), the atrophy of ability to debug and the yearning for immediate gratification and quick fixes.
Most insidiously, when code inevitably fails in production on cases the developer should have reasoned about and covered, they have no option but to toss it back to the AI tool, thereby, creating a vicious cycle of anxiety, helplessness and cognitive decay.
Writing code by hand and managing the mental model of its execution and architecture is one of the few remaining joys of my day job, apart from delivering a good product people want and use and being helpful. Even the small things, the tedious chores of refactoring or scaffolding that initial bit of CRUD boilerplate are steps that matter to me. The callouses matter. The tedium matters. These moments of pain and drudgery inform me on what to do differently next time in a way I worry I would not appreciate otherwise, were specific tools thrust upon me.
I remain because I remain hopeful the pendulum will swing the other way someday.
I've found that I reach for Copilot most often when working on frontend javascript code. Will the incentive to improve the frontend libraries, browser standards, etc vanish now that LLMs let us avoid some of this pain?
That’s why I laugh when people are like “oh, AI writes all the tests, it’s so much easier.” If your code is hard to test, you need to change the abstraction or the interface. Tests are the first reuse of your code, so if it’s a pain to use in tests, it’s going to be terrible to use in general.
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.
Do you have management pressure to use these tools? I don’t have any data but me and virtually every software engineer I talk to regularly is feeling or has felt pressure to use these tools.
FWIW, I'm responsible for our engineering team, and I'm the one starting to put some gentle pressure on the developers right now. Velocity used to be one of the bigger issues we had: Features used to be in development over weeks, while customers, product management, and engineers iterated on the feature, until it was finally deemed stable enough and shipped. With AI, we can shorten that cycle considerably, and get stuff out of the door in days or even hours instead. Doing so requires adapting your processes accordingly, give up some control over the details, take good care of tests, and do proper code reviews.
Given all that, I just cannot ignore AI as a development tool. There is no good justification I can give the rest of the company for why we would not incorporate AI tools into our workflows, and this also means I cannot leave it up to individual developers on whether they want to use AI or not.
This pains me a lot: On the one hand, it feels irresponsible to the junior developers and their education to let them outsource thinking; on the other hand, we're not a charity fund but a company that needs to make money. Also, many of us (me included) got into this career for the joy of creating. Nobody anticipated this could stop being part of the deal, but here were are.
> There is no good justification I can give the rest of the company for why we would not incorporate AI tools
Is there definitive proof of long term productivity gains with no detriment to defects, future velocity, etc?
If so I’d say you’re irresponsible at best to put this much trust in a tool that’s been around for a few months (at the current level). Absolutely encourage experimentation, but there’s a trillion dollar marketing hype machine in overdrive right now. Your job is to remind people of that.
And it is. You are going to end up with a wreck of a product and not a single person you can call upon to fix it. It is your choice and you will pay for it.
If programmer speed and efficiency was truly such a significant competitive factor, we wouldn't be packing them like sardines them in noisy and stuffy open floor plan offices.
yup. no effort - no bliss. and for rare bouts of wanting to shepherd cats I just got meself some actual cats. At least they don't pretend to be engineers.
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 love to hear your thoughts
Fun read. Audience can see Xeno's Arrow emerging on your "we're on the way to AGI!" timeline, a nice visual representation of "the trajectory is real, but the timeline keeps slipping."
But I'm gonna say I've always seen "[retail software] is just a tool" as an odd statement. I've heard it a lot over the last 20 years. "Just" a tool. Why always phrased like that? How can we be overthinking the role of a tool while you're in the middle of a multi-page essay about how it causes cognitive decline?
Nobody frets about the effect of a screwdriver on some IT rando's ability to do other computer stuff if on occasion they're screwing something into a rack. Seems odd to be so consistent about privileging the concept of a "tool" when you're saying that tool is on its way to thought.
>I’m addicted to prompting, I get high from it
yikes, but I did appreciate this honesty. Though, again: "this hash pipe is just a tool" did not appear after this statement
Also - isn't addiction behavioral, as opposed to strictly neurological? Maybe you should do a follow-up on the behavioral effects of a situation like "There’s no spark in you anymore." If you found a new identity that wasn't "I'm a prompt addict," what would it be?
It hit the front page here a few weeks ago, but I don’t think most people took it seriously and got hung up on the $1000/day in tokens part.
I am convinced that approach is the future of nearly all software development. It’s basically about how if you’re willing to spend enough tokens, these current models can already complete any software task. With the right framework in place, you don’t need to think about the code at all, only the results.
I really don’t like that the industry is heading this way, but the more I consider that approach, the more I’m convinced it is inevitable.
I started my coding apprenticeship back in early 80s with a senior programmer who taught me to code in LSI-11 processor codes. I memorized the whole table of octal processor opcodes and learned how to compose them with data to write programs on PDP-11. I was able to understand what each exact 16-bit word in my program is doing. It was a great skill. But then the same guy taught me FORTRAN 83, and I suddenly understood that writing in opcodes is not exciting anymore, because you can be 10x more productive and suffer less. Now, many years and programming languages later, with my coding skills in LSI-11 opcodes totaly athrophied, I do not regret about loosing that skill at all.
I see no reason to regret that our skills in coding C++/Java/* will decline or athrophy at some point in time. This will mean that we just don't need them anymore.
I think this is a false comparison, and I believe cognitive science will show this to be true over time.
"Now, many years and programming languages later, with my coding skills in LSI-11 opcodes totaly athrophied, I do not regret about loosing that skill at all."
But the cognitive capacities you developed reasoning about opcodes almost certainly made it easier for you to learn FORTRAN and its successors.
LSI-11 opcodes, FORTRAN 83, C++, the lambda calculus, etc are all formal languages that we can reason about logically. It's also the case that we can implement machines (hardware or virtual) that can in practice produce the results that match our logical deductions. This is generally what people mean when they say these languages are "deterministic".
It seems obvious to me that it is more cognitively demanding to reason about formal languages like these, to prove to oneself that a given change in the code will produces the outcomes you intend, than it is to prompt for changes in the code and review it.
The difference between now and then is a grand skill shift (from logic to vibe) and also fear of being replaced by this technology which was never the case before at this scale. You and me, we don't have this fear but many colleagues fear this new tech and also those colleagues who seem to get along with it.
Yes, fully agree with you. Although, I read some stories that in early 60s a lot of people who used to program in opcodes (because there were no higher-level languages, even assemblers were quite new and "untested") were also struggling to accept new reality that was coming with Algol, Fortran, amd Cobol. But given that the absolute number of programmers in the world at that time was quite low nobody paid attention to their fears and pains.
To me, personally, this shift is really enabling and refreshing. I usually have lot's of ideas but did not neither time nor capacity to play with them. Some of them were just impossible to do as a team of one. Now everything is possible! :)
One significant difference is that all programming languages, whether machine code or python, have always been a precise language for describing the desired computation or algorithm. Working with an AI agent means specifying what you want the program to do in English, which is not precise. Unless you write English pseudocode.
(Yes, I know the compiler does wild stuff behind the curtain, but unless you're using -Ofast, the assembly is black-box-equivalent to a naive compilation)
The opening sections including graphs do not match my experience. I think they only apply to certain workflows which can be described as "work we have to do because software has a history of poor integration". I.e. repeating solved problems.
Claude will, when given a task off the beaten track, churn through tokens for a while, then produce a completely incorrect answer. (Most recent anecdote: fixing a barostat in an MD sim)
Specifically: How does Spotify, a music streaming service, improve due to AI agents producing code all night? What is improving or being fixed which needs that much abstract code and problem solving? I am guessing the AI code is just building more messy architecture on top of the messy architecture which is causing so much work to be generated.
What just came to my mind is that the current main selling point of AI, is coder productivity. Some anecdotal experiences from a small agile team:
We had 1 week sprints and our PO had sometimes trouble to prepare enough work for the next sprint. We had 4 week sprints and we often ended up pulling tickets from the next sprint. There was often a mismatch in pace. (Quite funny, the time we had found a balance, management ordered all teams to have the same sprint lengths. They couldn't deal with all the asynchronous, overlapping sprint starts/ends. They choose to forfeit our productivity for theirs.)
So productivity isn't all about coders, it's also about owners / managers / shareholders supplying work. This kind of work is much about communication with several involved parties and researching usecases and features in a very specific context. LLMs can help with parts of it, but at one point there will be a flood of excessive, unverified generic reports and LLMs that again condense them with all the inaccuracies, that managers/owners may drown in a fuzzy mess of LLM bureaucracy. Nuances and importance will get lost in excess.
We often had rather large stories that simply had a small set of bulletpoints, because we already communicated everything in person and they were just reminders for the most important stuff. The importance here is that this reflected the teams agency how we solve things. An LLM can probably not at all provide that currently, as they are always excessive and try to add "helpful" details. They simply cannot pick up social norms and agreements, and prompting them correctly is in my opinion very hard or too time consuming.
LLM assisted coding or vibe coding is all the hype. But I have the feeling that the big realization sets in once all supporting processes are convoluted with AI noise, the peers that used to collaborate are detached and social conflicts and misunderstandings escalate.
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 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 rewritten, or if I'm need a mutex to protect this from a torn read.
While I agree with a lot of what this post says, to play devil's advocate for a moment, It's natural that skills we no longer need should be phased out. We should take this as an opportunity to figure out what new skills we need now.
If you're working on a personal project or trying to learn something new, by all means write the code yourself. That's still the best way to do it. But your life should not necessarily revolve around work, and sometimes there is nothing wrong wih caring more about the end product than the process.
"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!
One of the things I have started to realize whilst building apps using AI is that you get a bit indulgent when it comes to features. So in my toy project I wanted all sorts of quality of life bells-and-whistles. If this were a proper enterprise application there would have a been a review and priortization process where the merits would be weighted against the cost. In this case the cost is tokens, so fraction of FTE cost. So I just type and it builds. Whilst this is satisfying I am getting the unnerving sense its not going to be good for me (or the toy app) in the long run.
Other comments have mentioned upstream delays in deciding what features to build now that teams can deliver faster - but you bring up another issue around downstream “understanding debt”. How can sales and marketing sell this stuff if they don’t even know what everything does? How does customer service support it? Sure you can just slop-together documentation, blogs, etc but what good are all these extra features if end-users don’t know or just don’t care about them?
Prioritisation due to cost of engineering forces you to think hard about what to build (and thus not to build). If that calculation has now radically changed, which it has, then that presents a whole new risk that has not been thought about extensivley yet but I suspect will be. It might be that customers can develop the thing they want (that say not other customer does) themselves through well defined interfaces but then who supports and maintains that code?
> I’m not anti-AI, I like it a lot. I’m addicted to prompting, I get high from it.
I would suggest leaving the keyboard, going outside and getting some real highs. Perhaps also leave behind all your technology and try to experience a non-connected life.
What is the world coming to when folks get a high from prompting a complex algorithm.
Oh well, it probably proves that “human intelligence” isn’t that complex. It seems fairly simple to simulate.
> Developers need the dopamine hit of creation. That’s not a perk, it’s what keeps good engineers engaged, learning, retained, and prevents burnout.
Are developers some kind of special creature? or must they simply learn to deal with the complexity of juggling multiple projects, like every other desk job in 2026.
This expresses so well the concerns I've had as I've increasingly leaned into using Copilot at work.
The mismatch in time horizons between employers and developers will be so vexing.
At any given time, the profit-maximizing strategy for each employer is to have engineers ship features as quickly as possible. For each employee, it is rational to retain and strengthen skills by avoiding some amount of cognitive offloading.
Most insidiously, the temptation of cognitive offloading for the employee aligns with the profit-maximizing strategy of the employer.
Coming at this from the opposite end...I started coding 8 months ago with no experience, so AI assistance isn't replacing skills I had, it's the reason I have any skills at all.
But I've noticed something similar to what you describe. When Claude writes a solution for me, I understand it about 70% of the time. That other 30% used to bother me and I'd dig in. Lately I catch myself just accepting it and moving on. The velocity is addictive but you're right that something is being traded away.
The cost I've started noticing most: I'm worse at holding the full architecture of my own app in my head than I should be 8 months in. I can describe what each piece does but I couldn't rebuild it from scratch without help. Not sure the version of me who learned without AI would have that problem.
Still wouldn't trade the tradeoff = I have a live production app that wouldn't exist otherwise. But it's an honest cost worth naming.
The biggest problem is it’ll teach you bad habits. For example, Claude and gpt love to use fallbacks. They generate code that’ll get a positive result at any cost, even if it’s horrible in efficient. If you don’t have past knowledge you might just think that’s how it is.
Now before someone says that junior devs make the same mistakes, yes, to some extent.
If you don't have the experience you can't provide it with stylistic guidance, or idiomatic patterns or provide examples to direct it.
This leads to the idea that LLMs with existing languages can't really learn new idiomatic patterns.
For new engineers I think new paradigms will emerge that invalidate the need to know the current set of design patterns and idioms. Look at the resurgence of unit tests or the new interests in verification systems.
Models don't learn. They retrain them periodically, but junior engineers learn much faster and constantly improve. If you stop learning, you will only be as good as the model.
I've been coding (software engineering, I guess) for close to 15 years. The models skill set is a comfortable L1 (intern), pushing L2 (junior). They are getting better, but at a snail pace compared to a human learning the same thing.
get the system to build a clean architecture and explain it to you. it will help it to build a better system. a huge part of working with these models for engineering is getting them to create reports. for themselves and of course for us to read and understand. the bottleneck is actually our verification capacity.
I'm not buying this argument - use it or lose it isn't even true in physical sense - sure if you stop working out you lose muscles/strength - but once you start back up the rate of progression is like 5x.
With exercise and cognition alike, the concern is motivational. If you let yourself get out of shape, it can be very difficult to rebuild the habits required to get back into shape. You get drawn into a bad local maximum (e.g. prompting everything, driving everywhere) and find you don't have the energy to get out.
What I don't think people are talking enough about yet, is that AI doesn't invent new ways of doing things -- it just predicts the next word based on the materials it was trained on. That means that if a company lets all its coding be done by AI -- that company will be permanently stuck in, say, 2026 -- while other companies will be continuously improving.
I don't think it is that simple. Innovation can be found on several levels, from the lowest next-token level up to the higher level of new ways of combining things. Surely LLMs can produce code that on the whole does something completely new, even if on a syntactical level it has all been seen before?
We only have a couple dozen letters, still it is possible to write new poetry.
There's another great comment by daxfohl that I saved. The "complacency" at scale worries me [1]
Copied to save you a click:
> I worry about the "brain atrophy" part, as I've felt this too. And not just atrophy, but even moreso I think it's evolving into "complacency".
Like there have been multiple times now where I wanted the code to look a certain way, but it kept pulling back to the way it wanted to do things. Like if I had stated certain design goals recently it would adhere to them, but after a few iterations it would forget again and go back to its original approach, or mix the two, or whatever. Eventually it was easier just to quit fighting it and let it do things the way it wanted.
> What I've seen is that after the initial dopamine rush of being able to do things that would have taken much longer manually, a few iterations of this kind of interaction has slowly led to a disillusionment of the whole project, as AI keeps pushing it in a direction I didn't want.
> I think this is especially true if you're trying to experiment with new approaches to things. LLMs are, by definition, biased by what was in their training data. You can shock them out of it momentarily, whish is awesome for a few rounds, but over time the gravitational pull of what's already in their latent space becomes inescapable. (I picture it as working like a giant Sierpinski triangle).
> I want to say the end result is very akin to doom scrolling. Doom tabbing? It's like, yeah I could be more creative with just a tad more effort, but the AI is already running and the bar to seeing what the AI will do next is so low, so....
I like using AI but I also like writing source code and complex configurations. I've been using it a lot for "give me an example on how to do this" but I'm not a big fan of vibe coding.
It’s worth pointing out that as of February 2026 the costs here are still pretty speculative. We’ve got some small sample studies on developers, and we have some anecdotal transmission of certain skills falling away. But frankly, if these anecdotes and limited data were attached to some statement about Rust, for example, no one would give them any credence whatsoever.
What we’re working with
-—unfortunately—-are vibes. It really seems as though AI coding will have this effect on people. Morally, it seems like it ought to have this effect on people. We should not be allowed to be at ease without some sort of cost. And if we can luridly suggest that you don’t pay with money all the better.
This allows for the piece to perform its function, even when it doesn’t fully commit to it. A work in the genre can say all sorts of nuanced things about agentic coding, while still keeping the core premise that those who resist or position themselves strategically will be the winners.
That’s possible! It’s entirely possible that we will see some skill atrophy that is broken down by AI usage AND materially impacts outcomes that matter. We for sure do not know whether or not that is the case. I suspect it is because we don’t ask what these predictions cost you, which is nothing.
If we look at the starting point for most people on this stuff, it’s basically last fall. The author points this out, but the necessary conclusion one was draw from this is that we don’t have enough information to tell what the cost will be. It may like moving to programming languages from assembly or moving to assembly from bespoke instructions—-fundamentally very little was lost in those transitions, despite there being a lot of carping about it. It could be like the introduction of the tablet in American schools, where what we lose is nearly everything. We really do not know. It might be prudent to be cautious in this situation, but we ought to respect the fact that this caution might be born out of an old paradigm.
I enjoyed the article, though I do have to pick nits with:
> Software used to be deterministic
Ah, someone fortunate enough to have never coded a heisenbug or trip over UB of various causes.
I've written plenty of well structured, well thought out mostly-deterministic software, then spent hours or days figuring what oversight summoned the gremlins.
(There is one low priority bug I've occasionally returned to over the last two-three years in case experience and back-burner musing may result in insight. Nope. Use gcc, no bug, use clang, bug, always, regardless of O level, debug level, etc. Everything else, all of it far more complex, works 100% reliably, it's just that one display update that fails.)
(It occurs to me that that is a bad example, because it IS deterministic, but none of us can pinpoint the "determiner".)
all code is deterministic for a given input. If you don't understand the behavior, it's because you don't understand the complete set of inputs into the system.
Assuming you're not tripping over some hardware defect, it sounds like you're using a gcc hack that llvm doesn't support
One of the most annoying things is senior leadership thinking that these tools give them the ability to just go do things, then the actual engineers are stuck reviewing the massive amount of slop.
Output from AGIs used by experienced engineers tends to be vastly different quality than output from these leaders who are too disconnected from the slaughtering.
I wish we reach a point were we expect (as a matter of online etiquette) upfront disclaimers on predominantly AI-generated articles, so that we can save a few seconds and directly get our agents to read and summarize them.
Even when it's not slop, the verbosity of poorly edited AI-generated content is a micro-agression against readers. The prompter expects readers to read what they couldn't be bothered to properly edit.
Pushing AI-slop code without review, and without explicit warnings is a macro-agression against your colleagues, collaborators, and future agents. You are expecting everybody around you to maintain/ refactor, what you couldn't be botherered to review.
uh...okay. The legend of Faust is the classic work where a person sells his soul to the devil for power/knowledge/pleasure. Goethe has Faust make a wager with the Mephistopheles: show me the good life (pleasure, power, knowledge, whatever) it will never be enough to make me stop striving, to make me want to linger. If you can do that my soul is yours. To me it reads a _lot_ like our contract with AI.
One of my early experiences with AI coding was actually away from the keyboard. I was looking for my keys and just wanted to ask my agent. Very valid use case, but sent dependency chills down my spine. I've been more conscious since and following Sherry Turkle
Currently I am working on a code base that is rapidly evolving for customer fit and is hoped to be around for a while. Going over recent decisions about what abstractions to focus on and what to cut it really seems like LLM tools would have been a waste for any aspect of this work. This is not a situation where some existing process needs to be encoded, and every choice about naming and structure ends up making a big difference as changes trigger refactors.
And this piece focuses on the early adopter point of view. Sure there were problems at first, but then whatsit tool thing version whatever came out and now roses are growing out of the rocks. For a large fraction of what is done with coding that makes sense, but there should always be attention to the rough parts and the gap that forms where capabilities fall off. Even a small amount of modesty can go a long way, but the conversation keeps starting off from every developer, all development, the change is now or else, and I for one am not buying that, especially not with actual money which is what these services will be charging soon in order to pay their trillion dollar debt service.
this article claims humans will review code. there will be a date where the ai code review will meet your SOC compliance policies for change management
It remains unclear to me why my ability to read and review code (the majority of my job for years now) will atrophy if I continue doing it while writing even less code than I was before.
If my ability to write code somehow atrophies because I stop doing it, does that matter if I continue with the architecture and strategy around coding?
The act of writing code by hand seems to be on a trajectory of irrelevance, so as long as I maintain my ability to reason about code (both by continuing to read it and instruct tools to write it), what’s the issue?
Edit to add: the vast majority of the code I’ve worked on in my career was not written by me. A significant portion of it was not written by someone still employed by my employer. I think that’s true for a lot of us, and we all made it work. And we made it work without modern coding assistants helping out. I think we’ll be fine.
> The act of writing code by hand seems to be on a trajectory of irrelevance
It does not. English (or any human language) is an awful language to write specifications in, because it is not as precise as code. Each time you "compile" your prompt into a program, LLMs spit up something a little bit different. How is it a good thing?
> so as long as I maintain my ability to reason about code (both by continuing to read it and instruct tools to write it), what’s the issue?
The post mentions this. You need to write code yourself to keep your review skill (know what's good and what's bad) sharp. You think why if you want to learn something, you better get a paper, a pen and write notes, by hand, like in those ancient times? You would think we're in 2026, you can grab an ipad, watch some videos and become an expert? No. You need to have your hands dirty. By writing some damn code.
> The code is not replaced by English prompts. The code still exists
If you can guarantee that it does what you say it does, then all is ok. The core issue since the advent of ChatGPT was always this reliability issue, whether the end result, the code, addresses the change request issued.
It turned out that you need to be an expert programmer to vet the code as well as supervise its evolution, whatever the tool used to write it.
"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 erosion."
From my own (anecdotal) experience I am seeing a lot more cases of what I call developer bullshit where developers can't even talk about the work they are vibe-coding on in a coherent way. Management doesn't notice this since it's all techno-bable to them and sounds fancy, but other developers do.
This use to be the most embarrassing thing that could happen. A team member asks you why you did something a certain way during a PR and you can't provide an answer. This seems to be becoming the norm now.
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 literally in the study title: "skill formation", not skill practice, maintenance, or deterioration.
I think it's also extremely worth pointing out that when you break down the AI using group by how they actually used AI, those who had the AI both provide code and afterwards provide a summary of the concepts and what it did actually scored among the highest. The same for ones who actually use the AI to ask it questions about the code it generated after it generated that code. Which seems to indicate to me that as long as you're having the AI explain and summarize what it did after each badge of edits. And you're also using it to explore and explain existing code bases. You're not going to see this problem.
I'm so extremely tired of people like you who want to engage in this moral panic completely misinterpreting these studies
Per your last paragraph, I also think we are in an awkward middle period where developers are embarrassed to admit how much code is vibes with very little review before they submit.
The embarrassment is understanding. It feels wrong, because in many ways it is wrong.
The only way I’ve had this feel any better is by using it on a non-critical internal tool. I can confidently say “I didn’t write any of this code because it’s a quality of life tool that only lives on developer manners and is not required at any point in our workflow.”
I also agree with the article that, unless computer science departments maintain some pretty strict discipline, this idea of a seniority collapse could be very real.
Will we need those senior engineers if AI keeps getting better? I don’t know. Maybe one day the AI systems are going to just be trusted to be able to untangle complex architectural problems.
If it wasn’t for leaded gasoline, rudimentary cancer treatment, and a good section of my modern video game catalog. I might be wishing I was born earlier.
Even before AI, I’ve witnessed at Google plenty of L6 and L7 software engineers atrophy. They stop writing code, start reviewing code, until they find that their code reviews catch fewer issues than a junior engineer’s reviews. They have become accustomed to thinking only at a high-level, and when met with low-level details they can’t tell good from bad any more. Their coding skills, both reading and writing, have atrophied.
> Do they also stop providing value to Google as a result?
In the context of a software engineer, yes obviously?
> I don’t get paid to write code, and you probably don’t either.
I feel like you're rejecting the premise of the argument. You're talking about becoming a manager, as if that track is somehow relevant to software engineers. I used to be a nurse, I'm not anymore. My skills have definitely atrophied. I would now be a shitty and dangerous nurse. How does that apply to my skills at software engineering? When you stop being a software engineer, it's expected you skills at interacting with code will fall away. But the article you're arguing against isn't written for nurses, and equally isn't written engineering managers.
This is a wonderfully balanced and accurate take. I have been looking for the right medium of using AI to assist me. Cannot agree more on the three patterns to implement and there to avoid.
If the three good patterns are adhered to, these AI tools can help us become more knowledgeable, productive.
We get to retain our cognitive abilities and the desire to pursue code development as a means to solving hard problems.
Adopting the anti-patterns, on the other hand, could lead to over-reliance on AI, anxiety when the tools go down (this happens! ), the atrophy of ability to debug and the yearning for immediate gratification and quick fixes.
Most insidiously, when code inevitably fails in production on cases the developer should have reasoned about and covered, they have no option but to toss it back to the AI tool, thereby, creating a vicious cycle of anxiety, helplessness and cognitive decay.
Writing code by hand and managing the mental model of its execution and architecture is one of the few remaining joys of my day job, apart from delivering a good product people want and use and being helpful. Even the small things, the tedious chores of refactoring or scaffolding that initial bit of CRUD boilerplate are steps that matter to me. The callouses matter. The tedium matters. These moments of pain and drudgery inform me on what to do differently next time in a way I worry I would not appreciate otherwise, were specific tools thrust upon me.
I remain because I remain hopeful the pendulum will swing the other way someday.
Well said.
I've found that I reach for Copilot most often when working on frontend javascript code. Will the incentive to improve the frontend libraries, browser standards, etc vanish now that LLMs let us avoid some of this pain?
That’s why I laugh when people are like “oh, AI writes all the tests, it’s so much easier.” If your code is hard to test, you need to change the abstraction or the interface. Tests are the first reuse of your code, so if it’s a pain to use in tests, it’s going to be terrible to use in general.
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.
Do you have management pressure to use these tools? I don’t have any data but me and virtually every software engineer I talk to regularly is feeling or has felt pressure to use these tools.
FWIW, I'm responsible for our engineering team, and I'm the one starting to put some gentle pressure on the developers right now. Velocity used to be one of the bigger issues we had: Features used to be in development over weeks, while customers, product management, and engineers iterated on the feature, until it was finally deemed stable enough and shipped. With AI, we can shorten that cycle considerably, and get stuff out of the door in days or even hours instead. Doing so requires adapting your processes accordingly, give up some control over the details, take good care of tests, and do proper code reviews.
Given all that, I just cannot ignore AI as a development tool. There is no good justification I can give the rest of the company for why we would not incorporate AI tools into our workflows, and this also means I cannot leave it up to individual developers on whether they want to use AI or not.
This pains me a lot: On the one hand, it feels irresponsible to the junior developers and their education to let them outsource thinking; on the other hand, we're not a charity fund but a company that needs to make money. Also, many of us (me included) got into this career for the joy of creating. Nobody anticipated this could stop being part of the deal, but here were are.
> There is no good justification I can give the rest of the company for why we would not incorporate AI tools
Is there definitive proof of long term productivity gains with no detriment to defects, future velocity, etc?
If so I’d say you’re irresponsible at best to put this much trust in a tool that’s been around for a few months (at the current level). Absolutely encourage experimentation, but there’s a trillion dollar marketing hype machine in overdrive right now. Your job is to remind people of that.
> it feels irresponsible
And it is. You are going to end up with a wreck of a product and not a single person you can call upon to fix it. It is your choice and you will pay for it.
If programmer speed and efficiency was truly such a significant competitive factor, we wouldn't be packing them like sardines them in noisy and stuffy open floor plan offices.
Real quick, how does paging work?
yup. no effort - no bliss. and for rare bouts of wanting to shepherd cats I just got meself some actual cats. At least they don't pretend to be engineers.
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 love to hear your thoughts
Fun read. Audience can see Xeno's Arrow emerging on your "we're on the way to AGI!" timeline, a nice visual representation of "the trajectory is real, but the timeline keeps slipping."
But I'm gonna say I've always seen "[retail software] is just a tool" as an odd statement. I've heard it a lot over the last 20 years. "Just" a tool. Why always phrased like that? How can we be overthinking the role of a tool while you're in the middle of a multi-page essay about how it causes cognitive decline?
Nobody frets about the effect of a screwdriver on some IT rando's ability to do other computer stuff if on occasion they're screwing something into a rack. Seems odd to be so consistent about privileging the concept of a "tool" when you're saying that tool is on its way to thought.
>I’m addicted to prompting, I get high from it
yikes, but I did appreciate this honesty. Though, again: "this hash pipe is just a tool" did not appear after this statement
Also - isn't addiction behavioral, as opposed to strictly neurological? Maybe you should do a follow-up on the behavioral effects of a situation like "There’s no spark in you anymore." If you found a new identity that wasn't "I'm a prompt addict," what would it be?
Thanks, I like it! Thanks for taking time putting it together.
I’d encourage you to read this post: https://factory.strongdm.ai
It hit the front page here a few weeks ago, but I don’t think most people took it seriously and got hung up on the $1000/day in tokens part.
I am convinced that approach is the future of nearly all software development. It’s basically about how if you’re willing to spend enough tokens, these current models can already complete any software task. With the right framework in place, you don’t need to think about the code at all, only the results.
I really don’t like that the industry is heading this way, but the more I consider that approach, the more I’m convinced it is inevitable.
I started my coding apprenticeship back in early 80s with a senior programmer who taught me to code in LSI-11 processor codes. I memorized the whole table of octal processor opcodes and learned how to compose them with data to write programs on PDP-11. I was able to understand what each exact 16-bit word in my program is doing. It was a great skill. But then the same guy taught me FORTRAN 83, and I suddenly understood that writing in opcodes is not exciting anymore, because you can be 10x more productive and suffer less. Now, many years and programming languages later, with my coding skills in LSI-11 opcodes totaly athrophied, I do not regret about loosing that skill at all.
I see no reason to regret that our skills in coding C++/Java/* will decline or athrophy at some point in time. This will mean that we just don't need them anymore.
I think this is a false comparison, and I believe cognitive science will show this to be true over time.
"Now, many years and programming languages later, with my coding skills in LSI-11 opcodes totaly athrophied, I do not regret about loosing that skill at all."
But the cognitive capacities you developed reasoning about opcodes almost certainly made it easier for you to learn FORTRAN and its successors.
LSI-11 opcodes, FORTRAN 83, C++, the lambda calculus, etc are all formal languages that we can reason about logically. It's also the case that we can implement machines (hardware or virtual) that can in practice produce the results that match our logical deductions. This is generally what people mean when they say these languages are "deterministic".
It seems obvious to me that it is more cognitively demanding to reason about formal languages like these, to prove to oneself that a given change in the code will produces the outcomes you intend, than it is to prompt for changes in the code and review it.
The difference between now and then is a grand skill shift (from logic to vibe) and also fear of being replaced by this technology which was never the case before at this scale. You and me, we don't have this fear but many colleagues fear this new tech and also those colleagues who seem to get along with it.
Yes, fully agree with you. Although, I read some stories that in early 60s a lot of people who used to program in opcodes (because there were no higher-level languages, even assemblers were quite new and "untested") were also struggling to accept new reality that was coming with Algol, Fortran, amd Cobol. But given that the absolute number of programmers in the world at that time was quite low nobody paid attention to their fears and pains.
To me, personally, this shift is really enabling and refreshing. I usually have lot's of ideas but did not neither time nor capacity to play with them. Some of them were just impossible to do as a team of one. Now everything is possible! :)
One significant difference is that all programming languages, whether machine code or python, have always been a precise language for describing the desired computation or algorithm. Working with an AI agent means specifying what you want the program to do in English, which is not precise. Unless you write English pseudocode.
(Yes, I know the compiler does wild stuff behind the curtain, but unless you're using -Ofast, the assembly is black-box-equivalent to a naive compilation)
The opening sections including graphs do not match my experience. I think they only apply to certain workflows which can be described as "work we have to do because software has a history of poor integration". I.e. repeating solved problems.
Claude will, when given a task off the beaten track, churn through tokens for a while, then produce a completely incorrect answer. (Most recent anecdote: fixing a barostat in an MD sim)
Specifically: How does Spotify, a music streaming service, improve due to AI agents producing code all night? What is improving or being fixed which needs that much abstract code and problem solving? I am guessing the AI code is just building more messy architecture on top of the messy architecture which is causing so much work to be generated.
What just came to my mind is that the current main selling point of AI, is coder productivity. Some anecdotal experiences from a small agile team:
We had 1 week sprints and our PO had sometimes trouble to prepare enough work for the next sprint. We had 4 week sprints and we often ended up pulling tickets from the next sprint. There was often a mismatch in pace. (Quite funny, the time we had found a balance, management ordered all teams to have the same sprint lengths. They couldn't deal with all the asynchronous, overlapping sprint starts/ends. They choose to forfeit our productivity for theirs.)
So productivity isn't all about coders, it's also about owners / managers / shareholders supplying work. This kind of work is much about communication with several involved parties and researching usecases and features in a very specific context. LLMs can help with parts of it, but at one point there will be a flood of excessive, unverified generic reports and LLMs that again condense them with all the inaccuracies, that managers/owners may drown in a fuzzy mess of LLM bureaucracy. Nuances and importance will get lost in excess.
We often had rather large stories that simply had a small set of bulletpoints, because we already communicated everything in person and they were just reminders for the most important stuff. The importance here is that this reflected the teams agency how we solve things. An LLM can probably not at all provide that currently, as they are always excessive and try to add "helpful" details. They simply cannot pick up social norms and agreements, and prompting them correctly is in my opinion very hard or too time consuming.
LLM assisted coding or vibe coding is all the hype. But I have the feeling that the big realization sets in once all supporting processes are convoluted with AI noise, the peers that used to collaborate are detached and social conflicts and misunderstandings escalate.
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”
These articles need to stop. It’s joever.
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 rewritten, or if I'm need a mutex to protect this from a torn read.
While I agree with a lot of what this post says, to play devil's advocate for a moment, It's natural that skills we no longer need should be phased out. We should take this as an opportunity to figure out what new skills we need now.
If you're working on a personal project or trying to learn something new, by all means write the code yourself. That's still the best way to do it. But your life should not necessarily revolve around work, and sometimes there is nothing wrong wih caring more about the end product than the process.
"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!
One of the things I have started to realize whilst building apps using AI is that you get a bit indulgent when it comes to features. So in my toy project I wanted all sorts of quality of life bells-and-whistles. If this were a proper enterprise application there would have a been a review and priortization process where the merits would be weighted against the cost. In this case the cost is tokens, so fraction of FTE cost. So I just type and it builds. Whilst this is satisfying I am getting the unnerving sense its not going to be good for me (or the toy app) in the long run.
Other comments have mentioned upstream delays in deciding what features to build now that teams can deliver faster - but you bring up another issue around downstream “understanding debt”. How can sales and marketing sell this stuff if they don’t even know what everything does? How does customer service support it? Sure you can just slop-together documentation, blogs, etc but what good are all these extra features if end-users don’t know or just don’t care about them?
Prioritisation due to cost of engineering forces you to think hard about what to build (and thus not to build). If that calculation has now radically changed, which it has, then that presents a whole new risk that has not been thought about extensivley yet but I suspect will be. It might be that customers can develop the thing they want (that say not other customer does) themselves through well defined interfaces but then who supports and maintains that code?
> I’m not anti-AI, I like it a lot. I’m addicted to prompting, I get high from it.
I would suggest leaving the keyboard, going outside and getting some real highs. Perhaps also leave behind all your technology and try to experience a non-connected life.
What is the world coming to when folks get a high from prompting a complex algorithm.
Oh well, it probably proves that “human intelligence” isn’t that complex. It seems fairly simple to simulate.
> Developers need the dopamine hit of creation. That’s not a perk, it’s what keeps good engineers engaged, learning, retained, and prevents burnout.
Are developers some kind of special creature? or must they simply learn to deal with the complexity of juggling multiple projects, like every other desk job in 2026.
This expresses so well the concerns I've had as I've increasingly leaned into using Copilot at work.
The mismatch in time horizons between employers and developers will be so vexing.
At any given time, the profit-maximizing strategy for each employer is to have engineers ship features as quickly as possible. For each employee, it is rational to retain and strengthen skills by avoiding some amount of cognitive offloading.
Most insidiously, the temptation of cognitive offloading for the employee aligns with the profit-maximizing strategy of the employer.
Coming at this from the opposite end...I started coding 8 months ago with no experience, so AI assistance isn't replacing skills I had, it's the reason I have any skills at all.
But I've noticed something similar to what you describe. When Claude writes a solution for me, I understand it about 70% of the time. That other 30% used to bother me and I'd dig in. Lately I catch myself just accepting it and moving on. The velocity is addictive but you're right that something is being traded away.
The cost I've started noticing most: I'm worse at holding the full architecture of my own app in my head than I should be 8 months in. I can describe what each piece does but I couldn't rebuild it from scratch without help. Not sure the version of me who learned without AI would have that problem.
Still wouldn't trade the tradeoff = I have a live production app that wouldn't exist otherwise. But it's an honest cost worth naming.
The biggest problem is it’ll teach you bad habits. For example, Claude and gpt love to use fallbacks. They generate code that’ll get a positive result at any cost, even if it’s horrible in efficient. If you don’t have past knowledge you might just think that’s how it is.
Now before someone says that junior devs make the same mistakes, yes, to some extent.
If you don't have the experience you can't provide it with stylistic guidance, or idiomatic patterns or provide examples to direct it.
This leads to the idea that LLMs with existing languages can't really learn new idiomatic patterns.
For new engineers I think new paradigms will emerge that invalidate the need to know the current set of design patterns and idioms. Look at the resurgence of unit tests or the new interests in verification systems.
And they love to do this in spite of writing "NO FALLBACKS" etc. in your AGENTS.md.
Models don't learn. They retrain them periodically, but junior engineers learn much faster and constantly improve. If you stop learning, you will only be as good as the model.
I've been coding (software engineering, I guess) for close to 15 years. The models skill set is a comfortable L1 (intern), pushing L2 (junior). They are getting better, but at a snail pace compared to a human learning the same thing.
This was my biggest frustration with LLM based coding but Agent Skills have largely solved it.
While there’s a lot of room to improve them it’s a huge game changer for effectively coding harnesses.
get the system to build a clean architecture and explain it to you. it will help it to build a better system. a huge part of working with these models for engineering is getting them to create reports. for themselves and of course for us to read and understand. the bottleneck is actually our verification capacity.
I'm not buying this argument - use it or lose it isn't even true in physical sense - sure if you stop working out you lose muscles/strength - but once you start back up the rate of progression is like 5x.
With exercise and cognition alike, the concern is motivational. If you let yourself get out of shape, it can be very difficult to rebuild the habits required to get back into shape. You get drawn into a bad local maximum (e.g. prompting everything, driving everywhere) and find you don't have the energy to get out.
It’s like walking vs taking bus or car. It’s nice to walk sometimes..
Actually a pretty good metaphor.
What I don't think people are talking enough about yet, is that AI doesn't invent new ways of doing things -- it just predicts the next word based on the materials it was trained on. That means that if a company lets all its coding be done by AI -- that company will be permanently stuck in, say, 2026 -- while other companies will be continuously improving.
I don't think it is that simple. Innovation can be found on several levels, from the lowest next-token level up to the higher level of new ways of combining things. Surely LLMs can produce code that on the whole does something completely new, even if on a syntactical level it has all been seen before?
We only have a couple dozen letters, still it is possible to write new poetry.
This is actually a big advantage of using AI.
Using simple mature tech stacks following best practices makes your product much better.
Developers have a strong desire to reinvent the wheel and it wastes so much time.
Innovative should only be attempted in your product domain if you are trying to make a successful company.
There's another great comment by daxfohl that I saved. The "complacency" at scale worries me [1]
Copied to save you a click:
> I worry about the "brain atrophy" part, as I've felt this too. And not just atrophy, but even moreso I think it's evolving into "complacency". Like there have been multiple times now where I wanted the code to look a certain way, but it kept pulling back to the way it wanted to do things. Like if I had stated certain design goals recently it would adhere to them, but after a few iterations it would forget again and go back to its original approach, or mix the two, or whatever. Eventually it was easier just to quit fighting it and let it do things the way it wanted.
> What I've seen is that after the initial dopamine rush of being able to do things that would have taken much longer manually, a few iterations of this kind of interaction has slowly led to a disillusionment of the whole project, as AI keeps pushing it in a direction I didn't want.
> I think this is especially true if you're trying to experiment with new approaches to things. LLMs are, by definition, biased by what was in their training data. You can shock them out of it momentarily, whish is awesome for a few rounds, but over time the gravitational pull of what's already in their latent space becomes inescapable. (I picture it as working like a giant Sierpinski triangle).
> I want to say the end result is very akin to doom scrolling. Doom tabbing? It's like, yeah I could be more creative with just a tad more effort, but the AI is already running and the bar to seeing what the AI will do next is so low, so....
[1] https://news.ycombinator.com/item?id=46784594
I like using AI but I also like writing source code and complex configurations. I've been using it a lot for "give me an example on how to do this" but I'm not a big fan of vibe coding.
It’s worth pointing out that as of February 2026 the costs here are still pretty speculative. We’ve got some small sample studies on developers, and we have some anecdotal transmission of certain skills falling away. But frankly, if these anecdotes and limited data were attached to some statement about Rust, for example, no one would give them any credence whatsoever.
What we’re working with -—unfortunately—-are vibes. It really seems as though AI coding will have this effect on people. Morally, it seems like it ought to have this effect on people. We should not be allowed to be at ease without some sort of cost. And if we can luridly suggest that you don’t pay with money all the better.
This allows for the piece to perform its function, even when it doesn’t fully commit to it. A work in the genre can say all sorts of nuanced things about agentic coding, while still keeping the core premise that those who resist or position themselves strategically will be the winners.
That’s possible! It’s entirely possible that we will see some skill atrophy that is broken down by AI usage AND materially impacts outcomes that matter. We for sure do not know whether or not that is the case. I suspect it is because we don’t ask what these predictions cost you, which is nothing.
If we look at the starting point for most people on this stuff, it’s basically last fall. The author points this out, but the necessary conclusion one was draw from this is that we don’t have enough information to tell what the cost will be. It may like moving to programming languages from assembly or moving to assembly from bespoke instructions—-fundamentally very little was lost in those transitions, despite there being a lot of carping about it. It could be like the introduction of the tablet in American schools, where what we lose is nearly everything. We really do not know. It might be prudent to be cautious in this situation, but we ought to respect the fact that this caution might be born out of an old paradigm.
>Every developer I know uses AI for coding now.
And for blogging too, it seems.
I enjoyed the article, though I do have to pick nits with:
> Software used to be deterministic
Ah, someone fortunate enough to have never coded a heisenbug or trip over UB of various causes.
I've written plenty of well structured, well thought out mostly-deterministic software, then spent hours or days figuring what oversight summoned the gremlins.
(There is one low priority bug I've occasionally returned to over the last two-three years in case experience and back-burner musing may result in insight. Nope. Use gcc, no bug, use clang, bug, always, regardless of O level, debug level, etc. Everything else, all of it far more complex, works 100% reliably, it's just that one display update that fails.)
(It occurs to me that that is a bad example, because it IS deterministic, but none of us can pinpoint the "determiner".)
all code is deterministic for a given input. If you don't understand the behavior, it's because you don't understand the complete set of inputs into the system.
Assuming you're not tripping over some hardware defect, it sounds like you're using a gcc hack that llvm doesn't support
for a display update, sounds like memory ordering
One of the most annoying things is senior leadership thinking that these tools give them the ability to just go do things, then the actual engineers are stuck reviewing the massive amount of slop.
Output from AGIs used by experienced engineers tends to be vastly different quality than output from these leaders who are too disconnected from the slaughtering.
I wish we reach a point were we expect (as a matter of online etiquette) upfront disclaimers on predominantly AI-generated articles, so that we can save a few seconds and directly get our agents to read and summarize them.
Even when it's not slop, the verbosity of poorly edited AI-generated content is a micro-agression against readers. The prompter expects readers to read what they couldn't be bothered to properly edit.
Pushing AI-slop code without review, and without explicit warnings is a macro-agression against your colleagues, collaborators, and future agents. You are expecting everybody around you to maintain/ refactor, what you couldn't be botherered to review.
> micro-agression against readers
So basically the same cognitive debt that accrues to engineers the moment they become managers.
So...what does it cost you?
Goethe answered this in Faust. The answer is always: your soul.
Can you be more precise?
If you sell your soul to the devil, don’t expect to make a profit.
I'll take that as a "no".
uh...okay. The legend of Faust is the classic work where a person sells his soul to the devil for power/knowledge/pleasure. Goethe has Faust make a wager with the Mephistopheles: show me the good life (pleasure, power, knowledge, whatever) it will never be enough to make me stop striving, to make me want to linger. If you can do that my soul is yours. To me it reads a _lot_ like our contract with AI.
I don't have a contract with AI.
It was meant metaphorically. It gives you something, but it asks for something in return.
One of my early experiences with AI coding was actually away from the keyboard. I was looking for my keys and just wanted to ask my agent. Very valid use case, but sent dependency chills down my spine. I've been more conscious since and following Sherry Turkle
https://www.npr.org/2025/07/18/g-s1177-78041/what-to-do-when...
Shocking that devs are forgetting that writing and testing code gives us a conceptual map of what the code does...
Almost like someone never ever learned what the core of code development is....
This is why I use zettelkatsen as my own coding AI....long term results are far better than using AI to pretend to code.
> Every developer I know uses AI for coding now.
Currently I am working on a code base that is rapidly evolving for customer fit and is hoped to be around for a while. Going over recent decisions about what abstractions to focus on and what to cut it really seems like LLM tools would have been a waste for any aspect of this work. This is not a situation where some existing process needs to be encoded, and every choice about naming and structure ends up making a big difference as changes trigger refactors.
And this piece focuses on the early adopter point of view. Sure there were problems at first, but then whatsit tool thing version whatever came out and now roses are growing out of the rocks. For a large fraction of what is done with coding that makes sense, but there should always be attention to the rough parts and the gap that forms where capabilities fall off. Even a small amount of modesty can go a long way, but the conversation keeps starting off from every developer, all development, the change is now or else, and I for one am not buying that, especially not with actual money which is what these services will be charging soon in order to pay their trillion dollar debt service.
this article claims humans will review code. there will be a date where the ai code review will meet your SOC compliance policies for change management
It remains unclear to me why my ability to read and review code (the majority of my job for years now) will atrophy if I continue doing it while writing even less code than I was before.
If my ability to write code somehow atrophies because I stop doing it, does that matter if I continue with the architecture and strategy around coding?
The act of writing code by hand seems to be on a trajectory of irrelevance, so as long as I maintain my ability to reason about code (both by continuing to read it and instruct tools to write it), what’s the issue?
Edit to add: the vast majority of the code I’ve worked on in my career was not written by me. A significant portion of it was not written by someone still employed by my employer. I think that’s true for a lot of us, and we all made it work. And we made it work without modern coding assistants helping out. I think we’ll be fine.
> Each time you "compile" your prompt into a program, LLMs spit up something a little bit different. How is it a good thing?
Because that’s not how it works. How can we have a discussion about this topic if we don’t have a mutual understanding of how the tools even work?
The code is not replaced by English prompts. The code still exists.
> The code is not replaced by English prompts. The code still exists
If you can guarantee that it does what you say it does, then all is ok. The core issue since the advent of ChatGPT was always this reliability issue, whether the end result, the code, addresses the change request issued.
It turned out that you need to be an expert programmer to vet the code as well as supervise its evolution, whatever the tool used to write it.
"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 erosion."
From my own (anecdotal) experience I am seeing a lot more cases of what I call developer bullshit where developers can't even talk about the work they are vibe-coding on in a coherent way. Management doesn't notice this since it's all techno-bable to them and sounds fancy, but other developers do.
This use to be the most embarrassing thing that could happen. A team member asks you why you did something a certain way during a PR and you can't provide an answer. This seems to be becoming the norm now.
It also used to be an indicator that potentially someone was outsourcing their work overseas.
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 literally in the study title: "skill formation", not skill practice, maintenance, or deterioration.
I think it's also extremely worth pointing out that when you break down the AI using group by how they actually used AI, those who had the AI both provide code and afterwards provide a summary of the concepts and what it did actually scored among the highest. The same for ones who actually use the AI to ask it questions about the code it generated after it generated that code. Which seems to indicate to me that as long as you're having the AI explain and summarize what it did after each badge of edits. And you're also using it to explore and explain existing code bases. You're not going to see this problem.
I'm so extremely tired of people like you who want to engage in this moral panic completely misinterpreting these studies
Per your last paragraph, I also think we are in an awkward middle period where developers are embarrassed to admit how much code is vibes with very little review before they submit.
The embarrassment is understanding. It feels wrong, because in many ways it is wrong.
The only way I’ve had this feel any better is by using it on a non-critical internal tool. I can confidently say “I didn’t write any of this code because it’s a quality of life tool that only lives on developer manners and is not required at any point in our workflow.”
I also agree with the article that, unless computer science departments maintain some pretty strict discipline, this idea of a seniority collapse could be very real.
Will we need those senior engineers if AI keeps getting better? I don’t know. Maybe one day the AI systems are going to just be trusted to be able to untangle complex architectural problems.
If it wasn’t for leaded gasoline, rudimentary cancer treatment, and a good section of my modern video game catalog. I might be wishing I was born earlier.
Even before AI, I’ve witnessed at Google plenty of L6 and L7 software engineers atrophy. They stop writing code, start reviewing code, until they find that their code reviews catch fewer issues than a junior engineer’s reviews. They have become accustomed to thinking only at a high-level, and when met with low-level details they can’t tell good from bad any more. Their coding skills, both reading and writing, have atrophied.
Do they also stop providing value to Google as a result?
I don’t get paid to write code, and you probably don’t either.
> Do they also stop providing value to Google as a result?
In the context of a software engineer, yes obviously?
> I don’t get paid to write code, and you probably don’t either.
I feel like you're rejecting the premise of the argument. You're talking about becoming a manager, as if that track is somehow relevant to software engineers. I used to be a nurse, I'm not anymore. My skills have definitely atrophied. I would now be a shitty and dangerous nurse. How does that apply to my skills at software engineering? When you stop being a software engineer, it's expected you skills at interacting with code will fall away. But the article you're arguing against isn't written for nurses, and equally isn't written engineering managers.
You are not paid to only write code.