This article explores how automation and AI tools can create dangerous knowledge gaps. The Decision-Schema Framework below illustrates the key dynamics at play.
Antipattern: Knowledge Cliff
Is AI automation freeing us to focus on higher-value work, or are we accidentally losing core capabilities we'll desperately need later? Automation tools promise to make us more capable, but they can deliver the opposite. They create false confidence in skills we never actually developed while quietly eroding the abilities we need to keep sharp.
Senior developers are already voicing concerns that junior developers are using LLMs without building foundational skills. Juniors now hit a wall in their own development, cutting off the supply of new senior developers to the industry. Even those who are experienced are reporting concerns of skill atrophy, where they become so dependent on AI tools they can't perform formerly basic tasks without it. And as we zoom out, the pattern extends beyond coding to any domain where we delegate decisions to automation.
Knowledge and Ability
Everyone begins with a low level of knowledge, and through study and hands-on practice they develop. That hands-on practice is what allows knowledge to deepen into instinct, reaction, and faster decision-making.
Making decisions and seeing what happens creates a feedback loop for learning. We build expertise, develop faster, and perform at a higher standard than if we simply read a book. Getting the basics to a point where they are already semi-automatic for us humans becomes critical when we need to handle more decisions and higher complexity.
Delegating decisions to automation changes this dynamic. For those who have developed expertise, this can lead to false confidence where we trust the automation but perhaps shouldn't, or worse, we begin to believe we have abilities that were actually delegated away.
The final evolution is that as decisions are delegated away, skills begin to atrophy and need to be re-established by making decisions again (we will later discuss how some skills atrophy faster than others, with different recovery times).
Use this tool to guide AI Automation initiatives. Ask yourself, "Am I marching my workforce off a knowledge cliff?" and "Am I ready to manage a company where nobody really understands how to make decisions about this topic?".
Knowledge and capabilities will exist in one of these four quadrants, and depending on action (or inaction) those capabilities will naturally migrate towards other quadrants. For example, learning may become tacit through skill development, or create false confidence when learning is abandoned.
Experienced
Experience
Decisions
Decisions
("Fool's Gold")
When using automation tools to make decisions for you, it ought to be for things you already have expertise in, and are comfortable with those skills going into atrophy. It is not until you awaken to how poor those skills have become that you will need to start the learning process to rebuild them. Not all skills you developed in life will be useful in the future, but many will be, and it is often hard to see just how many micro-decisions we make in a single day.
Using LLMs to make decisions you could not make without the use of an LLM will trick you into a false sense of confidence and capability. If you don't understand it, don't delegate the decisions out to automation.
Skill Atrophy and Recovery
Skill Atrophy is a trap, and like any trap it is easier to avoid if you know where it is. From analogues in other fields (studies into things like automating the cockpit controls of an aircraft), there is the general understanding that skills do not just become lost but rather degrade. The speed of degradation depends on many factors including what type of skill it is. The speed of recovery is also variable.
Skills involving hand-eye coordination seem to bounce back fairly quickly, but cognitive skills like doing specific calculations in your head seem to require more practice before coming back to their previous level. There is research into ways to hack recovery time of lost cognitive skills through specific training schedules, but there is no well-proven mass-market solution for this across all types of experience. If the cognitive skills are critical to your organisation working correctly, be mindful when evaluating if you should automate them away to unstable unproven alternatives.
In the early 2000s, before GPS was widespread, you could wave at a taxi with your hand, say a street name, and the driver would usually know exactly where to go and how to get there. They likely even knew the relevant road conditions and would instantly take off in the best direction (unless they wanted to scam you with a detour).
As GPS became commoditized, it became harder to find a single taxi without a smart phone stuck to their windshield. Now you get in to the taxi, tell them the address, and the route pops up for them. These GPS routes in 2025 are realy good, but perhaps the top 10% GPS routes are not as good as the top 10% of 1980s taxi drivers could manage. Decisions about the route have been given over to automation, but the automation is stable, reliable, and on-average better, even if we lose that top 10% of route quality.
Today, many taxi drivers will find it a challenge to navigate without a GPS nearly as well as they did in the pre-GPS, and this includes many of the ones who were previously excellent at it. Planning a route in your head is a complex cognitive skill that evaporates quickly and is hard to re-build.
If you need yet another example, think of how easy it was to do basic mental math before everyone had a calculator in their pocket. We were practicing it every day. In North America, a shopping trip would often mean a shopper had to calculate percentage tax in their head like "What is the total with a 13% tax on $37?". Today, it is often hard for most people to to add simple two-digit numbers together, never mind calculate tax.
Movement across the Agency-Experience axis are challenging to see day-to-day but become very obvious when we zoom out to quarters and glaringly obvious over years.
As an example, one of many common paths to collapse might look like this:
Avoiding walking off the cliff can be done through re-learning lost capabilities. It can be quite simple if you monitor and act on it early.
When Atrophy is Not a Problem
Not all atrophy is bad. Bad is subjective.
For a taxi driver, driving and navigating a car is a critical core-capability of doing the job well. For a passenger, it is just background noise they can ignore. From a passenger perspective, hiring a taxi instead of driving has "automated away" a significant amount of their workload.
The taxi-driver is fine with the GPS automation because the automation they use is highly available and of high enough quality it is often not an issue for them. Yet the taxi-driver is not pushing innovation and delivering capabilities.
NASA on the other hand suffered knowledge atrophy even without automation. They once had an objective of landing people on the moon back in the 1960s, and they built Saturn V rockets to do just that. These were "deep space" capable rockets, which stopped being built due to economic pressure to focus instead on other missions with the space shuttle and near-earth-orbit. Saturn V could take you to the moon, but NASA had no missions out that far. Decade over decade no decisions were being made about how to build these rockets by anyone, and the last people who were involved retired.
It cost somewhere between 1 and 2 billion (inflation adjusted to 2025 USD) to build each Saturn V, and at the peak they could build one every 6-9 months. As NASA changed objectives back towards "deep space" they needed a rocket.
Although there were over 2900 cubic feet of detailed documentation about how to build the rocket ship, it was a major struggle to build one again. Teams had to re-discover what was a core capability, re-building and discovering the tacit knowledge. Not simply the documents but the tacit knowledge that never gets written down.
This created the Space Launch System (SLS) rockets, which cost nearly 24 billion and around 11 years to develop, and only one SLS Rocket was ever built.
While spaceflight is full of politics that makes many things impossible, from a purely economic perspective, I suggest it would have been significantly cheaper and yielded better results to keep a skeleton team on iterating Saturn V with improvements and new technology over the last 50 years, with the goal of keeping the knowledge alive and relevant for when NASA wanted to return to deep space.
- Pay close attention that the knowledge you are walking away from is a core capability.
- Some core knowledge can be worth walking away from if the automation does it to a significant enough quality, and is always available. However, always factor in the vendor lock-in.
- Knowledge is a living thing, not a document. You must ensure that critical knowledge exists in an ecosystem that has to regularly make decisions.
The Granular Skills Problem
"We should automate everything!" is unfortunately a strategic failure due to poor focus. Automation of things like "Software development" with an AI, is just the shorthand name for a seemingly endless list of nested micro-skills that clump together into bigger ones we can talk about. If you sat down and really thought about all the skills needed to do that job, you would see a vastly complex set of skills, some of which might not be obvious to most non-developers.
Software Engineer Skill, Composed of Micro-Skills
(Over-simplified, incomplete view. For illustration purposes.)
When we automate "coding," which specific capabilities are we preserving vs abandoning? Making the automation more specific lets us actually work on and deliver automation.
Today in 2025 there is a large discussion about if we can replace software developers with LLMs or not. This is far too bulky of an ask to work with effectively. By analogy, it is like asking if we can replace all taxi drivers with robots. There are some cutting-edge experiments that work in very well controlled situations, but it is not ready for widespread adoption. However, if we asked if we can replace a taxi driver's need to navigate a city by using GPS, the answer is obvious because that capability is high quality and highly available. Robo taxis exist in some contexts already, but they are not a global market replacement due to the massive set of other tasks that are unaccounted for by the technology, or due to the lack of reliability and stability in those contexts.
We can map out zones of automation-fit by considering the availability, and quality (or stability) of the candidate automation technology by four zones of risk.
For example, using LLMs to "replace all developers" is a low-quality and questionable availability solution in 2025. I would plate that somewhere around high-risk. However, if we zoom in and pick out specific micro-skills there are many things that land perfectly inside the safe zone or conditional zone.
Some leaders are unsure about automating granular skills instead of bulky ones, but this is a cognitive trap. Just because the skill you are automating is small, does not mean the impact is small. Think of it like this:
Don't just go for high impact single-event tasks, the low-impact high-frequency tasks are everywhere and often blend in so well we don't notice them.
Here's example of universally helpful developer automation is actually for a very granular task: Tab-autocomplete in code editors. This tiny feature predicts (using pre-AI technology) the rest of an untyped variable, considering all possible pre-existing variables. Much better than manually scouring the code for the right name and typing it out manually, especially when you might need to do this multiple times per line of code. Developers use this feature thousands of times per day without thinking about it, and it's been automated away for decades. However, what makes it work is it is: results are high quality, it is always available, and does not not taking agency away from the critical decisions your developers need to make about what kind of code to write.
By the same token, many developers using LLM Coding assistants become frustrated quickly as the tool quality has a quality-ceiling below where they need it, frequently has availability issues, and takes away the agency and decision making on such a bulky level they cannot easily unpick what decisions the tool made incorrectly (programming communities now commonly share memes about how developers might spend hours prompting the LLM to make a simple change instead of 20 minutes writing the code on their own). LLM coding tools can still be useful, but we have to always proceed with caution and limit our expectations to the right set of skills we plan to augment or automate.
The goal isn't to avoid all automation, but to be intentional about what decisions we preserve, and thoughtfully specific about why we use those tools.
Focus on finding automation targets that are stable, not a core capability you can lose knowledge of, and granular enough to take action on.
Quick Reference for Leaders
Before Automating, Ask
- Knowledge Assessment: Does our team understand this domain well enough to evaluate AI output?
- Load Classification: Are we giving away our autonomy of a core competency, or removing background noise?
- Failure Planning: What's our plan to monitor and unwind this decision if this automation fails?
- Knowledge Preservation: How will we keep the underlying knowledge alive?
The most dangerous path is abandoning learning for domains you don't understand. The most common organizational failure is allowing atrophy without planning for recovery.
Facing Pressure to Automate Everything
Organizations face structural incentives that drive core institutional knowledge off a cliff. Keep an eye out for common decision-making errors in your leadership team:
- Short-term efficiency metrics vs long-term capability preservation
- Quarterly pressure to show productivity gains from AI adoption
- Competitive pressure - "everyone else is automating, we have to keep up"
- Cost reduction mandates - automation looks cheaper than human expertise when ignoring the broader scope of human work
- Risk aversion - the common instinctive bias to believe computer systems can be more "reliable" than human judgment
Experts are most at risk for losing their skills because they're the ones organizations want to "leverage" with automation tools, but they're also the only ones who can evaluate when automation is dangerous. Work with your experts to discover what automation patterns work to remove the noise in a stable way, and avoiding solutions that only have market traction as they ride the hype cycle rather than proven value in your context.
It is important for leaders and experts to constantly sense for automation traps so they can work to revert problems as early as possible. Knowledge erosion is often invisible until crisis hits and it becomes obvious the org has de-skilled, traditional productivity metrics don't capture capability loss or de-skilling, ando no one really tracks things like "what we could do before, but can't do now".
You should aim to automate many things, but don't automate your core thinking.