Six months ago, I went all-in on AI assistants. I installed the plugins, opened the sidebars, and let the autocomplete engine run wild. It felt like magic at the start. I was flying through files, accepting suggestions, and watching functions write themselves. The speed was intoxicating.
Then the friction started. I noticed my workdays felt longer and more draining, yet my actual progress had stalled. I spent hours chasing weird bugs, debugging code I did not write, and trying to understand why a generated helper function worked only eighty percent of the time.
I realized I was spending more time reading and fixing AI code than I would have spent writing it myself. So, I turned it off. I uninstalled the extensions and went back to standard, plain autocomplete. My productivity stayed steady. In fact, it went up, and my stress levels went down.
The Silent Cost of Context Drift
When you write code yourself, you build a mental map of the system. You understand why a variable exists, how data flows through a function, and where the edge cases hide. This mental map is your context. It sits in your working memory while you program.
When you accept an AI completion, you bypass the creation of this mental map. The model spits out fifteen lines of code. It looks correct. The syntax is right, and the variable names match. You press tab, and the code is merged.
But because you did not write those lines, you did not build the mental pathways that connect them to the rest of the application. You skipped the thinking step. This is where context drift begins.
Over a few hours, these tiny gaps in your understanding add up. By afternoon, you are building features on top of a codebase you only partially comprehend. When a bug inevitably shows up, you cannot use your intuition to find it. You have to stop, read the generated code line by line, and construct the mental model you should have built in the first place. You spend hours catching up to your own codebase.
The Friction of "Almost Correct" Code
The hardest bugs to fix are not the ones that crash your application immediately. The hardest bugs are the ones where the code looks correct, runs without errors, but produces the wrong output under specific conditions.
AI models are trained to produce plausible-looking code. They are designed to predict the next token, not to verify mathematical correctness or system state. This means they are incredibly good at generating code that looks exactly like what you need, but contains subtle logical flaws.
For example, I recently asked an assistant to write a utility function to parse a custom date format and handle timezone offsets. The generated code looked perfect. It handled leap years, format variations, and string validation.
But under load, we noticed a memory leak. The model had used a regex engine feature that caused catastrophic backtracking on specific inputs. It took our team two days to isolate the issue. If I had written the parser myself, I would have used a simpler, split-based approach that avoided regex entirely.
This is the friction of the almost-correct code. You save five minutes on the initial write, only to pay for it with hours of debugging later. The speed gains are front-loaded, while the maintenance costs are back-loaded.
The Tax of Review Fatigue
Reading code is harder than writing it. It requires more focus to audit someone else's logic than to express your own. Using an AI assistant turns your job from a writer into a full-time code reviewer.
Every suggestion is a pull request from an incredibly fast developer who has no concept of long-term maintenance. You have to check every line. You have to make sure the array index is safe, the helper handles null values, and the model did not invent a utility method that does not exist in your dependencies.
In the morning, your mind is fresh. You catch the subtle bugs. You reject completions that use old APIs.
But by mid-afternoon, review fatigue sets in. You have looked at hundreds of suggestions. Your brain gets tired of playing spot-the-difference with the editor. You start hitting the tab key without fully verifying the output. You tell yourself that you will catch any issues during manual testing.
This is how technical debt creeps in. You trade your cognitive energy for raw typing speed. The result is a codebase full of micro-bugs and redundant logic that you have to clean up later.
The Illusion of Raw Output
AI tools are great at generating boilerplate. If you need a basic router or a mock data schema, the model can write it in seconds. This speed creates a loop of instant gratification. You feel highly productive because code is filling the screen.
But typing is rarely the bottleneck in software development. The real work is thinking and system design.
When you write code manually, the physical act of typing acts as a natural speed limiter. It forces your brain to slow down. While you are typing out a loop, your mind is evaluating if there is a cleaner way to structure the data. You are planning the next architectural step.
With autocomplete, you skip this planning phase. You accept the first working solution that appears. You end up with complex, bloated systems because you never took the time to ask if that code needed to exist at all. The cleanest code is the code you did not have to write.
Reclaiming Flow State
Writing software requires deep focus. You need to get into a flow state where the code feels like a direct extension of your thoughts.
AI assistants are a source of constant interruption. The flashing grey text of autocomplete suggestions pulls your attention away from your current thought process. You try to write a specific logic flow, but the model keeps suggesting its own ideas. You have to stop, evaluate its suggestion, reject it, and try to find your place again.
This constant switching, even if it only takes a fraction of a second, prevents you from entering a deep flow state. It makes programming feel fragmented and exhausting.
Once I disabled the inline completions, the silence was immediate. I could think about a problem for ten minutes without my editor trying to finish my sentences. I wrote fewer lines of code, but the lines I wrote were clean and intentional.
How I Use AI Now
I still use LLMs, but my relationship with them changed. They are now reference manuals.
I do not let AI write code inside my editor. I disabled all inline completions.
Instead, I use LLMs in a separate browser window for isolated tasks:
- Writing complex regular expressions that would take me twenty minutes to look up.
- Generating mock data schemas for testing.
- Explaining obscure compiler errors or legacy configurations.
- Asking for alternative approaches to a specific algorithmic problem.
By keeping the AI outside of my active workspace, I keep a clear boundary. I am the driver. The AI is a lookup tool, similar to Stack Overflow or documentation search, but faster. I write the code, and I own the context.
The Value of the Hard Way
We are told that the future of development is about prompt engineering and assembling pre-built blocks of code. But there is a reason we learn things the hard way.
Typing out the code and debugging errors is how we build intuition. If you outsource the typing, you outsource the learning. Over time, your skills start to rust. You become dependent on the tool to solve even basic problems.
If you feel like you are running faster but getting nowhere, try turning off your AI assistant for a week. You might find that writing code yourself is not as slow as you remember. In fact, it might be the fastest way to build software that actually works.
