A few days ago, I posted about a concept on LinkedIn, and I called it “AI Fasting.” I did not explain it well. It was a rough idea thrown into the void, and I did not expect much. But then the questions started coming in: What does it mean? Why is it necessary? Is this some kind of anti-AI movement? I realized the idea had touched something real in people. So let me explain it properly this time. Not as a manifesto. Not as a theory. As a story. My story!
When AI Became Too Comfortable
When I started using AI heavily as a software engineer, it felt genuinely transformative. I could debug faster, structure code more cleanly, and get through complex problems in a fraction of the time. Every tool I picked up made me faster. And faster felt like better, so I kept going deeper.
But somewhere along the way, something quietly shifted. I was shipping code, but I wasn’t always clear on it. I would look at a part of my own project a week later and feel strangely distant from it, as if I were reading someone else’s work. The mental map of the codebase, the one that should live in your head as a working model of everything you have built, it had started to blur. I was producing output without building comprehension, and for a while, I did not notice the difference because the output still looked fine.
Then something more personal hit me. My English writing started getting worse. Not dramatically. Nobody pointed it out; I just felt it myself. I was writing broken, lazy sentences because I knew AI would clean them up. I had stopped putting effort into structure and clarity because the effort was no longer required. The muscle was not being used, and quietly, it was getting weaker. I was producing output without building comprehension, and for a while, I didn’t notice the difference because the output still looked fine.
There is a concept in psychology called the Google Effect. Research has shown that when people know information is easily accessible, through a search engine, for example, they are less likely to store it in their own memory. They remember where to find the answer, not the answer itself. With AI, this effect goes several layers deeper. It is not just that you stop remembering facts. You stop forming the habit of thinking things through. You outsource the reasoning, not just the retrieval.
Cognitive offloading is also a related idea. The practice of using external tools to carry the mental load. We have always done this. Writing things down, using calculators, and setting reminders. Because our brain is the most power-hungry organ in our body. So it always wants to use it efficiently with less calorie consumption. It is not inherently harmful. But AI is a different kind of tool, because it does not just store or retrieve. It processes, structures, and reasons. When you offload those functions entirely and repeatedly, your own capacity for them starts to atrophy. Slowly. Invisibly. Until one day you sit in front of your own codebase and feel like a stranger. This is what researchers call cognitive debt. Every time you outsource a decision or skip the reasoning process, you borrow a little from your own mental capacity. The interest is invisible at first. But it accrues.
It Was Not Just Me
My first instinct was to dismiss this as a personal failing. Maybe I was using AI wrong. Maybe I was just having a rough patch. So I started looking outward. I read through Reddit threads where developers were talking about their workflows. I reached out to other engineers in my network. And what I found was not promising. It was a pattern. People were describing the same thing in different words. Faster output, weaker ownership. More code being written, less code being truly understood.
Around the same time, I was working on a research project about vibe coding, a style of development where you describe what you want to AI and let it generate most of the implementation. I was going through preliminary survey data from software engineers who worked this way, and the pattern was right there in the numbers. Productivity metrics looked healthy on the surface. But deeper indicators, things like understanding of system architecture, ability to debug without assistance, and confidence in explaining design decisions, were trending in the wrong direction.
This was not a personal characteristic. This was something structural happening to a whole category of knowledge workers who had adopted AI quickly and enthusiastically, without pausing to ask what they might be trading away in the process.
The Day the Internet Went Out
The real turning point came from something completely unplanned. One night, my internet stopped working. It was not a dramatic moment, just the kind of ordinary frustration that sends you to the router twice before giving up. But I had code to write. A deadline was sitting there, and I had no AI tools, no documentation lookups, no instant answers.
So I just started writing. Slowly. Recalling things. Thinking through problems step by step, the way I used to, years ago. And something surprising happened. I could do it. It was not effortless, but it was not impossible either. The knowledge was still there. It had just been sitting unused, waiting.
That night clarified something important for me. I had not lost my ability. I had just stopped exercising it. The internet coming back felt less like relief and more like a gentle warning! What would happen if I kept outsourcing until the muscle truly atrophied? That was the day the idea of AI fasting stopped being abstract and became something I actually wanted to practice.
What AI Fasting Actually Looks Like
The idea is simple. You’ve probably heard of intermittent fasting, or even social media fasting, taking a break from platforms for a period of time. I practice both occasionally. Social media fasting helps with mental clarity, while intermittent fasting supports physical health.
Similarly, I started doing something I call AI fasting.
Once a week, for a fixed block of work, I stop using AI entirely. No autocomplete, no code suggestions, no quick explanations, no grammar fixes, just the problem and my own thinking.
At first, it felt slow and uncomfortable, almost unfamiliar. I had forgotten what it was like to sit with a problem without immediately reaching for help. But that discomfort turned out to be valuable. It revealed just how dependent I had become.
After a few weeks, things started coming back. I could visualize my project structure more clearly. I started making decisions more confidently, because I was actually reasoning through them rather than delegating the reasoning. Even my writing sharpened a little. Not dramatically, but I was more deliberate again about how I formed sentences.
Beyond the fasting itself, I also changed how I use AI during normal work. This is the part that I think matters most in practice.
The idea translates simply. At the beginning of any project, I write the core architecture myself. The API client, the base components, the structural decisions, the way I want them, in my own style. I use minimal AI at this stage. Once that foundation exists and I deeply understand it, I let AI handle the repetitive scaling work: adding new features using the patterns I have already established, generating boilerplate that follows my conventions. I keep a context file (skills) that describes how components should behave, and when I point AI to specific files and changes needed, I verify that the output actually follows my style before accepting it.
Two things come from this approach. First, I maintain genuine ownership over the project; I always know what is in there and why. Second, because I am pointing AI to specific locations and giving it precise instructions, its token cost actually goes down. It spends less time guessing (where it should make the changes) and more time generating. So, understanding your codebase does not just protect your cognition; it also makes your AI usage more efficient and cost-effective. I think that, where the token is the new currency, practicing these types of things will help us in the future, eventually.
What This Means Beyond Engineering
I suggested AI fasting to a friend of mine who works in development and had become similarly dependent on AI tools. He was skeptical. His first question was the obvious one: Why would you deliberately slow yourself down? He tried it for two weeks, not entirely convinced. When he came back to me, what he said was not that he had coded faster or solved harder problems. He said he felt more present. He was thinking through problems again instead of just routing them to AI and waiting for output. He was learning from what he built, not just building it.
That distinction matters for everyone who works with knowledge, not just engineers. For students, AI has made it very easy to get answers without doing the cognitive work that turns answers into understanding. The struggle, the part where you sit with confusion and push through it, is not a flaw in the learning process. It is the process. When AI removes that friction entirely, the result is not better learning. It is shallow learning, dressed up as efficiency. You may get the right answer, but you do not build the model in your head that would help you generate the right answer next time, in a different context, without help.
For professionals across disciplines, writers, designers, analysts, and teachers, the risk is similar. AI can make your output look sharp while your underlying thinking becomes dependent and thin. Depth is the thing that makes expertise valuable. It is what lets you make good judgment calls in complex situations, what lets you catch errors in AI-generated output, and what lets you mentor others. Outsource the thinking long enough, and the depth quietly drains away.
The Real Risk Nobody Talks About
There is a version of the AI fear story that gets told constantly, the one about jobs, about automation, about replacement. I am not interested in that story here, because I think it misses the more immediate and personal risk. The real risk, the one that is happening right now to real people who use AI heavily every day, is not dramatic. It does not make headlines. It is the slow, quiet erosion of your own cognitive habits, your ability to hold complex systems in your head, to reason through problems without external scaffolding, to form a clear sentence from a clear thought.
AI fasting is a small thing. One day a week, or even a few hours, where you choose to think without assistance. It is not about rejecting AI or pretending it is not useful. It is about making sure that your intelligence remains the primary engine and AI remains the tool, not the other way around. Because once you have built a strong mental foundation, once you genuinely understand your codebase, your subject, your craft. AI becomes dramatically more useful to you. You can direct it precisely, verify its output meaningfully, and catch its mistakes. You are the senior engineer. AI is the fast but inexperienced junior who needs supervision.
The pause, it turns out, is not time lost. It is the practice that makes everything else sharper.
Written after too many good conversations about cognitive debt, vibe coding, and what it means to actually understand your work. If this resonated, try one day without AI this week, then come back and tell me what you noticed.