> skill atrophy is real
It is also both a choice and avoidable.
Atrophy happens when you trade understanding for productivity. Productivity benefits your employer and your KPIs, but not your understanding and your opportunities going forward.
Understanding used to be an unavoidable of the exploration process, and writing documentation used to be the thing that never got done. Now, writing documentation is automatic, but reading it still isn't.
I've been managing a team of interns at my last job, and as they were all equipped with coding agents, they'd deliver complete solutions to problems once or several times per day that would normally take days, or weeks if you factor in necessary learning.
As review of their understanding, and for the sake of my own cognitive debt, I would first ask them the question "How does it work?" and they usually couldn't answer. After a handful of tasks, they started preparing answers. This forth-and-back is still more shallow than getting the deep knowledge chiseled through hours of trial and error, debugging and wrong directions. Spending two hours to find a problem to realize you forgot to save or upload a file, or had an x instead of a y. I look back with nostalgia, and I wonder if there weren't always better ways, and we just get to pick them now. I can literally convert any task, solved or not, into a quiz that brings me towards understanding, in rainbow-colored pig latin.
Let’s say you have an incident, and you need a resolution. Do you send out the AI for the hunt and fix it within 5 minutes, or spend 30 minutes going around, figuring out the problem yourself?
I’m on the camp of using agents as much as you can, but make sure to understand what they did. However, it will still atrophy your skills, no matter what. It’s just different times now, as on the job you’re expected to deliver faster. And obviously that means less time spending on your craft, honing your skills and etc.
Digging a well using manual tools is a skill. Using a machine to dig is also a skill. They are distinct skills. So if people change the way work is done, skills themselves shift.
Using AI appropriately and efficiently and safely is a skill. Similar to using a mechanized excavator. It can do the work 10x faster but it can also do a lot of damage quickly as well.
Those who don't realize this and not adapt to the new skill set required by the industry will lose their jobs. It will cause a loss/atrophy of prior skills and development of new skills but that is inevitable.
Those who have the prior set of skills do have an advantage over those who don't have them. But the new set of required skills can be developed without having the earlier ones too. The most proficient in the new set of skills may or may not be the ones that were most proficient in the old skills.
> Let’s say you have an incident, and you need a resolution. Do you send out the AI for the hunt and fix it within 5 minutes, or spend 30 minutes going around, figuring out the problem yourself?
Let’s say you have an incident, and you need a resolution. Do you spend 5 minutes tinking, then solving the problem or send out the AI for the hunt and spend 30 minutes grappling with hallucinations and non-sensical output?
The 5 minutes I’ve seen is usually by someone that will send the complete output to someone else to decipher, while saying they have figured it out. Then they’ll turn into a meat proxy between the team and the agent.
In real life, for systems where incidents that require such rapid responses, you usually have fail-safes an killswitches. When you were designing your system, did you put in place alerts and monitoring to mitigate risks?
I’m not sure if you’re running the latest frontier models. Every single engineer (and myself included!) has mentioned numerous times how nothing beats AI in debugging. My other guess would be that you have non-standard set up that Opus 5.5 doesn’t know off the bat how to debug.
I wouldn’t say the same a year ago, but usually we get preliminary reports during incidents before someone can even auth to debug. Almost all the time, nowadays, the report is correct. We obviously verify it.
"Latest frontier models" seems a bit like acting like smarter reasoning can fill in context that doesn't exist in various systems without guessing. It's convenient because it's always the users fault for not working in the platonic ideal observability setup that can feed everything on a plate. And if you're in that situation how much is the agent adding over incremental improvements?
It can't be both "so easy and hands free anyone can use it" and also "well they must be using the wrong model/holding it wrong if it's not working for them". If there weren't tradeoffs of the different models then it wouldn't be exposed to the user.
> Let’s say you have an incident, and you need a resolution. Do you send out the AI for the hunt and fix it within 5 minutes, or spend 30 minutes going around, figuring out the problem yourself?
It is far more often the case that you will spend more time getting the answer out of the LLM than you would've gotten yourself. They suck ass at troubleshooting systems, very frequently jumping to completely implausible scenarios that no human would think of as the first thing to try, and almost never asking questions to clarify the situation the way a human does.
This has not at all been the case for me. LLMs (even the more-capable local models) are exceedingly good at troubleshooting when given proper context (clues, hints, a decent system prompt/skill that provides even the barest hint of how things work)
What you're describing sounds more like what would happen if you gave a chatbot without access to the repo as little context as possible and asked it to come up with a solution, blind.
> They suck ass at troubleshooting systems
Given the right tools and instructions I find them to be consistently superhuman. It's unreal.
I have an automated system responding to issues occurring on oceanconnect.ca, and every single diagnosis has been correct for months. Of course I still verify, I tune solutions, I review everything. But it's right. It's not a trivial system. It has a fairly large frontend, a large-scale model processing pipeline on the backend, a fairly complex database, and a queue for getting new data into the system. Claude does a stellar job of navigating and understanding problems, even when they're not 'real' or as they initially appear to be; things like quirks in old versions of Safari, or the model pipeline fails due to data integrity issues from the providers.
I've rarely encountered cases where I need to steer a frontier LLM much when troubleshooting. They're exceptional.
Sorry, this might be a thing in your org, and I have no idea hoe I can convince you, but it’s just not true in our environments. Maybe you might have a very non-standard set up, but frontiers do amazing job.
I’m a troubleshooter and I’ve managed human troubleshooters. The LLMs are better - if they are grounded in either IAC or api access to the infra.
I couldn't imagine submitting a PR for code that I didn't understand and couldn't explain. You can even have AI explain the code to you, so it's easier to understand.
I think a lot of this skill atrophy talk is over-blown. It definitely happens, I experienced it some, but as long as you slow down a bit, and clean up and understand your code, your skills won't atrophy. Actually, AI provides a great opportunity to learn at an even faster rate by using AI to help explain complex topics.
I think perhaps my use of the word skill atrophy here is wrong.
Skill atrophy is when you're good at something, and because you don't practice it regularly, it gradually wanes over years, like when my former CEO said "I used to be good at programming" because he made a tiny chess computer and sold millions of copies, and now he... just doesn't code, and hasn't for decades.
Skill atrophy would be if I opened my text editor and I wasn't able to code after two years. Being a polyglot, there's always some language that feels rusty. And now they all do. But it hasn't been long enough to feel the atrophy.
What I'm describing is laziness to understand a problem domain.
> I couldn't imagine submitting a PR for code that I didn't understand and couldn't explain.
I could. I do it constantly for projects where that premise is acceptable. And I've worked on projects where many people merge to main once an established set of steps has completed. "How does it work?" and "Show me the thing working." are good gates. Understanding (or even reading) the code is not a mandated prerequisite.
As an Open Source contributor? No way. Exactly because I'm contributing to projects where people don't share basic premises. Some people code by hand, others use coding agents. If I were compiling stuff and everyone else was hand-writing their assembly, I'd read and tidy up my generated assembly, too.
> AI provides a great opportunity to learn at an even faster rate by using AI to help explain complex topics.
Totally. Better solutions come through those explainer sessions.
[dead]