A few days ago I mentioned "AI fasting" on LinkedIn and barely explained what I meant. People understandably had questions. Was I against AI? Why would a software engineer choose to work more slowly? This is the longer answer, based on what changed in my own work.
When AI became too comfortable
When I started using AI heavily as a software engineer, the benefit was obvious. I debugged faster, cleaned up code more easily, and moved through difficult problems in less time. Faster felt better, so I kept handing over more of the work.
Somewhere along the way, I started shipping code that I could not recall clearly a week later. Parts of my own project felt like someone else's work. The mental map of the codebase had started to blur. The output still looked fine, which made the problem easy to miss. I was producing code without building the same level of understanding.
Then something more personal hit. My English writing got worse. Not dramatically. Nobody pointed it out; I just felt it. 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 it was getting weaker.
Psychologists use the term Google Effect for a familiar memory trade. When information is easy to look up, people are less likely to remember the information itself and more likely to remember where to find it. AI can also take over the reasoning between the question and the answer. That is the part I had stopped practising.
Cognitive offloading is related. It means moving part of a mental task outside your head so your brain does less of the work itself. Instead of holding a shopping list in memory, you write it down. Instead of doing long division by hand, you use a calculator. Instead of remembering a meeting time, you set a reminder. The thinking still happens, but some of the load sits on paper, a device, or another system.
We have always done this. The brain is the most power-hungry organ in the body, so it prefers to spend less energy when it can. That is not inherently harmful. In many cases it is smart: offloading frees attention for harder work.
AI can take on more than storage or retrieval. It can structure a problem and propose the reasoning too. If I accept that work without following it, I save time now but understand less later. The phrase cognitive debt describes that trade: each skipped decision makes the next round of independent thinking a little harder.
I started asking other developers
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 Reddit threads where developers talked about their workflows. I reached out to other engineers in my network. What I found was a pattern. People described the same thing in different words: faster output, weaker ownership. More code written, less code 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 in the numbers. Productivity metrics looked healthy on the surface. But deeper indicators (understanding of system architecture, ability to debug without assistance, confidence explaining design decisions) were trending the wrong way.
My experience was personal, and the survey was still preliminary, so I do not want to turn it into a universal claim. But it gave me a better question: what do we lose when we judge an AI workflow only by how much it produces?
The night the internet went out
The real turning point was unplanned. One night my internet stopped working. Nothing dramatic, just the ordinary frustration that sends you to the router twice before you give 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 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.
That night made the problem less dramatic and more manageable. I had not forgotten how to work. I was simply out of practice. When the internet came back, I decided to keep a small part of my week that way on purpose.
What AI fasting looks like
The idea is simple. You have 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. Intermittent fasting supports physical health.
I started doing something similar with AI.
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. That discomfort turned out to be useful. It showed 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 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 matters most in practice.
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 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.
This keeps me familiar with the project, and it also makes the later AI work cheaper. I can point to the right files and describe the change precisely instead of asking the model to search and guess. Knowing the codebase helps whether I am working alone or with AI.
Beyond engineering
I suggested AI fasting to a friend who works in development and had become similarly dependent on AI tools. He was skeptical. Why would he deliberately slow himself down? He tried it for two weeks anyway. His work was not suddenly faster or more difficult. He simply felt more present. He was thinking through problems again and learning from what he built.
That distinction applies outside engineering. A student can get a correct answer from AI without doing the work that turns an answer into understanding. Sitting with confusion is frustrating, but it is often where the mental model forms. Remove all of that friction and the assignment may improve while the learning gets thinner.
For professionals across disciplines (writers, designers, analysts, teachers), the risk is similar. AI can make your output look sharp while your underlying thinking gets thin and dependent. Depth is what makes expertise valuable. It is what lets you make good judgment calls in complex situations, catch errors in AI-generated output, and mentor others. Outsource the thinking long enough and the depth drains away.
The risk I care about
Most conversations about AI risk eventually reach jobs and replacement. My concern here is smaller and closer to home: I do not want daily convenience to weaken the habits my work depends on. I still need to hold a complex system in my head, reason without a prompt, and turn a half-formed thought into a clear sentence.
AI fasting is a small practice: one day a week, or even a few hours, without assistance. I am not rejecting AI. I am trying to keep enough command of my codebase and craft to direct the tool precisely, verify its output, and catch its mistakes. I should still be able to explain the decisions when the model is gone.
The weekly pause costs me a few hours of speed. So far, the trade feels worth it. I return to AI with a clearer idea of what I want it to do, and with more confidence that I can catch it when it is wrong.