I Stopped Using AI for a Week of Coding. Here's What I Actually Lost.

It was a Monday, and I noticed something about myself that I didn't love. I'd opened the editor, written maybe nine lines, hit a type error I didn't immediately understand — and my hand had already moved to the other window. Not after thinking about it. Before thinking about it. The gap between "problem appears" and "ask a machine" had shrunk to something under two seconds, and at no point in that sequence had I actually looked at the error. So I stopped using AI for a week of coding, mostly to find out whether the reflex was earning its keep or just replacing a skill I used to have.

Why I Ran This Experiment

I want to be upfront: this was not an anti-AI stunt. I like these tools. I pay for two of them. I spent a whole separate month timing exactly how many hours AI actually saves me, and nothing that happened this week contradicted those numbers.

What prompted it was a smaller, more specific worry. Somewhere in the last eighteen months, AI coding assistants had stopped being something I used and become something I did. There's a difference. A tool you use, you reach for on purpose. A habit, you perform. And I'd caught myself performing — asking questions I already knew the answer to, generating five lines it would have taken me forty seconds to type, pasting stack traces into a chat window before reading them.

The uncomfortable question underneath that was simple. If the assistants vanished tomorrow, what would happen to my output? I genuinely didn't know. And not knowing the answer to that felt worse than any answer would have.

So the goal wasn't to prove that coding without AI is superior. It was measurement. I wanted a number, or at least an honest impression, of what these tools were actually doing for my developer productivity — separated from the feeling that they were doing a lot.

My Ground Rules

I set the rules on Sunday night, deliberately, because I knew that if I left them vague I'd negotiate with myself by Wednesday.

Not allowed for seven days:

• ChatGPT, Claude, Gemini, or any chat assistant — for anything code-related
• GitHub Copilot and every other AI autocomplete, disabled at the extension level rather than just ignored
• Cursor's AI features, which meant going back to plain VS Code to remove the temptation entirely
• AI commit message generation
• AI-powered search summaries — I turned off the generated answer block where I could

Explicitly allowed:

• Official documentation — MDN Web Docs, the Python docs, React and Node documentation, Microsoft Learn
• Stack Overflow, including old answers
• GitHub issues and source code of libraries I was using
• Books on my shelf, blog posts, ordinary web search
• Regular IntelliSense and type-based autocomplete, since that's a language server, not a model

That last distinction mattered more than I expected. I wasn't trying to simulate 2009. I was trying to remove the thing that answers questions for me while keeping the things that help me answer them myself.

One more rule: no cheating by front-loading. I didn't spend Sunday generating a week's worth of boilerplate in advance, which I'll admit occurred to me around 10pm.

What My Workflow Looked Like Before

To make sense of the loss, here's an honest inventory of where AI had embedded itself in my week. I wrote this list before starting, and it was longer than I anticipated.

Regex. Total dependency. I hadn't written a non-trivial regular expression from memory in well over a year. I could read them fine. Producing them was a different skill and it had quietly gone.

SQL. Simple queries myself, anything with a window function or three joins went to the assistant.

Shell and Docker. Anything beyond common commands. Multi-stage Dockerfiles, awk one-liners, tar flags I've looked up two hundred times and never retained.

Boilerplate. Express route handlers, React component shells, TypeScript interfaces from a JSON payload, test scaffolding. This was the highest-volume use by a wide margin.

Unfamiliar APIs. Rather than reading a library's docs, I'd describe what I wanted and get working code. Fast. Also, in hindsight, the habit I'd most regret.

Debugging. Paste the stack trace, get a hypothesis. Often right. Sometimes confidently wrong in a way that cost me an hour.

Naming things and commit messages. Small, but constant.

Written down like that, it's a lot of surface area. No wonder the week felt daunting.

Day 1 — Muscle Memory Is Not a Metaphor

The first day was almost comic. I reached for the assistant eleven times before lunch. I know it was eleven because I started marking them on a sticky note after the third, and the marks are still on my desk.

The reaches weren't for hard problems. That's what stung. The first one was to ask how to reverse an array in JavaScript. I know how to reverse an array in JavaScript. I've known for a decade. But some part of my process had decided that recall was optional now, and typing a question was cheaper than remembering.

The Copilot absence was physically strange. You don't realise how much you've come to expect grey text ahead of your cursor until it isn't there. I'd type a function signature and then just... sit there. Waiting for a suggestion that wasn't coming. Several times I paused mid-line as if the editor had frozen.

Productivity on day one was bad. I'd estimate I got through about 60% of a normal day's work, and I was irritable about it. The task was a moderately dull one — adding a set of endpoints to an existing Express service — and without generated scaffolding, every route felt like manual labour.

I went to bed convinced the experiment would prove that AI saves enormous time. That conviction lasted about thirty-six hours.

Day 2 — Documentation Became My Assistant

Tuesday I stopped fighting it and changed strategy. Instead of trying to remember things, I opened documentation and left it open.

This sounds trivial. It wasn't, because I'd forgotten how good documentation has become. MDN in particular is superb now — I spent twenty minutes on the Intl.DateTimeFormat page and came away understanding date formatting properly rather than possessing one working snippet. The Node docs on streams, which I'd been avoiding for years, turned out to be clear and well-organised. React's documentation had been rewritten since I last read it seriously, and the section on effects answered a question I'd asked an assistant three separate times without ever retaining the answer.

That's the pattern I want to flag. When AI gave me an answer, I got the answer. When I read documentation, I got the answer plus a map of the surrounding area — the related methods, the caveats, the note about browser support I wouldn't have thought to ask about.

The cost is real though. Reading docs is slower per question. Substantially. A three-line answer I'd have received instantly took eight minutes to locate and absorb. Multiply that across a day and the arithmetic isn't flattering.

But by evening, something had shifted. I was reaching for the assistant less because I was reaching for it out of habit less. Only four sticky-note marks on Tuesday, down from eleven.

Day 3 — Debugging Felt Genuinely Different

Wednesday I hit a real bug. A test that passed locally and failed in CI, which is the flavour of bug I find most demoralising.

My instinct — deeply established — was to paste the CI logs into a chat and ask what was wrong. I couldn't. So I did the thing I used to do, which was to read the logs.

Actually read them. All of them, top to bottom, including the part I normally scroll past. The answer was in there, about forty lines above the failure, in a warning about a timezone-dependent assertion. It took me maybe twelve minutes to find, and I want to be honest: an assistant would likely have found it in one. This was not a productivity win.

What it was, was a reminder of a process I'd let atrophy. Over Wednesday and Thursday I fell back into the old rhythms — forming a hypothesis before touching the keyboard, setting a breakpoint rather than scattering log statements, bisecting the problem space by commenting out half the change and re-running. Binary search debugging is unglamorous and it works almost every time.

By the end of the week I was locating bugs faster than at the start. Not faster than with AI, necessarily. But faster than my week-one self, which suggests the skill had been sitting there rusting rather than gone.

The other difference was ownership. When I found a bug myself I understood why it happened, which meant I could reason about whether it existed elsewhere in the codebase. Twice it did. An AI hypothesis fixes the instance; understanding fixes the class.

Day 4 — Boilerplate Was Genuinely Painful

Thursday was the worst day and it wasn't close.

The task was unremarkable: scaffold a new feature module. Six Express routes, matching TypeScript interfaces, a React component per screen, and a test file for each. This is exactly the work AI is best at, and doing it by hand was like being asked to copy out a page of a phone book.

The TypeScript interfaces were the sharpest pain. I had a sample JSON response with about forty fields including three levels of nesting. With an assistant, that's a paste and a keystroke. By hand it took me a little over half an hour, and I made two typos I didn't catch until the compiler complained.

Tests were similar. Not the assertions — those need thought and I don't mind writing them — but the setup, the mocks, the describe blocks, all the ceremony around the three lines that matter.

I noted something that afternoon which I still believe: the tasks AI saves the most time on are the tasks that teach you the least. That's not an accident. Predictable, mechanical work is exactly what a model predicts well, and it's exactly what your brain gains nothing from repeating. The overlap is close to total.

Which is a fairly strong argument for using AI, honestly. Just not the argument I set out expecting to make.

Day 5 — I Started Thinking Before Typing

Friday is when the experiment stopped feeling like deprivation.

The change was in sequencing. With an assistant available, my process had become: encounter problem, describe problem, evaluate response. Without one, it became: encounter problem, think about problem, form approach, then execute.

That middle step had been getting skipped for a long time, and I hadn't noticed because the outcomes were mostly fine. Describing a problem well to an AI does require some thought. But it's a different, shallower kind of thought than working out the shape of a solution yourself.

On Friday I had to design a caching layer for something. Ordinarily I'd have discussed options with an assistant and picked one from the menu. Instead I got a notebook out — actual paper — and sketched three approaches, then argued myself out of two of them.

The design I ended up with was, I suspect, slightly worse than what I'd have gotten from a good conversation with Claude. It was also entirely mine, meaning I could defend every decision in it and I'll still understand it in six months. There's a version of "worse" that's actually better, and I think this was one.

Memory improved too, in a small measurable way. By Friday I was writing basic regex without looking things up. Nothing exotic — capture groups, character classes, lazy quantifiers — but a week earlier I couldn't have done that, and the skill hadn't gone anywhere. It just needed to be asked for.

Day 6 — Some Things Were Faster Without AI

Saturday produced the finding I least expected, and it's the reason I think this experiment was worth running.

Several categories of work were not slower at all. A few were marginally faster.

Small bug fixes, for one. When I know roughly where the problem is, the fix takes ninety seconds. Involving an assistant meant describing the context, reading a suggestion, deciding whether it fit my codebase's conventions, and adapting it. That review step isn't free. For small changes it frequently cost more than it saved.

Refactoring was the same story. Renaming, extracting functions, restructuring a module — my editor's built-in refactoring tools do this deterministically and correctly. AI suggestions for refactors need verification precisely because they're plausible rather than guaranteed.

Reading existing code was the clearest case. I'd fallen into the habit of asking for a summary of unfamiliar files. It's fast and it produces a feeling of understanding. Reading the file myself is slower and produces actual understanding, including the odd bit that the summary would have smoothed over. The summary tells you what the code does. Reading it tells you what the previous developer was worried about, which is often more useful.

There's a real cost to AI that nobody puts in the marketing: every generated suggestion is a code review you now have to perform. When the task is big, that trade is excellent. When it's small, it's a losing one.

Day 7 — What I Missed and What I Didn't

By Sunday the withdrawal was over. Zero reaches for the assistant. I'd stopped expecting grey text.

What I genuinely missed, in order:

1. Boilerplate generation. Badly. Every day.
2. Regex. Sat down with the docs and got there, but slowly.
3. Explaining unfamiliar error messages from libraries with poor documentation.
4. Complex SQL, particularly window functions.
5. Quick orientation in a library I'd never touched.

What I didn't miss at all:

1. Debugging. Better without it, for me.
2. Architecture and design decisions.
3. Small edits and fixes.
4. Commit messages, which took eight seconds and were more accurate.
5. Naming things — I'd been outsourcing a judgement call that's genuinely mine to make.

What I Actually Lost: The Numbers

These are estimates from my own timing across the week, compared against my normal pace on similar work. They're honest but they're not laboratory-grade — one developer, one week, one codebase. Treat them as a shape, not a measurement.

Fifteen to twenty percent. I'd predicted fifty.

The gap between those two numbers is the whole story of this experiment. My sense of dependency was far larger than my actual dependency, and I suspect that's true for a lot of developers. Losing a fifth of your throughput is a real cost that I wouldn't accept permanently. It is also not the catastrophe the reflex implied.

What I Actually Gained

The gains are harder to tabulate, which is exactly why they're easy to undervalue.

Deeper understanding of my own stack. A week of reading documentation left me knowing things about Node streams and React's effect model that I'd been vaguely gesturing at for years.

Better debugging instincts. The clearest gain. Hypothesis first, keyboard second.

Far less context switching. I hadn't counted the cost of the browser tab. Every AI query is a small exit from the problem, and coming back always costs something. Some days I stayed in the editor for two hours straight, which hadn't happened in a long time.

Recall came back quickly. Within days, not weeks. That was reassuring — the knowledge hadn't been deleted, just filed somewhere I'd stopped visiting.

Confidence. Slightly embarrassing to admit, but I'd developed a low-grade anxiety about whether I could still do this job unaided. I can. It's slower. It's fine.

Thinking before asking. The habit I most wanted back, and the one that survived the return to normal.

The Biggest Surprise

Here's the thing I keep returning to.

I'd assumed AI was giving me a broad, general uplift — that everything was maybe 30 or 40 percent faster across the board. It isn't. The benefit is enormously concentrated. Something like 80 percent of the time I lost came from a handful of task types: boilerplate, regex, config, SQL, and unfamiliar APIs. Everything else was close to a wash.

That reframes the tools entirely. AI coding assistants aren't a general accelerant. They're a specialised one, extremely effective in a narrow band of predictable work, and roughly neutral elsewhere.

Which means the honest question isn't "should I use AI for coding" — it's "am I using it inside the band where it actually pays?" For a good portion of my week, I wasn't. I was using it everywhere, because the habit doesn't distinguish between tasks. That was the real finding, and it's a criticism of my usage rather than of the tools.

Where AI Is Genuinely Worth Using

After the week, here's where I've deliberately kept it. The common thread is that verification is cheap — if the answer's wrong, I find out in seconds.

• Boilerplate and scaffolding. No hesitation. It's the strongest case by a distance.
• Regex. Generate it, then test it against real inputs. Always test it.
• SQL beyond the basics. Read the query plan afterwards.
• Test scaffolding. The ceremony, not the assertions. I still write those.
• Explaining error messages, especially from libraries with thin documentation.
• Configuration files — Docker, CI pipelines, build tooling. Verify by running them.
• Mechanical migrations between two well-known formats or framework versions.
• First orientation in an unfamiliar library, followed by actually reading the docs.
• Code review of my own work. A genuinely good use I underrated — it catches things I'm blind to.

One caveat on all of the above: the quality of what you get back tracks the quality of what you ask for far more than it tracks which model you're on. Half the cases where I'd previously blamed a tool for a bad answer were really cases of a lazy question, which is something I worked through in more detail in this piece on writing prompts that actually work.

Where I've Stopped Using It

• Learning anything new. If I want to keep it, I read the primary source.
• First-pass debugging. I read the trace myself before asking anyone, human or otherwise.
• Algorithms and data structures. The struggle is the entire point.
• Architecture and design decisions. I'll discuss, but I won't accept a recommendation I couldn't have reached myself.
• Interview preparation. Practising with a safety net you won't have on the day is self-deception — a point I made at more length in the coding interview prep piece.
• Naming things. Small, but it's a judgement about meaning, and that's my job.
• Anything under two minutes. The review overhead swallows the gain.

If You Want to Try This Yourself

Twelve things I'd tell someone attempting the same week.

1. Disable, don't resist. Turn the extension off properly. Willpower loses to muscle memory every time.

2. Bookmark your documentation first. Have MDN, your language docs and your framework docs one keystroke away before day one.

3. Expect day one to be terrible. It's withdrawal, not evidence. Judge the experiment from day three onward.

4. Count your reaches. A sticky note and a pen. The number itself is the most useful data you'll collect.

5. Time a few representative tasks. Rough numbers beat impressions, and impressions are wildly unreliable here.

6. Keep a debugging journal. One line per bug: symptom, hypothesis, actual cause. You'll spot your own patterns within days.

7. Pick a normal week. Not a crunch week, not a quiet one. A deadline will make you rationalise your way out by Tuesday.

8. Write explanations of what you build. A paragraph in your own words is a brutal test of whether you actually understood it.

9. Don't half-cheat. AI-generated search summaries count. So does asking a colleague to ask an assistant for you, which I thought about on Thursday.

10. Don't measure yourself against your AI-assisted pace daily. You'll feel slow because you are slow, and that misses the point of the exercise.

11. Read one library's source code. Pick something you use constantly and open it up. This was the single most educational hour of my week.

12. Plan what you'll keep. Decide before you finish which habits are coming back and which aren't. Otherwise the reflex simply resumes on day eight.

Frequently Asked Questions

Is coding without AI still realistic in 2026?

Completely realistic, just slower on certain categories of work. Across my week I finished everything I'd planned, roughly a day and a half behind schedule, and the delay was concentrated almost entirely in boilerplate and syntax I could have looked up but chose to reconstruct from memory. Nothing became impossible. Documentation is better than it has ever been, Stack Overflow still answers the awkward questions, and the debugger has not gotten worse. If your job disappeared the moment your assistant went offline, that's worth knowing about yourself.

Does using AI reduce your programming skills?

It doesn't erase what you know, but it does let specific skills go quiet from disuse. The ones that faded fastest for me were recall-based: regex syntax, less common Git commands, the exact shape of a Docker healthcheck block. Those came back within days. What worried me more was a subtler habit — reaching for an answer before I'd finished forming the question. That's not a skill loss so much as a thinking loss, and it took the whole week to notice properly.

Should beginners avoid AI coding assistants?

Not avoid, but delay and ration. The problem for beginners isn't that AI writes bad code — often it writes better code than they would. The problem is that accepting a correct solution you can't evaluate teaches you nothing, and programming is largely the skill of evaluating solutions. A reasonable compromise is to attempt everything yourself first, then use AI as a reviewer or explainer afterwards. You keep the learning and still get the feedback loop.

How much slower is manual coding without AI?

For me, roughly 15 to 20 percent slower overall across a normal working week — much less than the 50 percent I'd braced for. The average hides enormous variance though. Boilerplate-heavy tasks took two to three times longer. Regex and unfamiliar API integration were dramatically slower. Meanwhile small bug fixes, refactoring and reading existing code were essentially unchanged, and a few were marginally faster because I wasn't reviewing generated suggestions.

Is GitHub Copilot worth it for professional developers?

For most professionals doing production work, yes — the repetitive typing it removes is real and it compounds daily. The value is highest in codebases with heavy conventions, where the next twelve lines are genuinely predictable. It's lowest when you're solving something novel, because that's exactly when a confident wrong suggestion is most expensive. My week convinced me the tool is worth its cost and also that turning it off occasionally is worth the inconvenience.

Can experienced developers safely rely on AI assistants?

Experience is exactly what makes reliance safe, because reviewing generated code well requires knowing what good looks like. The risk for senior developers is different: it's drift. You stop reading documentation because summaries are faster, and slowly your mental model of a framework becomes second-hand. I noticed that in myself with a library I'd used for two years and could not describe accurately without help. That's a quieter problem than bad code, and harder to catch.

Will AI replace software engineers?

Nothing in my week suggested that. What AI removed from my day was typing, lookup and recall — genuinely useful to remove, and not the part of the job anyone was paying me for. What remained was deciding what to build, choosing between imperfect approaches, understanding why a system behaved unexpectedly, and taking responsibility for the result. The job is shifting toward specification and review rather than production, which is a real change worth preparing for, but it isn't replacement.

Should students practice coding without AI?

Yes, deliberately and regularly. Interviews are still largely unassisted, but that's the smaller reason. The larger one is that struggling with a problem for twenty minutes builds a kind of durable understanding that reading a correct answer simply does not produce. You don't need to be a purist about it — a few unassisted hours a week is enough to keep the muscle alive. Treat it like practising scales rather than a moral position.

What coding tasks is AI genuinely best at?

Anything repetitive, well-specified and easy to verify. Regex, SQL joins, test scaffolding, config files, data transformation scripts, migration between two known formats, and explaining an error message you've never seen. The common thread is that you can check the output quickly, so a wrong answer costs seconds rather than hours. Tasks that fail that test — architecture decisions, subtle concurrency bugs, anything where being wrong is expensive and hard to detect — are where I'd rather do the thinking myself.

Did coding without AI improve my debugging?

More than anything else in the experiment. Without the option of pasting a stack trace somewhere, I went back to reading it line by line, setting breakpoints, and bisecting the problem space. By midweek I was locating bugs noticeably faster than I had been, because I was forming a hypothesis before touching the keyboard rather than outsourcing that step. That habit is the single thing I kept after the week ended.

What about AI autocomplete versus chat assistants — is one worse for skills?

Autocomplete was harder to give up and, I think, the more habit-forming of the two. A chat assistant requires you to stop and articulate a problem, which is at least a small act of thinking. Inline autocomplete inserts itself into the moment before thought, which is why day one felt so disorienting. If you only turn off one thing as an experiment, turn off the autocomplete — it's the more revealing half.

The Honest Verdict

I didn't quit AI. On Monday morning I turned everything back on, and I have no plans to run this week again soon.

But I came back using it differently, which was the actual point. The assistants are on for boilerplate, config, regex, SQL and the mechanical work that fills the gaps between the interesting parts. They're off — deliberately off — for debugging first passes, for learning, and for anything where I'd rather understand the answer than have it.

The measured loss was 15 to 20 percent of my throughput. Real, but survivable, and concentrated in a narrow band of work I don't especially enjoy anyway. That's a strong case for the tools. What it isn't is a case for using them reflexively on everything, which is what I'd drifted into without noticing.

If I had to name the thing I lost that mattered most, it wasn't productivity at all. It was the assumption that I couldn't do this without help. That assumption had been quietly growing for a year and a half, and it turned out to be false — expensive, but false.

Try a week. Or a day, or an afternoon. Not because AI is bad for you, but because knowing the difference between a tool you use and a habit you perform is worth the inconvenience of finding out.

AI is an excellent assistant and a poor substitute for understanding. The week didn't teach me that — I already believed it. It just showed me how far my actual behaviour had drifted from something I thought I believed.