Fallback Competence: What to Do When AI Fails

By Vikas Malpani

On April 20, 2026, ChatGPT, Claude, and Gemini went down at roughly the same minute. The three systems that most teams treat as backups for each other all failed together, and for a few hours a lot of businesses discovered that their “AI-powered” workflow was really an AI-only workflow with no bottom to it. That same summer, OpenAI logged around 166 incidents in nine months, with four significant outages inside a single four-day window. The tools got good enough to run the work. They did not get reliable enough to be the only thing running it.

Here is the durable version of that story, the one that stays true long after the specific outage is forgotten. The question that matters is not how often your AI is wrong. It is what you can still do the moment it is not there. That capability has a name I want you to start tracking. I call it fallback competence, and most founders are losing theirs without ever seeing the meter move.

I run two companies where AI now writes most of the first draft of almost everything: code, copy, analysis, outreach. I did not notice how much I had offloaded until a model I depended on started returning confident garbage for an afternoon, at a moment when I needed a clean answer fast. I could still do the task by hand. It just took me three times longer than it used to, and I was rusty in a way I had not budgeted for. That rust is the subject of this piece.

The skill you are losing without noticing

Every capability you hand to a machine follows the same arc. First you supervise it closely because you do not trust it. Then it earns your trust and you supervise less. Then you stop doing the underlying task yourself at all, because why would you, the machine is faster and you are busy. Somewhere in that third phase your own ability to do the task quietly decays. You do not feel it decay, because on any normal day the machine is there and the work still ships.

The decay is invisible for a specific reason: nothing tests it on a good day. Your throughput keeps climbing because the AI keeps carrying the load. The only thing that would reveal how far your own skill has slipped is the machine’s absence, and the machine is almost always present. So the gap between what you can produce with AI and what you can produce without it widens month after month, unmeasured, until the one day it gets measured for you at the worst possible time.

This is not the same problem as skill atrophy in general, and it is worth being precise about the difference because the internet keeps blurring them. Atrophy is the slow rotting of a muscle you stopped using. I wrote about the mechanism of that in cognitive debt, the compounding cost of offloading your thinking. Fallback competence is a different object. It is not the muscle. It is the reserve. It is the specific, operational answer to one question: if the AI vanished this instant, could you still do the job to an acceptable standard, how fast, and at what quality? Atrophy is why the reserve shrinks. Fallback competence is the reserve itself, and unlike atrophy, you can size it, price it, and defend it on purpose.

The stakes are not abstract. In 2026, roughly 65 percent of organizations reported at least one security incident tied to AI agents running on their networks, with 43 percent of those causing operational disruption. Gartner expects that by 2027, more than 40 percent of enterprises will pull back or decommission autonomous agents after production incidents they only discovered by having them. Infrastructure that acts on your behalf cannot be down for an hour without causing real harm, not inconvenience: meetings unscheduled, money not moved, work left half-finished mid-execution. The more of your operation runs through AI, the larger the hole its absence leaves, and the more your fallback competence is the thing standing between a bad hour and a bad quarter.

Fallback competence, defined

Fallback competence is your ability to perform a critical task to an acceptable standard without the AI you normally use for it. It has three properties that make it worth treating as its own asset.

It is task-specific. You do not have one fallback competence, you have one per critical process. You might be perfectly able to write a contract clause by hand and completely unable to reconstruct your data pipeline without the assistant that built it. Averaging those together tells you nothing useful.

It decays silently. Unlike a server, it sends no alert when it drops. The only signal is a live test, and live tests only happen during failures, which is exactly when you do not want to be finding out.

It is a portfolio decision, not a moral one. You cannot keep every skill sharp, and you should not try. The goal is to decide, deliberately, which competencies you keep hot and which you let go cold, and to be right about that split before the day you need it.

Picture two lines running across time from the day you adopt an AI tool. The first line is your throughput with the AI, and it climbs. The second is your competence without the AI, and it sinks. The space between them is the fallback gap, and it grows quietly the whole time. Then the AI fails, and you drop off the top line onto the bottom one in an instant. The height of that drop is the fallback gap you let build up. Nobody plans that fall. They just take it.

The point of naming the gap is not to scare you into using less AI. It is to make a quantity visible so you can manage it. You already manage cash reserves, a buffer you keep against the day revenue stops. Fallback competence is the same idea applied to skill: a reserve of manual capability, sized to how much damage the AI’s absence could do, maintained on purpose rather than assumed by default.

The reversion test

You cannot manage a reserve you have never measured. So the first move is a test you run on each of your critical processes, one at a time. I call it the reversion test, and it has three questions.

First, is the AI reversible and available? Some processes have a graceful manual mode you can switch back to. Others have quietly become the only way the work gets done, with no manual path left because nobody kept one. If the answer is “there is no manual path,” you have already found a problem.

Second, if you dropped to manual with no warning, could you produce an acceptable output at all? Not a perfect one. Acceptable. For some tasks the honest answer is no, and that is fine as long as you chose it. For others the answer is yes but slow, which is a different posture.

Third, how long would it take and how good would it be? A task you can do manually in twenty minutes at ninety percent quality is a very different risk than one that takes you two days at sixty percent. The number is the whole point. Vague reassurance that you “could figure it out” is not a fallback plan, it is a hope.

Run this on five processes and you will find, as I did, that your intuition was wrong about at least two of them. The task I assumed I could always do by hand turned out to depend on context the AI had been silently holding for months. The task I feared I had lost turned out to be fine. You do not know your reserve until you count it.

The three ways AI leaves you holding the bag

People plan for the outage, the dramatic case where the service is simply down. That is the least of your problems, because it is obvious. The AI can leave you exposed in three distinct ways, and two of them are quieter and more dangerous than the one everyone pictures.

It can be down. The service is unreachable, the work stops, and at least you know it. This is the honest failure. Your only defense is a manual path and the competence to walk it.

It can be wrong. The service is up and returns a confident, fluent, plausible answer that happens to be false. This is worse than down, because down announces itself and wrong does not. To catch a wrong answer you need enough intact competence to know what right looks like. If your skill has decayed to the point where you can no longer tell, the failure passes straight through you. I wrote about the specific danger of confident-but-wrong output in silent failure, and it is precisely the mode fallback competence exists to catch.

It can be compromised. The service is up, the output looks normal, and it has been manipulated, poisoned, or hijacked. In 2026 this stopped being theoretical. Autonomous agents are now the object of real attacks, and 41 percent of AI-agent incidents resulted in unintended actions across business processes. The sprawl of unmanaged agents is exactly the surface these attacks exploit. Detecting a compromised output requires the most fallback competence of all, because the failure is designed to look like success.

Notice that the fallback each mode demands gets harder as you go down the table. Surviving “down” needs speed. Surviving “wrong” needs discrimination. Surviving “compromised” needs suspicion plus discrimination plus the standing to overrule a system that looks fine. That last one is where careers and companies get hurt, and it is the one people prepare for least.

The competence portfolio: hot versus cold

You cannot keep every skill sharp. If you tried, you would never get any of the speed that made AI worth adopting, and you would be right back to doing everything by hand. The answer is not maximal manual practice. It is a deliberate portfolio. You decide which competencies to keep hot, rehearsed and ready to take over, and which to let go cold, accepting that you cannot do them without the machine.

The sorting rule is a two-by-two. On one axis, your exposure: how likely the AI is to fail you on this task, multiplied by how much a failure costs. On the other, your current fallback competence, straight from the reversion test. Where those two land tells you what to do.

The box that should keep you up at night is the danger zone: high exposure, low fallback. A task where the AI can plausibly fail, a failure would hurt, and you have quietly lost the ability to take over. Most founders have two or three of these and do not know it, because they have never run the reversion test. The whole exercise is worth it just to find them.

Your list will be different from mine, and that is the point. The specific answers matter less than the fact that you made them on purpose, in advance, instead of discovering them during a crisis. A cold competency you chose is a decision. A cold competency you drifted into is a liability wearing the costume of efficiency.

What aviation already solved

Software people talk about this as if it is a brand new problem. It is not. Aviation ran the exact experiment forty years ago, at life-and-death stakes, and the lessons are sitting there waiting to be borrowed.

In 1997, an American Airlines training captain gave a lecture that named the failure mode perfectly. He called the pilots he worried about “children of the magenta,” after the magenta-colored course line the flight computer draws across the cockpit display. His point was that a generation of pilots had grown so used to following that line and managing the automation that they had lost the raw ability to fly the airplane by hand with authority. On a normal flight it never showed. The line was always there.

Then the line went away at the worst possible moment. On June 1, 2009, Air France Flight 447 was crossing the Atlantic at 35,000 feet when its airspeed sensors iced over and the autopilot disconnected, handing the aircraft back to the crew. What followed is the case study every founder building on AI should read. The stall warning sounded 75 times. The pilots, startled and out of practice at manual high-altitude flight, pulled the nose up, which is the exact opposite of the recovery, and held it there. The word “stall” was never once spoken in the cockpit. The airplane fell for three and a half minutes into the ocean, and 228 people died. Across a pattern of similar automation-confusion crashes, the combined toll ran to hundreds of lives.

The investigators did not conclude that automation was bad. They concluded that the industry had let fallback competence decay and never measured it until the sensors failed. Their fix is the whole playbook. They recommended more mandatory hand-flying in training. They pushed simulator practice for abnormal flight modes, the situations the automation normally handles. And they insisted crews rehearse under the “startle effect,” the shock and high emotional load of a sudden failure, because a skill you only have when calm is not a skill you actually have. The FAA later issued a safety alert on the loss of manual flying skill and told instructors to watch for automation dependency directly.

Read those three fixes again, because they translate one for one. Mandate manual reps. Rehearse the failure, not just the happy path. Practice under load, not only when relaxed. Aviation is the one field that faced this problem at scale and beat it, and it beat it by treating fallback competence as a thing you schedule, not a thing you hope you still have.

Deskilling is measurable, not hypothetical

You might suspect this is all vibes, the kind of worry that sounds true and never shows up in data. It shows up in the data.

A 2025 study in The Lancet Gastroenterology and Hepatology tracked doctors who had been using an AI tool to help spot polyps during colonoscopies. When the researchers turned the AI off, the same doctors’ detection rate fell from 28.4 percent to 22.4 percent. These were trained specialists, and a few months of assistance measurably dulled the unaided skill they had spent years building. The machine did not just add a capability. It quietly subtracted one.

The pattern repeats in knowledge work. Research from Anthropic in 2026 found that people who used AI to delegate coding tasks scored 17 percent lower on comprehension of the work, while those who used AI to ask conceptual questions scored above 65 percent. Same tool, opposite outcomes, and the difference was whether the human stayed in the loop or handed the loop over. A 2026 survey found 74 percent of clinicians already worried about losing skills to AI overuse. The worry is not paranoia. It is a correctly calibrated read of a real effect.

And then there is the perception gap, which is the reason none of this self-corrects. In a randomized controlled trial published by METR in 2025, experienced open-source developers completed real tasks 19 percent slower when allowed to use AI tools. Afterward, those same developers estimated that AI had made them 20 percent faster. They were wrong about their own speed by roughly forty points, and they were confident. If you cannot even feel whether AI is speeding you up today, you certainly cannot feel your fallback competence eroding underneath you. The meter you would use to notice is broken. That is exactly why you have to measure it deliberately instead of trusting the feeling, a theme I keep returning to in the cost of oversight.

The startle cost

Here is the cruelest property of the whole problem, and the one aviation named best. The failure never arrives on a calm afternoon when you have time and a clear head. It arrives mid-crisis, when three other things are already on fire, when a customer is waiting, when the money is moving, when you are least equipped to drop cold onto the manual path and perform.

I call this the startle cost. Your fallback competence is not what you can do when you sit down fresh and take your time. It is what you can do when the system fails without warning, adrenaline spikes, and you have to switch from supervising to doing in the space of a breath. Those are two very different numbers. The Air France crew were, on paper, qualified to fly that airplane manually. In the actual moment of startle, out of practice, they could not. The gap between the paper skill and the startle skill is where the disaster lives.

This is why “I could figure it out if I had to” is not a plan. Of course you could figure it out with a weekend and a search bar. You will not have a weekend. You will have four minutes and a racing pulse. The only way to close the startle gap is to have rehearsed the failure while calm, enough times that the manual path is grooved and your hands know it even when your mind is scrambled. A fallback competence you have never exercised under pressure is a competence you are assuming, not one you have. Knowing when to take over, and being able to when you must, is the same discipline I described in calibration practice: you are training a judgment, and untrained judgment fails exactly when it is loaded.

What most people get wrong

The standard take on all of this is “AI is making us dumber, so use less of it.” That advice is both wrong and useless, and it is worth saying why, because if you accept the framing you will make bad decisions in both directions.

It is wrong because deskilling is not inherently a problem. I cannot do long division at speed anymore and I do not lose a minute of sleep over it, because a calculator has never once been the thing standing between my company and a bad outcome. Letting a skill go cold is completely fine when the stakes are low and the tool is reliable. Most of your skills should go cold. That is what real efficiency is. A blanket “resist AI to stay sharp” tells you to keep everything hot, which means you get none of the benefit and burn all your practice budget on things that do not matter.

It is useless because it names the wrong villain. The problem was never that you use AI. The problem is that you never decided which competencies you can afford to lose, so you lost them by accident, including the two or three where you are the last line of defense and the failure lands mid-crisis. Deskilling by choice is strategy. Deskilling by drift is exposure. The word “use less AI” cannot tell those two apart, which is why it is worthless as guidance.

And there is an honest counterweight that the “always take over” crowd ignores. Sometimes the human intervention is the crash. The Air France pilots did take manual control, and their manual input is what stalled the airplane; the automation, had it stayed engaged, would have kept flying. Fallback competence is not a mandate to grab the controls every time. It is the ability to grab them well when you must, and the judgment to know which times those are. Maximal manual override is its own failure mode. The goal is calibration, not heroics, and I said the same thing about when to trust AI output: the skill is accuracy of trust, not amount of it. Fallback competence is what you fall back on when that trust runs out, and like trust, it should be sized, not maxed.

What to do Monday morning

This is a practice, not a philosophy, so here is the version you can start without any new tools.

1. List your AI-dependent critical processes. Write down every task where a failure of the AI would actually hurt the business. Keep it to the ones that matter. You are looking for the load-bearing dependencies, not every convenience.

2. Run the reversion test on each. For every process on the list, answer the three questions honestly. Is there a manual path? Could you produce an acceptable output by hand? How long would it take and how good would it be? Write the numbers down. Guesses do not count.

3. Sort into a portfolio. Place each task in the two-by-two. Anything landing in the danger zone, high stakes and low fallback, gets fixed first. Everything you consciously put in “let cold” you can now stop worrying about, which is its own kind of relief.

4. Schedule the manual reps. For your hot competencies, book recurring practice. Run one process the old way once a month. Better, run an “AI-off morning” where you deliberately do the load-bearing work without the assistant and time yourself. You are not being nostalgic. You are keeping the reserve funded.

5. Set a no-single-line rule. For anything high-stakes, never let the AI be the only line of defense. That means a human check, a second system, a rollback path, or a manual fallback you have actually rehearsed. This is the operating principle behind a serious founder operating system, and it is cheap insurance against the day the magenta line disappears.

None of this asks you to use less AI. I use more of it every month, and I intend to keep going. The practice just makes sure that the more I hand over, the more deliberately I hold onto the handful of things I would need on the day the handoff fails. That is the entire discipline. It costs a few hours a quarter, and it buys you the one thing the outage will ask for and never warn you about: the ability to still do the work when the work is on you. For a fuller map of which capabilities are worth this kind of investment, I laid out the durable ones in what to learn when AI knows everything, and the read-side version of the same shift in the read-write inversion.

Frequently asked questions

What is fallback competence?

Fallback competence is your ability to perform a critical task to an acceptable standard without the AI you normally use for it, when that AI is down, wrong, or compromised. It is a reserve of manual capability, and unlike your throughput with AI, it decays silently and only reveals itself during a failure. The goal is to size it, maintain it deliberately for the tasks that matter, and stop assuming you still have it.

Isn’t this just an argument to use less AI?

No. It is an argument to decide, on purpose, which skills you can afford to let go and which you must keep sharp. Most of your competencies should go cold, because that is what real efficiency is. The danger is not using AI, it is drifting into a state where you have quietly lost the two or three skills where you are the last line of defense. Deskilling by choice is strategy. Deskilling by accident is exposure. This framework helps you tell them apart so you can keep adopting AI aggressively without walking into a crisis unprepared.

How is this different from skill atrophy or cognitive debt?

Atrophy and cognitive debt describe the mechanism: the gradual erosion of a skill you stopped using. Fallback competence describes the asset that erosion puts at risk, and it adds three things atrophy does not: a way to measure your reserve on each task with the reversion test, a portfolio decision about which reserves to keep funded, and a maintenance practice to keep them funded. Atrophy is why the reserve shrinks. Fallback competence is the reserve you defend on purpose.

How do I know which skills to keep hot?

Run the reversion test on your critical processes, then sort them by failure exposure, meaning the probability the AI fails times the cost if it does, against your current fallback competence. Keep hot the tasks that are high-stakes and where you are the last line of defense: reading your own numbers, judging quality against your standards, and being able to operate your core systems by hand. Let cold the low-stakes, interchangeable work. The specific list is yours, but it should be a decision, not a drift.

How often should I practice working without AI?

For your hot competencies, run one process manually and timed about once a month, and hold an AI-off session on load-bearing work monthly to quarterly. The frequency matters less than the fact that the practice happens while you are calm, because the failure will arrive when you are not. A skill you only have when relaxed is not a skill you can count on in the moment it actually fails. Aviation solved its version of this problem with mandatory hand-flying practice, and the logic carries over directly.

Does this apply to solo founders, or only big companies?

It applies more to solo founders, not less. When you are the whole company, you are also the entire fallback plan. There is no colleague to take over, no second team, no redundancy except the one you build into yourself. The more of your operation runs through AI, the larger the hole its absence leaves and the more you personally are the reserve. A one-person company has to be deliberate about fallback competence precisely because there is no one else to hold it.

What is the startle cost?

The startle cost is the gap between the skill you have when you sit down fresh and the skill you have when a system fails without warning, mid-crisis, with adrenaline up and no time. Failures never arrive on a calm day, so your real fallback competence is the version of the skill you can deploy under shock, not the version you can deploy at leisure. The only way to close the gap is to rehearse the failure while calm, enough that the manual path is grooved before you ever need it in anger.

How do I measure my fallback competence?

Pick a critical process and actually do it without the AI, timed. Record two numbers: how long it took and how close the result came to acceptable. That pair is your fallback competence for that task, and it is far more honest than any feeling of “I could handle it.” Repeat across your load-bearing processes and re-run it twice a year. The measurement is the whole point, because the perception gap means your gut estimate of your own capability is not trustworthy.

A closing note. If you want the wider view of which bets and capabilities are worth holding as AI absorbs more of the work, the AI opportunity map and the piece on the verification layer both sit next to this one. Fallback competence is the personal version of a truth that runs through all of them: the systems will fail, and the edge belongs to whoever can still work when they do.