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.
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.
And not to mention that most tests available to AI training is trash, so no wonder AI-generated tests are not only worthless but costly in terms of false sense of reliability.
Completely resonate with this. There don't seem to be many of us, at least in my online bubble, but you're not alone.
I believe and hope eventually we'll come around to valuing people who have put in the work - not just to understand and review output but to make choices themselves and keep their knowledge and judgement sharp - when we fully realize the cost of not doing so.
I value people who put in the work. I also value being able to make a little one-off single use gadget without having to spend a week doing remedial python every few months. I can understand it once it's written but writing it is a separate skill.
Of course, having learned a few languages, understanding data types, knowing to prompt it for idiomatic code and check against best practices, etc is vital to being able to do that. The basic skills need to be developed even if not everyone gets the same value out of being able to write code.
I think throwaway use cases have very different requirements than products we expect to maintain and need to be treated differently. Go nuts with AI to generate a chart or a one off tool or whatever, if you don't care about deepening your skill to do those things yourself.
Wanted to chime in that, at my job, hand-writing code has been massively helpful when debugging it. My mental model of what can go wrong is much easier to form if I wrote the code. A LLM will not always be able to solve these incidents, no matter how many logs you throw at it.
Yes! I love to code. I love the entire process end-to-end. I love doing all the things people say they prefer to hand off to LLMs. Makes me sad to see all the people allowing corporations to slowly rob them of all the little joys this field has to offer.
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?
I wonder if they will improve in a specific direction - frameworks and libraries built to be easier for LLMs to use.
This could even happen through accidental evolution - a framework that is easier on an LLMs context window results in more successful projects, which results in more training data, which results in LLMs being even better at it.
Especially true for junior-mid engineers. The brain stores and comprehends what you tend to repeat.
If I don't solve math problems I won't understand how to solve them, no matter how many times I see videos of people solving similar problems. This is what LLM usage early on will ultimately lead to, and anyone who will claim "oh, by the time I'll be senior the LLM's will be much better than me" only proves my point.
I continue to do all of those things but have Claude do the typing for me, if that makes any sense. I'm directing it on almost a line by line basis, I just am not that interested in doing syntax pushups anymore.
Not the user you're responding to, but I feel like I do something similar
I describe what I want roughly on the level I could still code it by hand, to the level of telling Claude to create specific methods, functions and classes (And reminding it to use them, because models love pointless repetition)
Is it faster?
Sure, being this specific has the added benefit of greatly reduced hallucinations (Still, depends on the model, Gemini is still more prone to want to do more things, even when uncalled for)
I also don't need to fine comb everything, Logic and interaction I'll check, but basic everyday stuff is usually already pretty well explained in the repo and the model usually picks up on it
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?
This post resonates with me. I recognize everything you said except for the metrics part, since my employer luckily doesn't do that.
It's addictive. You're fast, efficient, you feel like you're in control. All while you're slowly losing grip.
I love how nuanced your takes are. The biggest challenge of this new programming paradigm is not to see how you can use it to its fullest extent. It is to find out what a sustainable pace is, both sort and long term.
Thanks for writing this blog. Others are also starting to notice these impacts and writing about them. I believe that it is important for more voices to be heard.
What resonated most for me was the "Finding Your Threshold" section. Your "Developers need the dopamine hit of creation." is memorable. I have also blogged about this phenomenon at https://www.exploravention.com/blogs/soft_arch_agentic_ai/ but I frame it more as how leaders can help the organization arrive at a healthy and sustainable balance between writing and reviewing code.
Hey your write up is good too. I thought the specific application to software architecture apart from software engineering is a valuable contribution, because software architecture is where if the AI tool goes wrong the repercussions have a longer term effect.
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.
My question is always: what are you building? You need to tell the AI what to build. What if it does it in a way that isn't what you want, or makes the buttom blue instead of red, or any number of other decisions?
AI can write the code, but not tell you what code you want it to write. In other words, how long are your specs? Either the LLM decides "whatever" or you have massive amounts of documentation to coordinate.
We still need to decide what to build, and some of the how. That is not automate-able, yet everyone seems to gloss over that bit.
Yes, the LLM writes the specs. In fact that LLM writes everything, and then the humans only flag anything they want changed, other than that it’s completely automated.
Imagine you were working with a very talented software shop. You might tell them your preferences sometimes and some things you want changed, but otherwise they mostly just build the right things the right way. And unlike a real software shop, the LLM system can implement changes incredibly fast.
I have this conversation (or a variation threof) with some friends: I suspect that the vast majority of “mainstream commercial software development” is flat out just cooked. We won’t be writing code, nor debugging it. It’ll will just be people throwing more LLM compute at everything.
Open source, hobbyist and personal projects will probably remain the last bastions of “human in the loop” and human-written code, and I suspect these circles will retract into smaller, tighter circles.
Basically had the same urge to write about this problem, prompted by the exact same comments around mental fatigue this week. Only got to the research stage.
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)
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.
"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.
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.
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.
I've worked places that actively acknowledged they were paying a productivity tax for people to have unexpected encounters, and they'd recover the losses at a higher level.
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.
So you struggled to improve velocity without AI tools, are you worried that using the AI tools as a crutch will just lead to a death spiral of bad code being shipped increasingly faster? I've only ever seen the AI adoption approach work on fully functional teams.
The concern as well is that by forcing the AI onto developers, they eventually throw their hands up and say "well they dont care about code quality anymore, neither should I" and start shipping absolute vibeslop.
> I've only ever seen the AI adoption approach work on fully functional teams.
It's not that the team isn't functioning, it's that it's a pretty diverse team in terms of experience, which means things just used to take a while to finish.
> The concern as well is that by forcing the AI onto developers, they eventually throw their hands up and say "well they dont care about code quality anymore, neither should I" and start shipping absolute vibeslop.
This is IMHO avoidable by emphasising code reviews and automated tooling; my general policy is still that everyone is responsible for what they push, period. So absolute vibeslop isn't what I'm seeing, rather an efficiency miscalculation on which parts should be written by humans and which by the AI.
In my experience the bottleneck was never with writing code. If this is the case how can a developer be expected to increase their output while still being responsible in the same way? Seems like a recipe for burnout.
The vast majority of workplaces have never cared about code quality (with the exception being the actual engineers that write the code). Everyone else has no clue what programmers do, other than, "they write arcane symbols, and our product works, and our business continues to function". They do not know that code can even _have_ quality. It does not help that they only ever have to interact with engineering when something is going _wrong_, which conditions them to associate engineers with stress and failure and angry customers. Nobody ever thinks of engineers when everything is going well. The LLM mandates stem from a combination of mistrust and resentment.
I know, from second hand experience, that long before coding LLMs became a thing, engineers would ship slop when it became clear that their superiors cared about deadlines uber alles (i.e. not shipping slop would be the same thing as quitting, but without the paycheck -- slop code is often a form of quiet quitting).
Most people would _prefer_ to be able to "program" their entire business from a spreadsheet. LLMs have enabled them to get involved, and they cannot understand why engineers reject this "help" (it is for the same reason that a pilot would reject a copilot that thinks he knows how to fly because he played a flight simulator or read Jonathan Livingston Seagull; flight simulators are used in training too, but they are not a substitute for actual piloting experience). This refusal and resistance feeds into the mistrust and resentment. We live in a world where managers and administrators do not understand what they are managing and administrating, nor do they think that this is part of their job description. In the worst cases, they believe their job is to extract compliance from their subordinates.
There is a _lot_ of alpha in being part of a company, where authorities understand how the internals of the business (including software and IT!) _actually_ function. (One engineer told me that clueless yet demanding managers are, for all intents and purposes, unwitting saboteurs, and that the best a company can do about this is get him a job interview at a competitor). In some sense, the economy is just a machine for transferring wealth from those who do not know something essential, to those who do know something essential. This can veer uncomfortably close to exploitation. If we want to avoid crossing that line, we need to cultivate an economy where a lack of understanding is not seen as an _opportunity for profit_, but rather _as an opportunity for illumination_.
Your team is creating code you don't really grok to "get stuff out the door". Guaranteed a month or year from now this is going to bite you in the ass, hard.
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.
A wreck of a product is still better than being out of business by not being able to release fast enough. Unfortunately, the market in general does not reward slow high quality.
Who says that is my view of the importance of quality? My second sentence starts with "unfortunately"...
I'm just recognizing that businesses have challenges to deal with besides quality. Being able to generate revenue is just as important as software quality. And seeing how easily consumers switch to a competing product if it has a few more features, you can't neglect time to market if you want to survive as a company.
Many customers are pretty shallow: "meh, the new version looks just like to old one, nothing has changed" even if under the hood the product has significantly improved.
Yes, market dynamics are a bit of a catch 22: customers looking for the best deal, companies looking to reduce costs to still make profit. Customers always looking for the newest features, companies releasing faster before the product is done.
This is a starker tradeoff, but still the same logic that engineering leaders have used for years to eliminate time for exploration, learning, mentoring, role-switching, and every other activity that makes a better engineer but doesn’t move tickets off the queue. These developers are all going to work somewhere else in a few years, so why should we invest in growing their skills? This isn’t a charity, after all.
I’m sure you’re smarter than that, but a lot of leaders aren’t. And that’s based on the past, when they had an established playbook they could choose to follow, not the situation we’re in now where you have to make it up as you go.
I absolutely see your point there, but I don't have a better answer. It feels like the table stakes for feature development speed have risen all of a sudden, whether we like it or not.
Well, only if the increased speed doesn't result in a quality or staffing time bomb. Which none of us really knows at this point. You could always write code faster if you don't care if it works or is maintainable (and indeed many companies work that way for a while), and you could always put your developers in a pressure cooker until they leave from burnout.
So, you have a duty of care to make a safe workplace, at least in most countries.
Consider what a job with no joy means for the ongoing mental health of your staff, where the main interaction they have all day is with an AI model that the person has to boss around; with little training on norms.
Depression, frustration, nonchalance, isolation, and corner cutting are going to be the likely responses.
So at the same time as you introduce new tooling, introduce the quality controls you would expect for someone utterly checked out of the process, and the human resources policies or prevention to avoid your team speed running Godwin's law because they dont deal with people enough to remember social niceties are important.
Examples off of the top of my head of ways to do this are:
- Increased socialisation in the design processes. Mandatory fun sucks, a whiteboard party and collaboration will bring some creativity and shared ownership.
- Budget for AI minimal or free periods, where the intent is to do a chunk of work "the hard way"; and have people share what they experienced or learnt
- Make people test each other's work (manual testing) or collaborate, otherwise you will have a dysfunctional team who reaches for "yell in all caps to make sure the prompt sticks" as the way people talk to each other/deal with conflict.
The way to justify this to management above you is the cost of staff retention - advertise, interview, hire, pay market rates, equip, train, followed 6 months later by securely off boarding, hardware return, exit interview means you get maybe 4 months productivity out of each person, and pay 2 months salary in all of the early job mistakes or late job not caring, or HR debacle.
Do you or your next level up want to spend 30% more time doing this process? Or would you rather focus on generating revenue with a team that works well together and are on board for the long term?
The answer most of the time is "we want to make money, not spend it". So do the math on what staff replacement costs are and then argue for building in enough slack to the process that it costs about half of that to maintain it/train the staff/etc.
Your company is now making a "50% efficiency gain" in the HR funnel, year over year, all by simply... not turning the dial up to 10 on forced AI usage.
I'm applying gentle pressure, not forcing everyone to use it. If necessary, I will fight for my team as much as I can, but that's not where we're headed and I would think about switching jobs if it ever is.
Having said that: The dichotomy expressed in the threads here is a bit too extreme for my taste. It's not like working with AI is pure Yes-clicking review dread; there is joy to be found in materialising your ideas out of thin air, instead of the Lego-like puzzle solving experience many developers are used to.
And as mentioned in TFA, There's risk in both using it too little and too much. This also applies to employees, of course: If I shielded junior developers from AI tools, they'd end up in their next job utterly unprepared for what may be required from them as the world keeps spinning.
> Framed like that, sounds a lot better doesn't it?
Sure does, but that's not the situation I'm in. I'm trying to figure out the local maximum of keeping my company afloat in a world where AI has kicked the PMF from under our feet to the other end of the playing field, and ensuring my team stays happy, curious, and engaged. And I'm not the only one in this spot, I suppose.
> It's not like working with AI is pure Yes-clicking review dread; there is joy to be found in materialising your ideas out of thin air
I think that's true for some developers, and not for others. My guess is that one subset of developers has more ideas than they have time/resources to implement, and they enjoy programming because they love seeing the finished product emerge. I think this subset is more likely to go into management, because it's a force multiplier for them. They're the ones getting joy out of seeing AI make their ideas into reality.
But there's another subset who enjoys programming not because they love to see a product emerge, but because they enjoy the process itself: the head-scratching, the getting past "why won't this work" to the moment when the build starts working again or the site comes back up or the UI snaps into place. It's the magic of finding, among all the possible wrong answers, the exact right combination of bits that solve the problem. This subset is not getting any joy from AI: they're seeing AI take away that whole process and turn it into the kind of work their managers and their project owners do. It's made even worse because their managers don't even understand why they're so unhappy. I think managers would do well to consider how they're going to keep these folks happy and engaged and productive, because they're the ones who are going to be fixing the production bugs introduced by their teammates' AI commits. If they've all gone off to retrain as electricians, we're going to have a problem as an industry.
You are feeling that pressure because the people that use them are more productive and the next pressure you are going to get is to remove yourself from the loop completely.
I personally do not. But I don't work in the software industry. I write custom software in an industry that's as far away from tech as you can imagine. My management tells me what features they want, and doesn't care how it gets done. They only care that it works, and the priority is never to get a feature out fast. The priority is to never break their logistics software that's used 24/7. The deployment cycle is still fast, but bugs can be catastrophic, and it's on me to fix any bugs that crop up whenever something goes into production. Usually, when a bug filters up to me, it's within a few hours, because edge cases arise quickly. I know almost immediately what lines of code in which files are the most likely culprits. Because I wrote them, and I tested them manually, and I thought long and hard before hitting the button. If someone else (or something else) wrote them, I'd have to go hunting at the exact moment when time is critical and there's an open bug in a live deployment, and my phone is ringing and people are yelling.
The term "vibe coding" is new, but I've described what I do as "jazz coding" for a couple decades.
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.
Am I alone in thinking atrophy might not happen? I use a keyboard all day but it doesn't mean I can't write by hand anymore. Predictive text didn't make me forget how to spell. If i buy coffee it doesn't mean I forget how to make it
Counterpoint: my handwriting is way harder to read and my hand tired faster than when I was in high school. And I am worse at spelling and my vocabulary has stopped expanding much since I started typing more and reading less
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.
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 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! :)
When you let compiler generate code for you, you're not a real programmer... That's what opcode coders was ranting in early 60s about FORTRAN programmers.
Product managers can't produce viable programs ready to be deployed in production (yet). But maybe the will able to do it in the future. We don't know how far or close this future is. But I don't think it's not a bad idea in general.
The assumption behind the discussion is that they will be able to produce viable programs. And if you’re letting the LLM own the code, that’s what your job function will be: product manager.
Fair. But I'd change a title a bit to Product Engineer or System Designer. Still a lot of engineering judgement is/will be required to deliver production-ready systems.
I recently accepted-ish a position at a very ai-forward company. Manual programming was somewhat discouraged entirely.
I've used AI tools in the past for maths I didn't understand or errors I couldn't make sense of, and wrote the bulk myself, but now we have as mentioned, opus/sonnet 4.5- which work great.
As part of this, I had to integrate two new apis- nornally, when I write an API wrapper I end up learning a lot about how the API feels, what leads to what and how it smells, etc. This time? I just asked Claude to read it's docs, then gave suggestions about how I wanted it to be laid out. As a result? I have no idea how these apis feel, their models, etc. If I want to interact with them, I ask Claude how I do a thing with the library it made.
Mind you, the library is good. I looked over everything, it's fairly thin and it's exactly how I would write it, as I suggested it do. But I have no deep understanding, much less an understanding of how it got integrated in.
Like, normally when I integrate something in I learn a bit about the codebase I'm integrating it into. Do that enough times, and I understand the codebase at depth, how things plug in. This time? Nada.
It's.... Deeply uncomfortable, to know so little but still be able to do so much. It doesn't matter if I get it to explain it, that's just information that washes off when I move onto the next thing. The reflexive memory isn't built.
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.
I have a few parallel AI-authored side projects on the go that have quite different shapes, and I feel quite different things about each
1. A survival horde game (like Vampire Survivors and Brotato). At the moment it's very primitive, very derivative (no new ideas) and not much fun. I have no sense of pride over it, but it is much further along than it would be if i'd been writing it from scratch. I expect once I invest in the fun side (gameplay innovations, graphics) i'll feel a greater sense of attachment, and I plan to do all the art assets myself.
2. A MacOS web app for managing dev env processes, works but is ugly. I don't have confidence in AI making a remotely presentable UI, so I'll be doing that part myself.
3. A useful little utility library. The kind of thing that pre-LLM would've been too far out of my expertise to be motivated to try making. I'm steering the design of it quite heavily, but haven't written any code. It seems like it's already capable of doing very useful things, and I oddly feel quite proud of it. But I have a weird sense of unease in that I _think_ it's good, but I don't _know_ it's good.
I think the main thing I'm learning is to make sure there's always something of yourself in whatever you produce with the help of AI, especially if you want to feel a sense of accomplishment. And make sure you have a good testing philosophy if you're planning to be hands-off with the code itself.
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.
It seems to do this kind of stuff more when you're not looking too. Like I'll be approving edits all day without any problem then the second I set it to auto it gets a lint error about dead code and adds a pragma to allow the dead code instead of removing it, etc.
> They generate code that’ll get a positive result at any cost, even if it’s horrible in efficient.
If only efficiency is the only problem with that. Sometimes an error state should an error. This is the equivalent of eating all exceptions and pretending all is fine. It just means nothing works.
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.
Claude Code has a “learning mode” that makes it explain what it’s doing and leave “TODO(human)” placeholders in the code where you have to do part of it.
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 spend a lot of time side by side with other devs watching them code and providing guidance. A trend I'm starting to sense is that developer velocity is just as much hindered by unfamiliarity with their tools as much as it is wrestling with the core problem they really want to solve.
When to use your mouse, when to use your keyboard, how to locate a file you want to look at in your terminal or IDE, how to find commands you executed last week, etc. It's all lacking. When devs struggle with these fundamentals, I suspect the desire to bypass all this with a singular "just ask the LLM" interface increases.
So when orgs focus on a "devs should use LLMs more to accelerate", I really wish the focus was more "find ways to accelerate", which could more reliably mean "get more proficient with your tools".
I think there's a lot of good that can be gained from formalizing conventions with templating engines (another tool worth learning), rather than relying on stochastic template generation.
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 think Mitchell Hashimoto as a pretty sane take here, where he uses LLM's to offload stuff he doesn't care about / want to think about so he can spend more time and brain power on the stuff that really matters. I tend to agree.
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.
One specific example that comes to mind is developer tooling in the form of bash scripts. Sure, I can write it myself, but I do this so infrequently that there is a cost for the context switch and ramp up. This, and similar dev ex things that have been languishing in the “one day” pile because there is always the next feature to build. I can now spend 10 minutes here and there to ship incremental QoL improvements alongside my core work.
You don't have a scripting language in your toolbox that you're comfortable with?
I would probably say a shell is "the correct tool for the job" but other than the appeal to authority, or appeal to tradition. There's not a great argument for a shell script over a language you're already comfortable with.
There are hundreds of examples that are easier or faster in python than shell.
Engineers are bad at making tooling, we're even worse making ephemeral tooling we're willing to throw away. Contrasted with other makers, you have machinests who gladly make a one off tool to make a single process easier.
The more 'correct way' than a shell script, is something simple and composable. A large unwieldy shell script that you can't make simple changes in, is terrible design, and it's a mistake to allow that inertia to gain speed.
It's not exactly a complete refutation but something I've been thinking about recently.
I'm not disagreeing with your point. A good understanding of the domain and relevant systems is quite crucial. My point is that you don't always need to inspect the code at such low-level detail, provided there are tests or other ways to prove that the code behaves in the way that you describe.
> My point is that you don't always need to inspect the code at such low-level detail, provided there are tests or other ways to prove that the code behaves in the way that you describe.
This is true *only* in isolation. The pain of going through said depth of detail, is what builds the intuition for the whole system. Once and twice may not be noticeable, but a new habit, and that new habit's corresponding extreme downtime because no one understands the quirks anymore... Despite a few engineers who stake their life on the testing system, tests can't catch all issues. And it's extremely difficult to stop an oil tanker.
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.
In other engineering fields, no one calculates the numbers for building a plane or a dam by hand anymore. They rely heavily on software for design, simulations, etc. throughout the entire development cycle. Yet, starting in university, those engineers still learn to do those calculations by hand so they comprehend the underlying principles.
IMO, that’s what we should do as software engineers. The idea of letting AI "do the thinking" for you is a bad idea. Sure, it can trivially write a sort function for you. Let it! But you still need to understand how that sort function works. If having the tool was a substitute for understanding the fundamentals, anyone with access to Catia, etc. could design a working airplane.
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.
I was recently analyzing a TypeScript module in our new project to learn how it works, and was thinking, "I wouldn't have done it like this” and “the styling is not for me". Then the realization slapped me in my face: this code came from me!
This article also slapped me, and has crystallized my jumbled thoughts on the topic. I'm deep into my career as a productive software engineer, yet I'm concerned there is a visible vanishing point of my value. My retirement is also visible, but I'm more concerned about our trade and those of you who have many years ahead.
While adaptation is hard when moving a lightspeed, workflows must adapt, more time on imprinting the generated code into our heads with iterating on trialing, testing, editing, before PRs is prudent.
A larger problem is architectural drift and leak. Those feel like they could become extremely problematic. We’ll need to put more effort into steering agents so their output aligns with architectural goals. The steering will also need to be iteratively refined.
Great article! I’m concerned, but also rallying for us.
really good piece, sums up almost exactly where I'm at with AI currently.
cognitive debt is a real problem in my domain (embedded software) because AI simply can’t debug the symptom when the reasons for the bug aren’t in code, and a stack trace may not exist. finding the REALLY hard bugs requires in depth systems understanding and the ability to connect things you’ve seen around the codebase together - and the fix usually isn’t adding code, which means the patchwork fixes Claude likes to do only makes things worse.
that said, it’s made writing harnesses and supporting tools WAY easier and faster, and my workflow is better for it. Searching the git history for the why of things is also made way easier; helping me to reason more effectively
In the section about Cognitive Debt the author wrote...
Apply this directly to fully agentic coding. If you stop writing code and only review AI output, your ability to reason about code atrophies. Slowly, invisibly, but inevitably. You can’t deeply review what you can no longer deeply understand.
I think this argument is flawed. On every team I've worked with we've always had the opinion that junior developers learn a lot about coding by reading and reviewing code written by other people, especially people more senior to them. Reviewing output doesn't weaken your skills, it improves them. Reviewing code in a large codebase forces you to explore and understand the paths that data takes. It pushes you to build an accurate mental model more than writing new code does, because that's usually isolated to a small, encapsulated domain where you only really need to care about the inputs and outputs (hopefully!).
The author is absolutely correct if you take 'review' to be 'click the accept button and move on', but if you're actually reviewing the code that your AI generates, and understanding it, and thinking about how to move forwards and prompt it to build the thing you really want, then AI only really removes the last type-the-code step. All of the architecture and process steps should be coming from you (maybe from a conversation with the AI during the planning step, but still, not just letting the AI do whatever it fancies.)
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.
The problem is this is the difference between one or two obscure skills fading away with disuse (normal); and potentially all ability to load programming information into your working memory being affected; as you didn't develop the neural pathways or knowledge of the codebase (not normal or desirable)
While it is a spectrum around when you choose to use AI, what seems increasingly common in my experience is some people trying to go "all in", feel frustration and burnout when they are relegated to babysitting an LLM; get angry that it has made a mistake, misinterpretation or simply left something obvious out; then thinking it's user error/they didn't prompt well enough/it is their fault. At the same time, they are increasingly cognitively blind to mistakes at a review stage, so they find out the hard way in production and enter into a cycle of hyper vigilance/distrust/justifiable paranoia.
In those cases, it's a recipe for skills loss and depression over the long term and a vicious cycle.
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
The debugging gap in the Shen-Tamkin study is the part that worries me. AI tools are great at generating code from a clear spec. But the skill that atrophies is recognizing when code is subtly wrong — and that's the exact skill you need most when reviewing AI output.
What works for me: write the spec in a markdown file before handing it to the agent. Predict what it'll produce before reading the output. When it surprises you, figure out why before accepting. Keeps you engaged enough to actually build mental models.
The management pressure angle in this thread is real. If your org measures velocity in lines shipped, AI tools will optimize for that metric and comprehension dies quietly.
I think for AI to become useful while minimizing it's harm, the interface as a whole needs to be reworked. Instead of having a loop of code generation followed by review. The initiative should be taken by the developer, AI should be a background thing, not one that's surfacing itself to the developer.
For instance I was thinking of AI coding where the developer is writing the application interface, files, design, and the AI in the background is reading them and translating them to the programming language of choice.
This way the developer is writing the whole thing out by hand, it would be as if one is writing fluid pseudo code, but the abstractions would be there, the way they are interacting with each other is there, the human is thinking if the abstractions and when to use them. Whereas the AI is out of the view, simply translating the fluid pseudo code to a rigid programming language.
Perhaps the above isn't really it, but I strongly feel something needs to change in the way we currently work, because it really creates a chasm between the developer and the outputted code not only in terms of the actual implementation but the mental abstractions it's supposed to reflect
I often come back to a quote from Tony Hoare (paraphrased):
There are two ways to write software: either it obviously has no errors or there are no obvious errors in it.
LLMs tend to generate the latter. Because that’s what’s in the training data: all the code that was rushed to production with a promise it would be fixed later. And humans are notoriously bad at catching these kinds of errors.
It feels bad using tools like this because it turns you into a reverse centaur. You’re there because the tool cannot be held accountable. You’re the last mile delivery driver shipping the code. You didn’t participate in its construction and you take all the responsibility for it.
Only there are studies which demonstrate how small of an impact code review has on code quality. And that after reading a few hundred lines of code in an hour the effect disappears. Current AI processes aren’t equipped to handle this.
Whatever we’re doing it’s heading in the opposite direction of engineering.
> 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.
We sysadmins have been seeing this for decades with docker, k8s and cloud adoption. None of the engineers I work with are able to debug a simple networking issue or compile a trivial piece of c code.
Otoh: didn't Socrates say the same about writing? It rots the brain?
I’d argue it’s more like driving yourself vs passively being driven everywhere. Remember that scene at the end of E.T.? Where Elliott and his brother steal the van, but they don’t know how to get to their destination because “I don’t know streets mom always drives!”. LLMs are mom always driving - you might recognize some landmarks after a while, but you don’t know the names of the streets to get anywhere.
Should we seek the dopamine reward of creativity in writing code?
Isn't delivering the value created through the developed results to users itself a creative act?
Will the ability to review code (which is important now) become important in the future?
Is it necessary to have a pipeline to nurture seniors?
Wouldn't it be more important to define clear requirements, verify that the resulting code operates properly within various guardrails, and clearly communicate the designed value, than to be able to review code?
> Reviewing AI output all day without the dopamine of creation is not a sustainable job description.
I agree that reducing engineers’ careers to code review will lead to burnout (amongst other problems).
But I think the reason we’re headed in this direction is precisely because creating with AI /can/ deliver “the dopamine of creation”.
It doesn’t deliver that hit for everyone - but it does for the half of engineers who are more excited about building new things than the act of coding.
Teams build more and ship faster because it’s so much easier to do that with AI - and it’s fun - and that leads to increased review load.
Your writeup accurately captures the big concerns I have about using AI coding tools. One extra thing I have noticed around this is I have a similar feeling about driving and self driving. I really love driving but since I was able to better arrange my life and no longer am a commuter driver I don't get as much daily practice so now when I do take the occasional long drive I don't have as much skill and expertise. It is the same with AI coding tools, I need to put them down from time to time and exercise my mental sharpness to prevent losing my abilities to be a senior engineer.
> Refusing to use AI out of principle is as irrational as adopting it out of hype.
My principles have nothing to do with whether or not AI is giving me extra productivity though. Even if AI made me 5000x more productive I still wouldn't want to use it out of principle. I think it is a deeply immoral technology that shouldn't exist
I also think that people who research and build AI are deeply immoral people who should be tried for crimes against humanity
Because I have no doubt in my mind that AI is leading us towards crimes against humanity. We are going to be culled the moment we are not useful anymore.
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 think you could probably identify different "risks" and then just code in such a way as to mitigate them; I don't personally think there would have to be much of a risk of atrophy of skills if this is done.
I guess it reminds me of someone switching from a manual labor job to a desk job: you become at risk of physical issues from being more sedentary, but you can exercise after work or even some people have things like standing desks and such to keep active during the job
So there can be real risks but there should be ways to manage them
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.
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.
> "You don’t learn to recognize good code by reading about it in a textbook, or a PR. You learn by writing bad code, getting it torn apart, and building intuition through years of practice."
I'd like to point out though, that you also learn by AI producing bad outcomes you are responsible for, and building intuition how it might fail through practice... You also might experience more lessons than you would have if you would have coded manually.
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 wonder whether there's a relevant analogy between human languages and computer languages.
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.
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.
It's currently unclear what the long-term effects of offloading coding to AI will be for developers, and posts like this are not meaningful, as they have zero data to work with. I suppose they feel good to write if you're the type who thinks that a theory with zero data is as good as one with data.
> 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.
I think what’s interesting is technical debt is contained in a project, but cognitive debt is contained in a person. I think we will see good developers pile up so much cognitive debt they will nuke their own careers.
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.
I meant in the physical sense of muscles/physical adaptations. I haven't read/written C++ in 10 years - it would take me a month to get back up to speed. If you never written C++ it would take you at least 6 months/year to get to the same level (depending on what we're comparing here).
Likewise for physical exercise - it took me a year to hit 100kg squat when I started getting into shape 10 years ago. I haven't been very physically active for years but I'd hit 100x5 in a month of starting gym again.
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.
The challenge is that the competitive and economic pressures make this moot.
A person, entering the field via AI driven development, will have none of the qualms about skill, seniority, understanding the codebase, or craftsmanship. Those arguments are handwringing by the previous generation of engineers. Their focus is solely on the outcome and value produced from the input prompt. That aligns closer to how businesses see their codebase: something they have to prompt their engineers to produce in order to generate business value.
Similarly, new AI driven companies focused on delivering value at speed and lower costs will have none of the baggage of the legacy code companies with engineers stuck debating these questions. These new gen companies will be focused on delivering value, doing so at quicker speeds and lower costs, raising the level of competition for existing incumbents.
Will existing businesses be willing to spend money to purchase services from these new gen companies of AI developed products? Seems like it.
There are real problems with these AI developed codebases. They tend to collect baggage and start to feel like a house of cards. A big open question is whether AI models will continue to improve in order to patch all the vibe-holes being generated. Seems like they will improve.
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.
"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!
We can argue about percentage points and months here and there, but we're very quickly coming to 100% and people aren't even afraid to admit it publicly anymore. The prophecy was definitely on point.
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....
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.
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 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
Re determinism: that's what we'd like to believe, but it's true only if we redefine input to include overall build and execution context, and the latter is generally unreproducible. Over the last few years I've seen plenty of subtle bugs, some caused by UB, some caused by interactions with the overall execution environment, that resulted in mostly correct but sometimes wild and haphazard results, all for the same "input".
Once these bugs were fixed, things became deterministic, but to say that all software is deterministic is to assert some level of programming, build, and operational consistency that is often achievable with great effort.
Re gcc hacks: nope. No gcc'isms anywhere in the code, all warnings enabled, no warnings produced, just one case where a field is not updated in one very specific set of circumstances. Thanks for the suggestion, but that was one of the first things we thought of. There is a slight chance that it is actually a clang/llvm call stack depth bug, but the effort to reproduce that outweighs the impact of the bug, what with one thing and another not relevant here.
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.
Until a majority of software engineers become unemployed, we won't collectively wake up and act which is what we should to this existential crisis unfolding. Action more than yet another plausible sounding article.
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’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.
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.
"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.
Edit: I had an instance once where about once a month another developer would ask me about workplace setup, mentioned it to someone and was told maybe they were the English speaker of the group. Upon further investigation, that seemed to be the case.
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.
What happens when more and more people cannot explain their PRs ? I mean they already use AI to create the "explanation" as well and ping you. Ask them questions and they will delegate again to AI and copy-paste what the AI answers.
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
Point taken. Still, isn’t an activity like learning a new library, language, or platform a fundamental part of being a software developer? Haven’t we all complained at some point about companies hiring react developers because we all know the real skill is the ability to pick up new things. And to be clear, this isn’t moral panic, it’s a concern that we may end up in a future where people don’t know how systems work anymore and we are dependent on two or three companies and their data center moats to maintain any technology.
> Still, isn’t an activity like learning a new library, language, or platform a fundamental part of being a software developer?
Yeah, this is fair. However, I think the same study indicates a way out of this dilemma. I feel like I've actually learned a lot about the languages and libraries I've used that I haven't known before through agent coding just by watching it do things and having explained and summarized things to me and find documentation and so on.
> And to be clear, this isn’t moral panic, it’s a concern that we may end up in a future where people don’t know how systems work anymore and we are dependent on two or three companies and their data center moats to maintain any technology.
I don't think this concern in itself constitutes a moral panic, no. I think it's a reasonable thing to think about and worry about how to avoid. However, I think there are definitely very prominent features of the general discourse and concern around this that do constitute a moral panic:
1. First of all, and most importantly, this issue is very often moralized, around like having done a proper amount of work or suffered enough or whatever to be like justified in getting the results you're getting or participating or being considered a real program or whatever. This moralization has existed in the community for a really long time, treating programmers that work at a higher abstraction level than you as lesser than or whatever, so I would argue this isn't a natural response to these concerns so much as it is an extension of a moralistic attitude to a new topic and it's also not necessary to have in order to have these discussions.
2. The hyperbolic misinterpretation of studies, and the fact that these concerns are being raised as if they are going to be a certain, and huge, consequence when we just have very little evidence so far to that effect.
3. The fact that most of the discussion isn't about how to use these tools in a way that doesn't face these problems or whatever, but instead a sort of binary framing around either you suffer from this problem or you boycott.
4. The way the idea of "cognitive debt" and these other things is used to frame it as anyone using AI has their brains "turned to mush" or whatever, as if it's some kind of like general debilitating cognitive injury inside of just that you're getting rusty at skills because you aren't using them, even using scaremongering terms like skill atrophy, which is then used to preemptively dismiss the thoughts of anyone, the people most concerned about this disagree with.
I also think like... If the argument is that people get good at what they do a lot and to get rusty at what they don't do, I really don't see the argument for why using AI a lot wouldn't make you better at high level architectural decisions spotting possible problems with architectures and approaches before they become a problem organizing your thoughts and tasks, reading a code and spotting issues, etc.
The thing is that using coding agents doesn't actually hide whether an algorithm isn't performant enough from you. It'll either be slow or it won't be.
It doesn't hide if you've come up with a bad architecture, because that will also confuse the agent and make it difficult for it to make future modifications without breaking other things.
It doesn't hide a lack of DRY either because if you've got the same code in multiple places and you want to change how it behaves then you've got to change it in multiple places and they can get out of sync and that will bite you in the ass.
And then there's the fact that with coding agents, there's an obvious and direct reward for using more tests and more advanced testing, better linters, more compiled and typed languages, better CI/CD, better documentation, etc. So people will probably get better at that.
> 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.
Yes, it exists, but are you going to edit it by hand if you didn't write it in the first place, or you would rather throw another prompt to update it? People tend to do the latter, thinking about the code as some generated artifact, like object files.
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 your 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.
How do we maintain best practices when the compiler outputs a different result for the spec at any given time? How do we obtain reproducible builds? Do we pin to a specific version of our compiler (ie, snapshot of the model; is this possible anywhere except local currently?), and vigorously test changes after any updates in our "toolchain"? How do we have control over our "toolchain" (again, apart from local), especially when said "toolchain" can, for all its users simultaneously, fold to political pressure from state regimes? And, if the code generated by LLMs is the build artifact, why is it now okay to check the build artifact into source control?
There may come a day when we, as an industry, decide that simply doing it by hand is more expedient when it comes to resolving urgent production issues. We may not know the pain we are causing ourselves until well into the future when it has become too much to bear without a visit to the proverbial doctor.
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.
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.
This is why I teach TDD when I'm teaching agent use to my clients.
Not to mention that tests are at least as critical to get right as the code that is being tested.
And not to mention that most tests available to AI training is trash, so no wonder AI-generated tests are not only worthless but costly in terms of false sense of reliability.
Completely resonate with this. There don't seem to be many of us, at least in my online bubble, but you're not alone.
I believe and hope eventually we'll come around to valuing people who have put in the work - not just to understand and review output but to make choices themselves and keep their knowledge and judgement sharp - when we fully realize the cost of not doing so.
I value people who put in the work. I also value being able to make a little one-off single use gadget without having to spend a week doing remedial python every few months. I can understand it once it's written but writing it is a separate skill.
Of course, having learned a few languages, understanding data types, knowing to prompt it for idiomatic code and check against best practices, etc is vital to being able to do that. The basic skills need to be developed even if not everyone gets the same value out of being able to write code.
I think throwaway use cases have very different requirements than products we expect to maintain and need to be treated differently. Go nuts with AI to generate a chart or a one off tool or whatever, if you don't care about deepening your skill to do those things yourself.
Wanted to chime in that, at my job, hand-writing code has been massively helpful when debugging it. My mental model of what can go wrong is much easier to form if I wrote the code. A LLM will not always be able to solve these incidents, no matter how many logs you throw at it.
Yes! I love to code. I love the entire process end-to-end. I love doing all the things people say they prefer to hand off to LLMs. Makes me sad to see all the people allowing corporations to slowly rob them of all the little joys this field has to offer.
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?
I wonder if they will improve in a specific direction - frameworks and libraries built to be easier for LLMs to use.
This could even happen through accidental evolution - a framework that is easier on an LLMs context window results in more successful projects, which results in more training data, which results in LLMs being even better at it.
Especially true for junior-mid engineers. The brain stores and comprehends what you tend to repeat.
If I don't solve math problems I won't understand how to solve them, no matter how many times I see videos of people solving similar problems. This is what LLM usage early on will ultimately lead to, and anyone who will claim "oh, by the time I'll be senior the LLM's will be much better than me" only proves my point.
I continue to do all of those things but have Claude do the typing for me, if that makes any sense. I'm directing it on almost a line by line basis, I just am not that interested in doing syntax pushups anymore.
Can you describe a bit more how this works? I suppose the speed remains about the same, while the experience is more pleasant?
(Big fan of SQLAlchemy)
Not the user you're responding to, but I feel like I do something similar
I describe what I want roughly on the level I could still code it by hand, to the level of telling Claude to create specific methods, functions and classes (And reminding it to use them, because models love pointless repetition)
Is it faster? Sure, being this specific has the added benefit of greatly reduced hallucinations (Still, depends on the model, Gemini is still more prone to want to do more things, even when uncalled for)
I also don't need to fine comb everything, Logic and interaction I'll check, but basic everyday stuff is usually already pretty well explained in the repo and the model usually picks up on it
I love your take <3
I mean at least now I have the option to spend time on code problems I enjoy.
Did I ever feel joy from trying to figure out the api of an obscure plotting library? No. And thankfully I never have to do it again.
>The callouses matter. The tedium matters.
Yeah nicely said.
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?
didn't even take 24 hours: https://news.ycombinator.com/item?id=47190947
This post resonates with me. I recognize everything you said except for the metrics part, since my employer luckily doesn't do that.
It's addictive. You're fast, efficient, you feel like you're in control. All while you're slowly losing grip.
I love how nuanced your takes are. The biggest challenge of this new programming paradigm is not to see how you can use it to its fullest extent. It is to find out what a sustainable pace is, both sort and long term.
It is hard to understate how difficult that is.
Thanks for writing this blog. Others are also starting to notice these impacts and writing about them. I believe that it is important for more voices to be heard.
What resonated most for me was the "Finding Your Threshold" section. Your "Developers need the dopamine hit of creation." is memorable. I have also blogged about this phenomenon at https://www.exploravention.com/blogs/soft_arch_agentic_ai/ but I frame it more as how leaders can help the organization arrive at a healthy and sustainable balance between writing and reviewing code.
Hey your write up is good too. I thought the specific application to software architecture apart from software engineering is a valuable contribution, because software architecture is where if the AI tool goes wrong the repercussions have a longer term effect.
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.
My question is always: what are you building? You need to tell the AI what to build. What if it does it in a way that isn't what you want, or makes the buttom blue instead of red, or any number of other decisions?
AI can write the code, but not tell you what code you want it to write. In other words, how long are your specs? Either the LLM decides "whatever" or you have massive amounts of documentation to coordinate.
We still need to decide what to build, and some of the how. That is not automate-able, yet everyone seems to gloss over that bit.
Yes, the LLM writes the specs. In fact that LLM writes everything, and then the humans only flag anything they want changed, other than that it’s completely automated.
Imagine you were working with a very talented software shop. You might tell them your preferences sometimes and some things you want changed, but otherwise they mostly just build the right things the right way. And unlike a real software shop, the LLM system can implement changes incredibly fast.
I have this conversation (or a variation threof) with some friends: I suspect that the vast majority of “mainstream commercial software development” is flat out just cooked. We won’t be writing code, nor debugging it. It’ll will just be people throwing more LLM compute at everything.
Open source, hobbyist and personal projects will probably remain the last bastions of “human in the loop” and human-written code, and I suspect these circles will retract into smaller, tighter circles.
Basically had the same urge to write about this problem, prompted by the exact same comments around mental fatigue this week. Only got to the research stage.
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.
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.
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.
I've worked places that actively acknowledged they were paying a productivity tax for people to have unexpected encounters, and they'd recover the losses at a higher level.
This. And there would be huge investments in productivity and reducing bureaucracy.
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.
So you struggled to improve velocity without AI tools, are you worried that using the AI tools as a crutch will just lead to a death spiral of bad code being shipped increasingly faster? I've only ever seen the AI adoption approach work on fully functional teams.
The concern as well is that by forcing the AI onto developers, they eventually throw their hands up and say "well they dont care about code quality anymore, neither should I" and start shipping absolute vibeslop.
> I've only ever seen the AI adoption approach work on fully functional teams.
It's not that the team isn't functioning, it's that it's a pretty diverse team in terms of experience, which means things just used to take a while to finish.
> The concern as well is that by forcing the AI onto developers, they eventually throw their hands up and say "well they dont care about code quality anymore, neither should I" and start shipping absolute vibeslop.
This is IMHO avoidable by emphasising code reviews and automated tooling; my general policy is still that everyone is responsible for what they push, period. So absolute vibeslop isn't what I'm seeing, rather an efficiency miscalculation on which parts should be written by humans and which by the AI.
In my experience the bottleneck was never with writing code. If this is the case how can a developer be expected to increase their output while still being responsible in the same way? Seems like a recipe for burnout.
The vast majority of workplaces have never cared about code quality (with the exception being the actual engineers that write the code). Everyone else has no clue what programmers do, other than, "they write arcane symbols, and our product works, and our business continues to function". They do not know that code can even _have_ quality. It does not help that they only ever have to interact with engineering when something is going _wrong_, which conditions them to associate engineers with stress and failure and angry customers. Nobody ever thinks of engineers when everything is going well. The LLM mandates stem from a combination of mistrust and resentment.
I know, from second hand experience, that long before coding LLMs became a thing, engineers would ship slop when it became clear that their superiors cared about deadlines uber alles (i.e. not shipping slop would be the same thing as quitting, but without the paycheck -- slop code is often a form of quiet quitting).
Most people would _prefer_ to be able to "program" their entire business from a spreadsheet. LLMs have enabled them to get involved, and they cannot understand why engineers reject this "help" (it is for the same reason that a pilot would reject a copilot that thinks he knows how to fly because he played a flight simulator or read Jonathan Livingston Seagull; flight simulators are used in training too, but they are not a substitute for actual piloting experience). This refusal and resistance feeds into the mistrust and resentment. We live in a world where managers and administrators do not understand what they are managing and administrating, nor do they think that this is part of their job description. In the worst cases, they believe their job is to extract compliance from their subordinates.
There is a _lot_ of alpha in being part of a company, where authorities understand how the internals of the business (including software and IT!) _actually_ function. (One engineer told me that clueless yet demanding managers are, for all intents and purposes, unwitting saboteurs, and that the best a company can do about this is get him a job interview at a competitor). In some sense, the economy is just a machine for transferring wealth from those who do not know something essential, to those who do know something essential. This can veer uncomfortably close to exploitation. If we want to avoid crossing that line, we need to cultivate an economy where a lack of understanding is not seen as an _opportunity for profit_, but rather _as an opportunity for illumination_.
Your team is creating code you don't really grok to "get stuff out the door". Guaranteed a month or year from now this is going to bite you in the ass, hard.
> 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.
A wreck of a product is still better than being out of business by not being able to release fast enough. Unfortunately, the market in general does not reward slow high quality.
You better not ever complain about software again given your view on the importance of quality.
Who says that is my view of the importance of quality? My second sentence starts with "unfortunately"...
I'm just recognizing that businesses have challenges to deal with besides quality. Being able to generate revenue is just as important as software quality. And seeing how easily consumers switch to a competing product if it has a few more features, you can't neglect time to market if you want to survive as a company.
Many customers are pretty shallow: "meh, the new version looks just like to old one, nothing has changed" even if under the hood the product has significantly improved.
and_then("complain about enshittification")
ookay..
Yes, market dynamics are a bit of a catch 22: customers looking for the best deal, companies looking to reduce costs to still make profit. Customers always looking for the newest features, companies releasing faster before the product is done.
This is a starker tradeoff, but still the same logic that engineering leaders have used for years to eliminate time for exploration, learning, mentoring, role-switching, and every other activity that makes a better engineer but doesn’t move tickets off the queue. These developers are all going to work somewhere else in a few years, so why should we invest in growing their skills? This isn’t a charity, after all.
I’m sure you’re smarter than that, but a lot of leaders aren’t. And that’s based on the past, when they had an established playbook they could choose to follow, not the situation we’re in now where you have to make it up as you go.
I absolutely see your point there, but I don't have a better answer. It feels like the table stakes for feature development speed have risen all of a sudden, whether we like it or not.
Well, only if the increased speed doesn't result in a quality or staffing time bomb. Which none of us really knows at this point. You could always write code faster if you don't care if it works or is maintainable (and indeed many companies work that way for a while), and you could always put your developers in a pressure cooker until they leave from burnout.
So, you have a duty of care to make a safe workplace, at least in most countries.
Consider what a job with no joy means for the ongoing mental health of your staff, where the main interaction they have all day is with an AI model that the person has to boss around; with little training on norms. Depression, frustration, nonchalance, isolation, and corner cutting are going to be the likely responses.
So at the same time as you introduce new tooling, introduce the quality controls you would expect for someone utterly checked out of the process, and the human resources policies or prevention to avoid your team speed running Godwin's law because they dont deal with people enough to remember social niceties are important.
Examples off of the top of my head of ways to do this are: - Increased socialisation in the design processes. Mandatory fun sucks, a whiteboard party and collaboration will bring some creativity and shared ownership. - Budget for AI minimal or free periods, where the intent is to do a chunk of work "the hard way"; and have people share what they experienced or learnt - Make people test each other's work (manual testing) or collaborate, otherwise you will have a dysfunctional team who reaches for "yell in all caps to make sure the prompt sticks" as the way people talk to each other/deal with conflict.
The way to justify this to management above you is the cost of staff retention - advertise, interview, hire, pay market rates, equip, train, followed 6 months later by securely off boarding, hardware return, exit interview means you get maybe 4 months productivity out of each person, and pay 2 months salary in all of the early job mistakes or late job not caring, or HR debacle. Do you or your next level up want to spend 30% more time doing this process? Or would you rather focus on generating revenue with a team that works well together and are on board for the long term?
The answer most of the time is "we want to make money, not spend it". So do the math on what staff replacement costs are and then argue for building in enough slack to the process that it costs about half of that to maintain it/train the staff/etc.
Your company is now making a "50% efficiency gain" in the HR funnel, year over year, all by simply... not turning the dial up to 10 on forced AI usage.
Framed like that, sounds a lot better doesn't it?
I'm applying gentle pressure, not forcing everyone to use it. If necessary, I will fight for my team as much as I can, but that's not where we're headed and I would think about switching jobs if it ever is.
Having said that: The dichotomy expressed in the threads here is a bit too extreme for my taste. It's not like working with AI is pure Yes-clicking review dread; there is joy to be found in materialising your ideas out of thin air, instead of the Lego-like puzzle solving experience many developers are used to.
And as mentioned in TFA, There's risk in both using it too little and too much. This also applies to employees, of course: If I shielded junior developers from AI tools, they'd end up in their next job utterly unprepared for what may be required from them as the world keeps spinning.
> Framed like that, sounds a lot better doesn't it?
Sure does, but that's not the situation I'm in. I'm trying to figure out the local maximum of keeping my company afloat in a world where AI has kicked the PMF from under our feet to the other end of the playing field, and ensuring my team stays happy, curious, and engaged. And I'm not the only one in this spot, I suppose.
> It's not like working with AI is pure Yes-clicking review dread; there is joy to be found in materialising your ideas out of thin air
I think that's true for some developers, and not for others. My guess is that one subset of developers has more ideas than they have time/resources to implement, and they enjoy programming because they love seeing the finished product emerge. I think this subset is more likely to go into management, because it's a force multiplier for them. They're the ones getting joy out of seeing AI make their ideas into reality.
But there's another subset who enjoys programming not because they love to see a product emerge, but because they enjoy the process itself: the head-scratching, the getting past "why won't this work" to the moment when the build starts working again or the site comes back up or the UI snaps into place. It's the magic of finding, among all the possible wrong answers, the exact right combination of bits that solve the problem. This subset is not getting any joy from AI: they're seeing AI take away that whole process and turn it into the kind of work their managers and their project owners do. It's made even worse because their managers don't even understand why they're so unhappy. I think managers would do well to consider how they're going to keep these folks happy and engaged and productive, because they're the ones who are going to be fixing the production bugs introduced by their teammates' AI commits. If they've all gone off to retrain as electricians, we're going to have a problem as an industry.
[dead]
You are feeling that pressure because the people that use them are more productive and the next pressure you are going to get is to remove yourself from the loop completely.
I personally do not. But I don't work in the software industry. I write custom software in an industry that's as far away from tech as you can imagine. My management tells me what features they want, and doesn't care how it gets done. They only care that it works, and the priority is never to get a feature out fast. The priority is to never break their logistics software that's used 24/7. The deployment cycle is still fast, but bugs can be catastrophic, and it's on me to fix any bugs that crop up whenever something goes into production. Usually, when a bug filters up to me, it's within a few hours, because edge cases arise quickly. I know almost immediately what lines of code in which files are the most likely culprits. Because I wrote them, and I tested them manually, and I thought long and hard before hitting the button. If someone else (or something else) wrote them, I'd have to go hunting at the exact moment when time is critical and there's an open bug in a live deployment, and my phone is ringing and people are yelling.
The term "vibe coding" is new, but I've described what I do as "jazz coding" for a couple decades.
This mentality never worked in IT world. We've always had high pace of change and endless learning and adaptation to new tools and approaches.
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.
Am I alone in thinking atrophy might not happen? I use a keyboard all day but it doesn't mean I can't write by hand anymore. Predictive text didn't make me forget how to spell. If i buy coffee it doesn't mean I forget how to make it
Counterpoint: my handwriting is way harder to read and my hand tired faster than when I was in high school. And I am worse at spelling and my vocabulary has stopped expanding much since I started typing more and reading less
[dead]
Nobody has to worry about atrophy. That's the good thing about it: Things only atrophy when you don't need them any more.
Real quick, how does paging work?
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.
What's FORTRAN 83?
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 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! :)
Ask me what 9 times F is
It's fleventy five
When you let the LLM do the programming, you’re a product manager, not a programmer.
When you let compiler generate code for you, you're not a real programmer... That's what opcode coders was ranting in early 60s about FORTRAN programmers.
Product managers can't produce viable programs ready to be deployed in production (yet). But maybe the will able to do it in the future. We don't know how far or close this future is. But I don't think it's not a bad idea in general.
The assumption behind the discussion is that they will be able to produce viable programs. And if you’re letting the LLM own the code, that’s what your job function will be: product manager.
Fair. But I'd change a title a bit to Product Engineer or System Designer. Still a lot of engineering judgement is/will be required to deliver production-ready systems.
I recently accepted-ish a position at a very ai-forward company. Manual programming was somewhat discouraged entirely.
I've used AI tools in the past for maths I didn't understand or errors I couldn't make sense of, and wrote the bulk myself, but now we have as mentioned, opus/sonnet 4.5- which work great.
As part of this, I had to integrate two new apis- nornally, when I write an API wrapper I end up learning a lot about how the API feels, what leads to what and how it smells, etc. This time? I just asked Claude to read it's docs, then gave suggestions about how I wanted it to be laid out. As a result? I have no idea how these apis feel, their models, etc. If I want to interact with them, I ask Claude how I do a thing with the library it made.
Mind you, the library is good. I looked over everything, it's fairly thin and it's exactly how I would write it, as I suggested it do. But I have no deep understanding, much less an understanding of how it got integrated in.
Like, normally when I integrate something in I learn a bit about the codebase I'm integrating it into. Do that enough times, and I understand the codebase at depth, how things plug in. This time? Nada.
It's.... Deeply uncomfortable, to know so little but still be able to do so much. It doesn't matter if I get it to explain it, that's just information that washes off when I move onto the next thing. The reflexive memory isn't built.
All of which is to say, I agree with the article.
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.
I have a few parallel AI-authored side projects on the go that have quite different shapes, and I feel quite different things about each
1. A survival horde game (like Vampire Survivors and Brotato). At the moment it's very primitive, very derivative (no new ideas) and not much fun. I have no sense of pride over it, but it is much further along than it would be if i'd been writing it from scratch. I expect once I invest in the fun side (gameplay innovations, graphics) i'll feel a greater sense of attachment, and I plan to do all the art assets myself.
2. A MacOS web app for managing dev env processes, works but is ugly. I don't have confidence in AI making a remotely presentable UI, so I'll be doing that part myself.
3. A useful little utility library. The kind of thing that pre-LLM would've been too far out of my expertise to be motivated to try making. I'm steering the design of it quite heavily, but haven't written any code. It seems like it's already capable of doing very useful things, and I oddly feel quite proud of it. But I have a weird sense of unease in that I _think_ it's good, but I don't _know_ it's good.
I think the main thing I'm learning is to make sure there's always something of yourself in whatever you produce with the help of AI, especially if you want to feel a sense of accomplishment. And make sure you have a good testing philosophy if you're planning to be hands-off with the code itself.
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.
And they love to do this in spite of writing "NO FALLBACKS" etc. in your AGENTS.md.
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.
It seems to do this kind of stuff more when you're not looking too. Like I'll be approving edits all day without any problem then the second I set it to auto it gets a lint error about dead code and adds a pragma to allow the dead code instead of removing it, etc.
> They generate code that’ll get a positive result at any cost, even if it’s horrible in efficient.
If only efficiency is the only problem with that. Sometimes an error state should an error. This is the equivalent of eating all exceptions and pretending all is fine. It just means nothing works.
> it’ll teach you bad habits
So will most programmers
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.
Claude Code has a “learning mode” that makes it explain what it’s doing and leave “TODO(human)” placeholders in the code where you have to do part of it.
> Boilerplate and scaffolding
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 spend a lot of time side by side with other devs watching them code and providing guidance. A trend I'm starting to sense is that developer velocity is just as much hindered by unfamiliarity with their tools as much as it is wrestling with the core problem they really want to solve.
When to use your mouse, when to use your keyboard, how to locate a file you want to look at in your terminal or IDE, how to find commands you executed last week, etc. It's all lacking. When devs struggle with these fundamentals, I suspect the desire to bypass all this with a singular "just ask the LLM" interface increases.
So when orgs focus on a "devs should use LLMs more to accelerate", I really wish the focus was more "find ways to accelerate", which could more reliably mean "get more proficient with your tools".
I think there's a lot of good that can be gained from formalizing conventions with templating engines (another tool worth learning), rather than relying on stochastic template generation.
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 think Mitchell Hashimoto as a pretty sane take here, where he uses LLM's to offload stuff he doesn't care about / want to think about so he can spend more time and brain power on the stuff that really matters. I tend to agree.
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.
One specific example that comes to mind is developer tooling in the form of bash scripts. Sure, I can write it myself, but I do this so infrequently that there is a cost for the context switch and ramp up. This, and similar dev ex things that have been languishing in the “one day” pile because there is always the next feature to build. I can now spend 10 minutes here and there to ship incremental QoL improvements alongside my core work.
You don't have a scripting language in your toolbox that you're comfortable with?
I would probably say a shell is "the correct tool for the job" but other than the appeal to authority, or appeal to tradition. There's not a great argument for a shell script over a language you're already comfortable with.
There are hundreds of examples that are easier or faster in python than shell.
Engineers are bad at making tooling, we're even worse making ephemeral tooling we're willing to throw away. Contrasted with other makers, you have machinests who gladly make a one off tool to make a single process easier.
The more 'correct way' than a shell script, is something simple and composable. A large unwieldy shell script that you can't make simple changes in, is terrible design, and it's a mistake to allow that inertia to gain speed.
It's not exactly a complete refutation but something I've been thinking about recently.
I'm not disagreeing with your point. A good understanding of the domain and relevant systems is quite crucial. My point is that you don't always need to inspect the code at such low-level detail, provided there are tests or other ways to prove that the code behaves in the way that you describe.
> My point is that you don't always need to inspect the code at such low-level detail, provided there are tests or other ways to prove that the code behaves in the way that you describe.
This is true *only* in isolation. The pain of going through said depth of detail, is what builds the intuition for the whole system. Once and twice may not be noticeable, but a new habit, and that new habit's corresponding extreme downtime because no one understands the quirks anymore... Despite a few engineers who stake their life on the testing system, tests can't catch all issues. And it's extremely difficult to stop an oil tanker.
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.
In other engineering fields, no one calculates the numbers for building a plane or a dam by hand anymore. They rely heavily on software for design, simulations, etc. throughout the entire development cycle. Yet, starting in university, those engineers still learn to do those calculations by hand so they comprehend the underlying principles.
IMO, that’s what we should do as software engineers. The idea of letting AI "do the thinking" for you is a bad idea. Sure, it can trivially write a sort function for you. Let it! But you still need to understand how that sort function works. If having the tool was a substitute for understanding the fundamentals, anyone with access to Catia, etc. could design a working airplane.
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.
I was recently analyzing a TypeScript module in our new project to learn how it works, and was thinking, "I wouldn't have done it like this” and “the styling is not for me". Then the realization slapped me in my face: this code came from me!
This article also slapped me, and has crystallized my jumbled thoughts on the topic. I'm deep into my career as a productive software engineer, yet I'm concerned there is a visible vanishing point of my value. My retirement is also visible, but I'm more concerned about our trade and those of you who have many years ahead.
While adaptation is hard when moving a lightspeed, workflows must adapt, more time on imprinting the generated code into our heads with iterating on trialing, testing, editing, before PRs is prudent.
A larger problem is architectural drift and leak. Those feel like they could become extremely problematic. We’ll need to put more effort into steering agents so their output aligns with architectural goals. The steering will also need to be iteratively refined.
Great article! I’m concerned, but also rallying for us.
really good piece, sums up almost exactly where I'm at with AI currently.
cognitive debt is a real problem in my domain (embedded software) because AI simply can’t debug the symptom when the reasons for the bug aren’t in code, and a stack trace may not exist. finding the REALLY hard bugs requires in depth systems understanding and the ability to connect things you’ve seen around the codebase together - and the fix usually isn’t adding code, which means the patchwork fixes Claude likes to do only makes things worse.
that said, it’s made writing harnesses and supporting tools WAY easier and faster, and my workflow is better for it. Searching the git history for the why of things is also made way easier; helping me to reason more effectively
In the section about Cognitive Debt the author wrote...
Apply this directly to fully agentic coding. If you stop writing code and only review AI output, your ability to reason about code atrophies. Slowly, invisibly, but inevitably. You can’t deeply review what you can no longer deeply understand.
I think this argument is flawed. On every team I've worked with we've always had the opinion that junior developers learn a lot about coding by reading and reviewing code written by other people, especially people more senior to them. Reviewing output doesn't weaken your skills, it improves them. Reviewing code in a large codebase forces you to explore and understand the paths that data takes. It pushes you to build an accurate mental model more than writing new code does, because that's usually isolated to a small, encapsulated domain where you only really need to care about the inputs and outputs (hopefully!).
The author is absolutely correct if you take 'review' to be 'click the accept button and move on', but if you're actually reviewing the code that your AI generates, and understanding it, and thinking about how to move forwards and prompt it to build the thing you really want, then AI only really removes the last type-the-code step. All of the architecture and process steps should be coming from you (maybe from a conversation with the AI during the planning step, but still, not just letting the AI do whatever it fancies.)
Replace this with “writing assembly”
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.
The problem is this is the difference between one or two obscure skills fading away with disuse (normal); and potentially all ability to load programming information into your working memory being affected; as you didn't develop the neural pathways or knowledge of the codebase (not normal or desirable)
While it is a spectrum around when you choose to use AI, what seems increasingly common in my experience is some people trying to go "all in", feel frustration and burnout when they are relegated to babysitting an LLM; get angry that it has made a mistake, misinterpretation or simply left something obvious out; then thinking it's user error/they didn't prompt well enough/it is their fault. At the same time, they are increasingly cognitively blind to mistakes at a review stage, so they find out the hard way in production and enter into a cycle of hyper vigilance/distrust/justifiable paranoia.
In those cases, it's a recipe for skills loss and depression over the long term and a vicious cycle.
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...
The debugging gap in the Shen-Tamkin study is the part that worries me. AI tools are great at generating code from a clear spec. But the skill that atrophies is recognizing when code is subtly wrong — and that's the exact skill you need most when reviewing AI output.
What works for me: write the spec in a markdown file before handing it to the agent. Predict what it'll produce before reading the output. When it surprises you, figure out why before accepting. Keeps you engaged enough to actually build mental models.
The management pressure angle in this thread is real. If your org measures velocity in lines shipped, AI tools will optimize for that metric and comprehension dies quietly.
I think for AI to become useful while minimizing it's harm, the interface as a whole needs to be reworked. Instead of having a loop of code generation followed by review. The initiative should be taken by the developer, AI should be a background thing, not one that's surfacing itself to the developer.
For instance I was thinking of AI coding where the developer is writing the application interface, files, design, and the AI in the background is reading them and translating them to the programming language of choice.
This way the developer is writing the whole thing out by hand, it would be as if one is writing fluid pseudo code, but the abstractions would be there, the way they are interacting with each other is there, the human is thinking if the abstractions and when to use them. Whereas the AI is out of the view, simply translating the fluid pseudo code to a rigid programming language.
Perhaps the above isn't really it, but I strongly feel something needs to change in the way we currently work, because it really creates a chasm between the developer and the outputted code not only in terms of the actual implementation but the mental abstractions it's supposed to reflect
You could give https://github.com/jurriaan/aico a try.
Seems very interesting thanks for sharing! (even tho it still has a review process, but I feel it's heading in the right direction)
I often come back to a quote from Tony Hoare (paraphrased):
There are two ways to write software: either it obviously has no errors or there are no obvious errors in it.
LLMs tend to generate the latter. Because that’s what’s in the training data: all the code that was rushed to production with a promise it would be fixed later. And humans are notoriously bad at catching these kinds of errors.
It feels bad using tools like this because it turns you into a reverse centaur. You’re there because the tool cannot be held accountable. You’re the last mile delivery driver shipping the code. You didn’t participate in its construction and you take all the responsibility for it.
Only there are studies which demonstrate how small of an impact code review has on code quality. And that after reading a few hundred lines of code in an hour the effect disappears. Current AI processes aren’t equipped to handle this.
Whatever we’re doing it’s heading in the opposite direction of engineering.
> 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.
We sysadmins have been seeing this for decades with docker, k8s and cloud adoption. None of the engineers I work with are able to debug a simple networking issue or compile a trivial piece of c code.
Otoh: didn't Socrates say the same about writing? It rots the brain?
It’s like walking vs taking bus or car. It’s nice to walk sometimes..
I’d argue it’s more like driving yourself vs passively being driven everywhere. Remember that scene at the end of E.T.? Where Elliott and his brother steal the van, but they don’t know how to get to their destination because “I don’t know streets mom always drives!”. LLMs are mom always driving - you might recognize some landmarks after a while, but you don’t know the names of the streets to get anywhere.
Actually a pretty good metaphor.
Should we seek the dopamine reward of creativity in writing code? Isn't delivering the value created through the developed results to users itself a creative act?
Will the ability to review code (which is important now) become important in the future? Is it necessary to have a pipeline to nurture seniors?
Wouldn't it be more important to define clear requirements, verify that the resulting code operates properly within various guardrails, and clearly communicate the designed value, than to be able to review code?
> Reviewing AI output all day without the dopamine of creation is not a sustainable job description.
I agree that reducing engineers’ careers to code review will lead to burnout (amongst other problems).
But I think the reason we’re headed in this direction is precisely because creating with AI /can/ deliver “the dopamine of creation”.
It doesn’t deliver that hit for everyone - but it does for the half of engineers who are more excited about building new things than the act of coding.
Teams build more and ship faster because it’s so much easier to do that with AI - and it’s fun - and that leads to increased review load.
Your writeup accurately captures the big concerns I have about using AI coding tools. One extra thing I have noticed around this is I have a similar feeling about driving and self driving. I really love driving but since I was able to better arrange my life and no longer am a commuter driver I don't get as much daily practice so now when I do take the occasional long drive I don't have as much skill and expertise. It is the same with AI coding tools, I need to put them down from time to time and exercise my mental sharpness to prevent losing my abilities to be a senior engineer.
> Refusing to use AI out of principle is as irrational as adopting it out of hype.
My principles have nothing to do with whether or not AI is giving me extra productivity though. Even if AI made me 5000x more productive I still wouldn't want to use it out of principle. I think it is a deeply immoral technology that shouldn't exist
I also think that people who research and build AI are deeply immoral people who should be tried for crimes against humanity
Because I have no doubt in my mind that AI is leading us towards crimes against humanity. We are going to be culled the moment we are not useful anymore.
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 think you could probably identify different "risks" and then just code in such a way as to mitigate them; I don't personally think there would have to be much of a risk of atrophy of skills if this is done.
I guess it reminds me of someone switching from a manual labor job to a desk job: you become at risk of physical issues from being more sedentary, but you can exercise after work or even some people have things like standing desks and such to keep active during the job
So there can be real risks but there should be ways to manage them
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
The commentator was trying to be polite. Passing off LLM generated work as your own is a dick move to the reader. It's plagiarism.
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.
>Every developer I know uses AI for coding now.
And for blogging too, it seems.
Yeah this feels at least partially Claude-written to me too.
> "You don’t learn to recognize good code by reading about it in a textbook, or a PR. You learn by writing bad code, getting it torn apart, and building intuition through years of practice."
I'd like to point out though, that you also learn by AI producing bad outcomes you are responsible for, and building intuition how it might fail through practice... You also might experience more lessons than you would have if you would have coded manually.
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 wonder whether there's a relevant analogy between human languages and computer languages.
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.
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.
It's currently unclear what the long-term effects of offloading coding to AI will be for developers, and posts like this are not meaningful, as they have zero data to work with. I suppose they feel good to write if you're the type who thinks that a theory with zero data is as good as one with data.
> 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.
I think what’s interesting is technical debt is contained in a project, but cognitive debt is contained in a person. I think we will see good developers pile up so much cognitive debt they will nuke their own careers.
>> That deep, focused, creative problem-solving where hours disappear and you emerge with something you built and understand.
Yea but for how long? Go back and read any code you wrote a year ago and realize it could have been AI that wrote it.
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.
It is very true in a physical sense. "Use it" results in neural pathways being formed. What happens when you dont use them?
https://www.sciencedirect.com/science/article/abs/pii/S01602...
I meant in the physical sense of muscles/physical adaptations. I haven't read/written C++ in 10 years - it would take me a month to get back up to speed. If you never written C++ it would take you at least 6 months/year to get to the same level (depending on what we're comparing here).
Likewise for physical exercise - it took me a year to hit 100kg squat when I started getting into shape 10 years ago. I haven't been very physically active for years but I'd hit 100x5 in a month of starting gym again.
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.
A reasoned argument I agree with.
The challenge is that the competitive and economic pressures make this moot.
A person, entering the field via AI driven development, will have none of the qualms about skill, seniority, understanding the codebase, or craftsmanship. Those arguments are handwringing by the previous generation of engineers. Their focus is solely on the outcome and value produced from the input prompt. That aligns closer to how businesses see their codebase: something they have to prompt their engineers to produce in order to generate business value.
Similarly, new AI driven companies focused on delivering value at speed and lower costs will have none of the baggage of the legacy code companies with engineers stuck debating these questions. These new gen companies will be focused on delivering value, doing so at quicker speeds and lower costs, raising the level of competition for existing incumbents.
Will existing businesses be willing to spend money to purchase services from these new gen companies of AI developed products? Seems like it.
There are real problems with these AI developed codebases. They tend to collect baggage and start to feel like a house of cards. A big open question is whether AI models will continue to improve in order to patch all the vibe-holes being generated. Seems like they will improve.
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.
"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.
We can argue about percentage points and months here and there, but we're very quickly coming to 100% and people aren't even afraid to admit it publicly anymore. The prophecy was definitely on point.
I would wager we aren't even at 50%.
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
That was a nice collection of brief history, links to research and other articles, and original thoughts.
So basically the same cognitive debt that accrues to engineers the moment they become managers.
> 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.
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 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
Re determinism: that's what we'd like to believe, but it's true only if we redefine input to include overall build and execution context, and the latter is generally unreproducible. Over the last few years I've seen plenty of subtle bugs, some caused by UB, some caused by interactions with the overall execution environment, that resulted in mostly correct but sometimes wild and haphazard results, all for the same "input".
Once these bugs were fixed, things became deterministic, but to say that all software is deterministic is to assert some level of programming, build, and operational consistency that is often achievable with great effort.
Re gcc hacks: nope. No gcc'isms anywhere in the code, all warnings enabled, no warnings produced, just one case where a field is not updated in one very specific set of circumstances. Thanks for the suggestion, but that was one of the first things we thought of. There is a slight chance that it is actually a clang/llvm call stack depth bug, but the effort to reproduce that outweighs the impact of the bug, what with one thing and another not relevant here.
UB -> occasional non-determinism.
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.
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.
"Cost" is a matter of personal judgement. Personally, using AI hasn't cost me anything.
so like...JavaScript?
Until a majority of software engineers become unemployed, we won't collectively wake up and act which is what we should to this existential crisis unfolding. Action more than yet another plausible sounding article.
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
[deleted]
[dead]
Agreed - if you're only writing things with Claude Code that would exist anyway (largely day job things) you're missing out.
Having an AI-slop version of X for your own gratification is usually better than having no version at all.
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.
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.
"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.
Edit: I had an instance once where about once a month another developer would ask me about workplace setup, mentioned it to someone and was told maybe they were the English speaker of the group. Upon further investigation, that seemed to be the case.
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.
What happens when more and more people cannot explain their PRs ? I mean they already use AI to create the "explanation" as well and ping you. Ask them questions and they will delegate again to AI and copy-paste what the AI answers.
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
Point taken. Still, isn’t an activity like learning a new library, language, or platform a fundamental part of being a software developer? Haven’t we all complained at some point about companies hiring react developers because we all know the real skill is the ability to pick up new things. And to be clear, this isn’t moral panic, it’s a concern that we may end up in a future where people don’t know how systems work anymore and we are dependent on two or three companies and their data center moats to maintain any technology.
> Still, isn’t an activity like learning a new library, language, or platform a fundamental part of being a software developer?
Yeah, this is fair. However, I think the same study indicates a way out of this dilemma. I feel like I've actually learned a lot about the languages and libraries I've used that I haven't known before through agent coding just by watching it do things and having explained and summarized things to me and find documentation and so on.
> And to be clear, this isn’t moral panic, it’s a concern that we may end up in a future where people don’t know how systems work anymore and we are dependent on two or three companies and their data center moats to maintain any technology.
I don't think this concern in itself constitutes a moral panic, no. I think it's a reasonable thing to think about and worry about how to avoid. However, I think there are definitely very prominent features of the general discourse and concern around this that do constitute a moral panic:
1. First of all, and most importantly, this issue is very often moralized, around like having done a proper amount of work or suffered enough or whatever to be like justified in getting the results you're getting or participating or being considered a real program or whatever. This moralization has existed in the community for a really long time, treating programmers that work at a higher abstraction level than you as lesser than or whatever, so I would argue this isn't a natural response to these concerns so much as it is an extension of a moralistic attitude to a new topic and it's also not necessary to have in order to have these discussions.
2. The hyperbolic misinterpretation of studies, and the fact that these concerns are being raised as if they are going to be a certain, and huge, consequence when we just have very little evidence so far to that effect.
3. The fact that most of the discussion isn't about how to use these tools in a way that doesn't face these problems or whatever, but instead a sort of binary framing around either you suffer from this problem or you boycott.
4. The way the idea of "cognitive debt" and these other things is used to frame it as anyone using AI has their brains "turned to mush" or whatever, as if it's some kind of like general debilitating cognitive injury inside of just that you're getting rusty at skills because you aren't using them, even using scaremongering terms like skill atrophy, which is then used to preemptively dismiss the thoughts of anyone, the people most concerned about this disagree with.
I also think like... If the argument is that people get good at what they do a lot and to get rusty at what they don't do, I really don't see the argument for why using AI a lot wouldn't make you better at high level architectural decisions spotting possible problems with architectures and approaches before they become a problem organizing your thoughts and tasks, reading a code and spotting issues, etc.
The thing is that using coding agents doesn't actually hide whether an algorithm isn't performant enough from you. It'll either be slow or it won't be.
It doesn't hide if you've come up with a bad architecture, because that will also confuse the agent and make it difficult for it to make future modifications without breaking other things.
It doesn't hide a lack of DRY either because if you've got the same code in multiple places and you want to change how it behaves then you've got to change it in multiple places and they can get out of sync and that will bite you in the ass.
And then there's the fact that with coding agents, there's an obvious and direct reward for using more tests and more advanced testing, better linters, more compiled and typed languages, better CI/CD, better documentation, etc. So people will probably get better at that.
> 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.
Yes, it exists, but are you going to edit it by hand if you didn't write it in the first place, or you would rather throw another prompt to update it? People tend to do the latter, thinking about the code as some generated artifact, like object files.
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 your 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.
How do we maintain best practices when the compiler outputs a different result for the spec at any given time? How do we obtain reproducible builds? Do we pin to a specific version of our compiler (ie, snapshot of the model; is this possible anywhere except local currently?), and vigorously test changes after any updates in our "toolchain"? How do we have control over our "toolchain" (again, apart from local), especially when said "toolchain" can, for all its users simultaneously, fold to political pressure from state regimes? And, if the code generated by LLMs is the build artifact, why is it now okay to check the build artifact into source control?
There may come a day when we, as an industry, decide that simply doing it by hand is more expedient when it comes to resolving urgent production issues. We may not know the pain we are causing ourselves until well into the future when it has become too much to bear without a visit to the proverbial doctor.