{"slug": "using-ai-without-deskilling", "title": "Using AI Without Deskilling", "summary": "A developer warns that AI tools can cause 'deskilling' by removing the difficulties that build expertise, citing the psychological concept of 'desirable difficulties' from Robert and Elizabeth Bjork. The post argues that while AI improves short-term output, it can prevent skill formation in beginners, stagnate intermediates, and erode team skills for seniors, urging developers to distinguish between productive struggle and mere friction.", "body_md": "The worry is not that AI makes you lazy.\n\nIt is that AI removes the difficulties that were building the skills you are paid for. You do not notice, because the work still ships. Your output stays the same. What is underneath it does not.\n\nEvery other post in this series points at this one. It is also the post where the evidence is strongest, and where the honest answer is more complicated than \"keep struggling.\"\n\nLearning research has a well-established finding that explains the whole problem. It is called **desirable difficulties**.\n\nRobert and Elizabeth Bjork named it in 1994. The result is the opposite of what most people expect. Conditions that slow you down while you are learning often lead to better long-term memory and better transfer to new situations. Conditions that make learning feel smooth tend to lead to worse memory. Learning that feels easy now usually means weaker recall later.\n\nThe reason is that recalling something with effort strengthens the memory more than recalling it easily does. When you struggle to work something out and then get there, the working out is the part that teaches you. When the answer is handed to you, you never work anything out.\n\nSo the useful question about any tool is not whether it makes work faster. It is whether the difficulty the tool removed was also teaching you something.\n\nDebugging was. You formed a guess, you were wrong, you found out why, and you made a better guess. Nobody designed that as training. It happened because the work was hard.\n\nReading documentation was. You went in for one answer and came out understanding more of the system, because finding the answer you needed meant reading past four you did not need.\n\nBoth of those still happen when you use these tools. They just happen much less often, and you cannot see the difference, because the output looks the same.\n\nAny tool that removes friction also removes whatever that friction was teaching. That is not a complaint about tools, or about the people who use them. It is just how tools work.\n\nThe reason it is easy to miss comes from a second finding in the same research: **doing something well today and learning it properly are different things, and we mix them up constantly.** How well you perform today is visible. Whether the skill will still be there in two years is not. So a change that improves the first while damaging the second looks like a straight win, both to you and to your manager.\n\nThat is why this is not only a junior problem, and why nobody's discipline is the issue. Everyone's short-term output goes up. Nothing tells you that anything else has changed.\n\nThe mechanism is the same everywhere. What differs is where the damage lands.\n\n**Beginner.** The skill never forms at all. There is no earlier version of you to fall back on, so nothing decayed. The skill was simply never built, which is harder to notice because there is no \"before\" to compare with.\n\n**Intermediate.** Your existing skills stay flat while your output rises. That feels fine, and mostly it is, until you compare yourself with someone who kept practising on purpose. The gap opens slowly, and it shows up on unfamiliar problems rather than routine ones.\n\n**Senior.** Your own skill is mostly intact, because you built it earlier. Your team is losing theirs, quietly, and you are the person answerable for what they can do in eighteen months. You will not see it in delivery metrics.\n\nThe advice is not \"use AI less.\" It is more specific than that, and the research explains why the specifics matter.\n\nBjork warns against the obvious misreading: making something harder is not automatically useful. Some difficulties teach you something. Others are just annoying. A badly documented internal tool creates a huge amount of friction and teaches you nothing except how to get around that one tool. Removing that friction costs you nothing.\n\nSo the job is to separate the two.\n\n**Step one: list what became easier.** Not in general. In your own week. Writing boilerplate. Remembering syntax. Finding the cause of an error. Choosing between two designs. Reading unfamiliar code.\n\n**Step two: for each item, ask what it was teaching you.** Boilerplate taught you nothing, so let it go completely. Remembering syntax taught you very little. Finding the cause of an error taught you a lot. Choosing between designs taught you the most.\n\n**Step three: keep two or three of them on purpose.** Not all of them. Two or three, with a small fixed time limit, chosen because they were teaching you something you will need later.\n\n**One condition matters more than the rest.** The research finds the benefit only holds when the effort ends in getting the answer. Struggling and never getting there teaches you nothing. So whatever you keep, finish the loop: try it unassisted, then check the answer, then compare the two. The comparison is where you actually learn something.\n\nThat is the whole method. Three steps: name what became easier, ask what it was teaching you, and keep two or three of them with a timer and a check at the end.\n\nHere is the strongest version:\n\n**Every generation of tools caused this same worry, and it was overblown every time. Compilers, garbage collection, ORMs, Stack Overflow. Each one was going to produce engineers who did not understand their systems. Each one produced engineers who worked on more interesting problems instead. Why is this different?**\n\nI think this objection is largely right. This case probably is not entirely different, and some of what I have written above will look overcautious in ten years. More importantly, **you cannot tell from the inside which case you are in.** Every generation that worried was sure its case was the real one, and most of them were wrong. I have no special view that lets me say this time is the exception, and neither does anyone else who says so confidently.\n\nWhat I can offer instead is a test you can apply later. The earlier tools removed work but left the learning loop alone. A compiler wrote your assembly, and you still thought about the program, still guessed why it was slow, and still found out when you were wrong. The loop survived.\n\nThis tool can remove the loop itself, because it can give you the guess as well as the code. That is the specific difference worth watching. If the loop turns out to come back somewhere else, further up, then this was the usual worry and it was overblown again. That would be a good outcome, and I would be happy to be wrong about it.\n\nThe precaution costs a few hours a month. That seems worth it either way.\n\n**Three steps:**\n\n**1. List what became easier this month.** Specifically, in your own work.\n\n**2. For each item, ask what it was teaching you.** Boilerplate taught you nothing. Working out the cause of a problem taught you a lot. Be honest about which is which.\n\n**3. Keep two or three of them.** Small time limit. Always check your answer at the end.\n\nNot all friction is worth keeping. But not all friction is waste either, and the whole skill is telling the two apart.", "url": "https://wpnews.pro/news/using-ai-without-deskilling", "canonical_source": "https://dev.to/raghavsharma_/using-ai-without-deskilling-4in7", "published_at": "2026-08-10 06:00:00+00:00", "updated_at": "2026-08-10 06:15:26.478904+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-ethics", "developer-tools"], "entities": ["Robert Bjork", "Elizabeth Bjork"], "alternates": {"html": "https://wpnews.pro/news/using-ai-without-deskilling", "markdown": "https://wpnews.pro/news/using-ai-without-deskilling.md", "text": "https://wpnews.pro/news/using-ai-without-deskilling.txt", "jsonld": "https://wpnews.pro/news/using-ai-without-deskilling.jsonld"}}