The paper tries to frame expertise as a shared resource that can be depleted when AI takes over the work through which people normally learn. Its core claim is simple even if the paper’s language annoyed a lot of readers: when fewer people struggle through problems, get mentored, review each other’s work, and build judgment the slow way, the pipeline that produces future experts weakens. Several people said this already feels familiar from earlier shifts like social media displacing books, calculators reducing mental arithmetic, and outsourcing hollowing out manufacturing know-how. The paper itself drew heavy criticism for stretching the “tragedy of the commons” idea too loosely and for using Ostrom badly, but most of the useful conversation accepted the underlying concern even while rejecting the academic framing.
Where people landed was more concrete than the paper. The strongest recurring point was not “developers forget syntax” but that they lose the habit of poking around in unfamiliar systems until they understand them. That matters because debugging nerve, verification instinct, and comfort with ambiguity are exactly what teams need when the model fails. Several experienced programmers said AI can make them faster and broader, but also more dependent on the model for first-pass investigation, code review, and even deciding what to inspect next. That dependence feels fine until the guardrails disappear.
The practical split was between people using AI to skip mastered or low-value work versus people using it to skip the very struggle that builds competence. Some described AI as a way to clear blank-page friction and focus on architecture, systems, or product work. Others described a more corrosive pattern where non-coders ship real products without learning much about the underlying code, and where experts can still deliver more but stop exercising the muscles that once made them reliable under pressure. A few comments argued that this is just another tool transition and that manual coding will matter less over time anyway. Even there, the implied requirement was the same: somebody still has to know how to test, verify, and govern what agents produce. The discussion was skeptical of companies chasing “many times more code” without a plan for preserving those human capabilities.
If you run an engineering team, treat AI productivity gains as a training and governance problem, not just a tooling upgrade. Keep explicit paths for humans to practice debugging, code review, and independent problem solving or you may get short-term output with long-term fragility.
Mostly concerned and skeptical. People broadly bought the premise that AI can erode real expertise, especially debugging instincts, mentorship, and junior-to-senior skill formation, while also criticizing the paper’s academic framing and its use of commons theory.
Key insights
01
Debugging nerve is what atrophies
What weakens first is not raw knowledge but the willingness to enter a messy system and investigate it yourself. Relying on Claude for the first pass changes debugging from direct contact with logs, flags, and failure states into supervision of a mediator, which blunts the instinct to probe, falsify assumptions, and get comfortable being lost. That reframes the risk from “you forgot commands” to “you stopped building the temperament that hard problems require.”
Watch for engineers who can still approve or steer AI output but hesitate when they must diagnose a failure from scratch. Preserve work that forces direct system contact, especially incident response and exploratory debugging.
Used carefully, AI does not just replace learning. It can move attention up the stack. Experienced developers described offloading groundwork they already understand so they can spend more time on architecture, organization, abstraction boundaries, and game or product systems they otherwise would not reach. The key claim is that some “lost skill” is really discarded ceremony, while judgment and taste become more central.
Do not measure capability only by how much hand-written code someone produces. Evaluate whether AI use is creating better system design and clearer decisions, or just more artifact output.
AI is already letting determined non-programmers get apps and workflows into production by orchestrating tools like ChatGPT, ClaudeCode, TestFlight, RevenueCat, Squarespace, and Google Sheets. That is a real expansion of who can build. It does not mean they absorbed software engineering fundamentals. One commenter said the skill acquired is mostly “how to use AI to make apps,” which shows up fast in delivery and vanishes fast when the model disappears.
Expect a growing class of operators who can produce useful software but cannot maintain or extend it independently. Plan support, review, and ownership boundaries accordingly before these projects become business-critical.
Several comments pushed past the familiar calculator analogy and argued that AI is absorbing not one narrow task but most of the loop that once reinforced competence. It writes, reviews, researches, debugs, and flatters the user into trusting the flow. That creates what one firm reportedly calls “cognitive surrender,” where people stop doing the analysis needed to catch bad assumptions because the model now handles both production and the supposed oversight.
Do not let AI own both generation and validation in the same workflow. Separate who creates, who tests, and who signs off, or errors will pass through with very little real scrutiny.
The useful version of the paper’s metaphor is not that shared resources naturally collapse. It is that unmanaged systems do. Comments invoking Elinor Ostrom argued that commons survive when rules, boundaries, and enforcement exist, and fail when those structures are weak or dismantled. Applied here, expertise does not disappear just because AI exists. It disappears if firms remove the institutions that replenish it.
If you buy the “cognitive commons” idea, the answer is not nostalgia. Build governance. Create protected training time, review norms, and incentives that reward understanding, not just throughput.
People are inventing deliberate practice around AI
Some of the most concrete responses were behavioral. One programmer keeps a daily block for fully AI-free coding and asks agents to leave key problems unsolved unless explicitly told otherwise. Others said wrestling with wrong AI answers or doing LeetCode and Project Euler by hand restores the feeling of connection to the work. The point is not purity. It is maintaining the struggle that sharpens intuition.
Treat independent problem solving as a maintained skill, like exercise. Teams using AI heavily should institutionalize some no-assist work, especially for juniors and for core technical paths.
This view says the whole concern is backward-looking. AI is quickly turning coding and even parts of math into benchmark-driven automation, so worrying about whether juniors can still hand-code misses the direction of travel. If answer boxes can handle both implementation and design discussion, then losing old craft skills may matter about as much as losing long division or slide-rule fluency.
Do not assume today’s bottleneck remains the bottleneck. Track which skills are becoming optional in your org and which new verification or orchestration skills are actually compounding.
The analogy to hollowed-out manufacturing was challenged as too neat. The counterpoint was that US manufacturing output is still large and growing, just more automated, so the story is not pure loss of know-how. Fewer people do the work, but expertise may have shifted into different roles rather than disappeared outright.
Be careful with decline narratives that ignore automation’s reallocation effects. In your own team, distinguish between genuine capability loss and skills moving into different layers of the stack.
arxiv.org