IBM's skill-erosion survey records worry from 60% of 8,800 employees

A count of worried employees and a test of what employees can do measure different things. The IBM figure is the first kind. Its numbers come via a dev.to post summarising IBM's announcement ^[1]. Sixty percent of 8,800 respondents is roughly 5,280 people reporting a concern ^[3][2]. The post's author wrote that it is "a report of concern, not a controlled measurement proving that AI caused people to lose ability" ^[4].

The post points to an Anthropic experiment published in January as closer evidence. Anthropic randomly assigned 52 developers learning an unfamiliar Python library to work with or without an AI assistant ^[5]. The assisted group averaged 50% on a quiz afterward. The unassisted group averaged 67% ^[6]. The gap is 17 points, about a quarter of the control group's score ^[6][1]. Completion time did not differ significantly between the groups ^[7].

The result belongs to a specific workload. The post describes the study as small, covering one learning task, with the quiz shortly afterward, and says it does not establish long-term effects on developers generally ^[8]. Its comparison of interaction styles was observational, so it cannot show that one prompting technique caused better learning ^[9]. For the number to transfer, your people have to be learning a library they do not know and be checked soon after. A senior engineer working in a codebase she knows well is outside the conditions tested.

Inside those conditions, the timing result matters more than the score. The assisted developers scored lower and did not finish significantly faster ^[6][7]. For onboarding, where the learning is the deliverable, that study offers no time saving to set against the lost comprehension.

The Microsoft Research study is the weakest of the three on causation. It surveyed 319 knowledge workers for a CHI 2025 paper and found higher confidence in AI associated with less reported critical thinking ^[10]. Those were self-reports and associations ^[11]. The direction could run either way: people who already check less may simply trust the tool more.

The evidence supports treating this as a training design problem. The post proposes a design at the level of a single task: "give the feature and your understanding separate finish lines" ^[12]. Its worked example is a task tracker that sorts by due date. The developer writes down the intended order first. Then they predict where tasks with an early date, a later date and no date will land, and what breaks a tie between two matching dates, before the assistant shows the result ^[13]. The suggested prompt tells the assistant: "Ask me to predict the order for a small example before showing the answer" ^[14].

In my view this is the right unit for a team lead running onboarding. It costs minutes per task. It also leaves a written prediction that a reviewer can compare with what the code actually did. The author is careful about its standing, calling it "a work habit you can try, not a scientifically validated recipe" ^[15].