The Dev Tool I Quit For A Year

On the second Sunday of January 2025 I was sitting at my kitchen table in a rented house in Porto, the one with the blue-tiled stairwell and the window that doesn't quite close. My partner had gone to the market. There was a half-finished cup of coffee on a coaster shaped like a fish. My laptop was open to the VS Code settings JSON, and I had the cursor blinking next to a line that read "github.copilot.enable": { "*": true }. I was about to change the true to false.

I'd been using Copilot since the beta in 2021. By that Sunday it had been part of my hands for almost four years. I didn't think about it. I'd type a function name, see the grey ghost text, hit tab, and keep going. I'd write a comment that described what I wanted, and a function would appear. The first time it happened in 2021 I laughed out loud in a coworking space and a stranger turned around. By 2025 I didn't laugh. I just tabbed.

What pushed me wasn't a productivity guru's blog post or some clean philosophical objection. It was smaller and more embarrassing. The week before, I'd shipped a small bug in production — a regex that matched email addresses the way Copilot suggested, which was close enough to be useful and wrong enough to drop the plus-sign aliases that about 4% of our users used. The bug was a one-line fix. The thing that bothered me wasn't the bug. It was that I'd read the regex when I tabbed it in, decided it looked right, and never actually checked. I didn't know what was in my own pull request. I'd reviewed it the way you skim a contract you've already signed.

So I changed the true to false, saved the file, and closed the laptop. I'd already told my team I was doing this. I'd already written, in a Notion doc nobody asked for, that I'd keep Copilot off for a year — no inline completions, no autocomplete-from-the-model, nothing that wrote code I hadn't typed. I'd allowed myself one exception: the chat sidebar, for design discussions. Not 'write me this function.' More like 'here's three approaches I'm considering, what am I missing.' Conversation, not autocomplete.

I drank the rest of the coffee. It had gone cold. I went for a walk along the river and thought about how, in twelve months, I'd write a smug blog post about how I'd become a better engineer by typing every character myself. I planned the title. I planned the lede. I was wrong about almost everything I'd write. Here is the actual post.

The first six weeks were ugly

I want to say I felt clearer immediately. I didn't. The first week felt like writing left-handed. My fingers kept stopping in the spot where ghost text used to appear, like a dog pausing at a closed door it expected to be open. I'd type array. and freeze, because for years the autocomplete had been finishing the thought. Now I had to finish it. And here's the embarrassing part: half the time I had to think about whether I wanted .map, .filter, .reduce, or .flatMap. Not because I didn't know what they did. Because I hadn't been choosing between them. The tool had been choosing, and I'd been ratifying.

By week three I'd noticed something specific. I was writing fewer lines per day. Maybe 40% fewer. But I was also opening fewer pull requests because the ones I was opening didn't need a second pass. The little revision loop — write fast, review, find the bug Copilot helped me write, fix it, push again — that loop had been invisible to me. I'd thought of it as 'just iterating.' Removing the first half of the loop made the second half mostly unnecessary.

By week six I'd stopped flinching at the missing ghost text. My typing speed came back. The function names I was choosing got shorter. I noticed that I was reaching for the standard library more than I used to. Not because I'd decided to. Because when you have to type out Array.from(new Set(items)) you start to wonder if there's a one-liner, and you go look, and then you remember it. Copilot had been remembering for me. Which meant I wasn't remembering.

What I lost and what I gained

Let me be honest about the losses, because the gain-only version of this story is the dishonest version.

• I shipped less boilerplate. When you have to type every line of a CRUD form by hand, you write fewer CRUD forms. Sometimes this was good — I extracted abstractions I'd been avoiding because tab-completing the duplicate was easier than refactoring. Sometimes it was bad. I put off a small admin tool for two months because I dreaded the typing. With Copilot I'd have shipped it on a Tuesday afternoon.
• Test scaffolding became a chore. Writing the third 'it should return an empty array when input is empty' by hand is tedious in a way that writing the first one isn't. I caught myself writing fewer edge-case tests. I had to consciously force myself to keep doing them, which is a tax I'd forgotten I used to pay before the tool started paying it for me.
• Onboarding to new libraries got slower. The first day with a new ORM or HTTP client, Copilot is basically a fuzzy autocomplete for the API surface. Without it I read more docs. Reading docs is slower than reading Copilot's guess at the docs, but the docs are right and Copilot's guess is sometimes a hallucinated method that almost-exists. So slower, but with fewer dead-ends. Net was a wash, maybe slight loss in calendar time, slight gain in retained knowledge.
• My commit graph got patchier. I'd have weeks where I shipped almost nothing and weeks where I shipped a lot. The averaging that Copilot did — every day a steady drip of small PRs — went away. This bothered my manager less than it bothered me. She had to look at the actual work to evaluate it, which was, in retrospect, how it should always have been.

The gains were quieter. They didn't show up in any metric I could screenshot. The biggest one is hard to articulate without sounding mystical, so I'll just say it plainly: I started knowing what was in my own code again. Not in a vague 'I wrote it' way. In a specific 'I can tell you, without looking, what that function does and why I made that choice' way. When a reviewer asked why I'd used a Map instead of a Record, I had an answer. The answer was sometimes 'I don't remember,' but it was almost never 'because the tool suggested it.'

The second gain was about reading code. I'd been a worse reader of code than I'd realized. With autocomplete on, I read code the way you read a recipe — scanning for the next step. With autocomplete off, I read code the way you read a contract — actually parsing the clauses. This carried over into reviewing other people's PRs. I started catching bugs in review that I'd previously have missed. Not because I got smarter. Because I was finally paying the kind of attention that the work required.

The middle months were where the dogma kicked in

Around month four I went through a phase I'm not proud of. I became the guy in the engineering channel who'd post things like 'just so we're clear, I think AI autocomplete is making us all worse engineers' under any post that mentioned Cursor. I started journaling about my keystrokes. I wrote a 1,800-word internal memo titled 'Attention as a First-Class Engineering Concern' which I sent to nobody, thank god. I bought a paper notebook and wrote out function signatures longhand before typing them, as if I were a medieval scribe and JavaScript were Latin.

This was productivity theater wearing the costume of anti-productivity theater. It was just as much of a distraction as the thing I'd quit. I was making the experiment the point. The experiment was supposed to be a probe; I'd turned it into an identity.

What snapped me out of it was a conversation with an old coworker over coffee in Lisbon — she was visiting for a weekend — who listened to me explain my year for about ten minutes and then said, in the kind voice you use with children, 'It sounds like you're doing the opposite of the thing you said you didn't like.' Which was true. The dogma was just the inline completion of opinions. Tab, tab, tab — same shape, different output.

The last three months were the interesting ones

Once I dropped the dogma I started actually paying attention to what I'd actually changed. Not the rules — the habits. There were habits underneath the rules that the rules had been mistaking themselves for.

The habit was: when I write code, I read it first. I run through it in my head. I notice what could be wrong with it. That habit didn't require Copilot to be off. It required me to be on. The tool was incidental. What had happened in my first four years with Copilot was that I'd let the tool's speed dictate my reading speed, and my reading speed had drifted below my comprehension speed. The fix wasn't 'no tool.' The fix was 'read at comprehension speed regardless of what the tool is offering.'

I started doing small experiments. I turned Copilot back on for one afternoon, with the rule that I'd slow down my tab-acceptance to the speed at which I could actually read the suggestion. I'd let the ghost text appear, I'd read it as carefully as I'd read a PR diff, and then I'd accept or reject. It felt strange. Like driving with a speed governor. But the output was different from both my old self and my Copilot-off self — fewer keystrokes than the latter, more attention than the former. It was the version of using the tool I'd probably been pretending I was already doing.

The default-on cost nobody talks about

Here's the part I want you to take from this, if you take anything. Modern dev tooling has a default-on cost that we don't price into our reasoning about it. Every tool that auto-completes, auto-formats, auto-imports, auto-deploys, auto-suggests is also auto-deciding. The autoformatter decided where the line break goes. The auto-importer decided which of the three same-named exports to pull in. The autocomplete decided which method to call. The CI pipeline decided that this commit shouldn't ship because a flaky test failed.

Most of these decisions are right. That's why we accept them. We accept them so consistently that we stop noticing they're decisions. They become the medium we work in, like water for fish. And then a few of those decisions turn out to be load-bearing — not in the sense of 'critical infrastructure,' but in the sense of 'a thing your brain stopped doing because the tool was doing it, and now the part of your brain that used to do it has atrophied.'

The atrophy is hard to see from the inside. You don't know you've forgotten how to read code carefully until you spend six weeks reading code carefully again and realize that the muscle came back. You don't know you've stopped choosing between four different stdlib methods until you have to choose, and you realize you had a preference and didn't know it.

I'm not making a moral argument. I'm not saying you should be doing the harder thing because the harder thing builds character. I'm saying: there's a difference between a tool you chose and a tool you accepted. The chosen tools earn their slot. You picked them, you tried alternatives, you have a reason. The accepted tools get used because they were already there when you started. Most of the tooling in a senior engineer's daily life is the second kind. We don't audit it because auditing it is expensive and the tool 'works fine.'

Default-off experiments worth a week each

If you don't want to do a full year — and you probably shouldn't, the dogma phase is real and embarrassing — you can run smaller probes. The point isn't to quit the tool. The point is to spend one week as the person you'd be without it and see what you notice. Some of what you notice will be 'I want this back.' Some will be 'I didn't realize I was leaning on this.' Both are useful.

1. 1.Turn off inline completions for one week. Keep the chat sidebar if you want. The rule is no ghost text. You'll feel it on day one and forget by day five. Pay attention to what your fingers do when they expect a tab and don't get one.
2. 2.Ship without a linter for one week on a small side project. Don't disable the formatter — disable the rule-enforcement parts. Notice which rules you'd been outsourcing your style preferences to, and which ones you actually have opinions about.
3. 3.Deploy from a shell script for one week. No CI, no GitHub Actions. Just a bash file that runs tests, builds, and pushes. You'll discover which parts of your pipeline you actually understand. You'll also discover, possibly, that your pipeline is doing five things you didn't know it was doing.
4. 4.Write commit messages by hand with no template, no AI suggestion, no Conventional Commits enforcement for one week. Just describe what you did, in a sentence, like you're telling a coworker. You'll find that 60% of your commits don't need a structured prefix and the other 40% benefit from one. Most templates flatten the difference.
5. 5.Run tests only on push, not on every save, for one week. Stop the watcher. The constant green-red feedback loop is sometimes great and sometimes a low-grade interruption that prevents you from holding a whole feature in your head at once. Find out which it is for you.
6. 6.Name files without the template generator for one week. No npx create-. No scaffolding script. When you need a new component, make the file, write export function ComponentName() {}, and go. Notice which scaffolding was earning its slot and which was just ceremony.

Pick one. Don't do them all at once — that's the dogma phase, and it doesn't teach you anything. Do one for a week. Write down, at the end of that week, what you noticed. Decide whether to put the tool back or leave it off. Move on.

What I do now, twelve months later

I turned Copilot back on in February 2026. Not the version I'd been using before — a different relationship with the same tool. Here's what that looks like, concretely:

• Inline completions are on, but I read them. Every suggestion gets the same scan I'd give a PR diff. If I can't read it at that speed, I'm typing too fast for the work I'm doing, and the answer is to slow down, not to lean harder on the tool.
• I keep it off when I'm learning something new. New library, new language feature, new pattern — Copilot goes off until I've written it by hand at least three times. After three times I know what I'm looking at, and the autocomplete becomes a typing accelerator instead of a decision-maker.
• The chat sidebar is for design conversations only. 'Here are three ways I could structure this — what trade-offs am I missing?' Not 'write me this function.' I noticed during the year that I think better in dialogue than in monologue, and the chat is a reasonable interlocutor for that, with the caveat that it agrees with you too much.
• I turn it off every Friday afternoon. Not for any deep reason. Just to keep the muscle from atrophying again. It's a sanity check. Like running the fire alarm test.

I'm not anti-tool. I want to be clear about that. The post you might have expected from the title — 'AI autocomplete is making us all worse engineers, here's why I quit forever' — that's not this post. That post is wrong, in my experience. Used carefully, Copilot is a real and meaningful accelerator. The 'used carefully' is doing all the work in that sentence, and the year off was what taught me what carefully meant for me. I don't think I could have learned it without the year off. You might be able to, if you're paying more attention than I was.

What I am is pro-default-audit. I think every developer with more than a couple years of accumulated tooling should, periodically, look at their setup and ask: which of these did I choose, and which did I accept? Of the ones I accepted — which would I miss if I turned them off for a week? Of the ones I'd miss, why? Of the ones I wouldn't miss, why are they still on?

Most of the answers will be boring. The tool was free, it was already there, it's fine. That's a legitimate answer. But the few interesting answers — the ones where you realize you've been outsourcing a decision you actually have opinions about — those are worth the audit. They compound over a career. The people I know whose work I most respect aren't the ones with the most tools. They're the ones whose tools are deliberate, whose defaults are chosen, and who can tell you, when you ask, why the thing on their screen is configured the way it is.

A small note on the directory

When I started this experiment in early 2025 I kept a private list in a markdown file — tools I'd turned off, tools I was thinking about turning off, tools I'd turned back on and why. It was for me. Halfway through the year I realized that almost every developer I knew was running their own version of this, in their own private file or their own head, and none of us were sharing it.

Part of what /dir/dev-tools is, for me, is the public version of that file. It's not a 'best of' list. It's the running ledger — what I tried, what I kept, what I dropped, what I re-adopted in a smaller way. The directory itself isn't opinionated in the way a top-ten post is. It's opinionated in the way a workshop pegboard is — the tools that are up there are up there because they earned their hook. The empty hooks are the interesting part. If you're a developer, the related corner of the directory is /for/developers; if you want the broader map of the whole project, it's at /dir.

I don't think my list should be your list. Your stack is yours. Your defaults are yours. The point isn't to copy my year — it's to find the one tool in your setup that you've been accepting instead of choosing, and to spend a week or a month as the version of yourself that doesn't have it. See what you do with the space.

Back to the kitchen table

It's a Sunday morning in May 2026. I'm at the same kitchen table in the same rented house in Porto — we extended the lease, the landlord still hasn't fixed the window. My partner is at the same market. There's a coffee on the same fish-shaped coaster. My laptop is open to the VS Code settings JSON. Copilot is on. I'm typing a function I've typed a hundred times before — a small async helper for retrying a fetch with exponential backoff — and the ghost text appears, and I read it, slowly, the way I'd read a PR diff, and I notice that it's used Math.pow where I'd have used **, and that the jitter calculation has an off-by-one that wouldn't matter in production but would bother me, and I delete the suggestion and type it myself.

The coffee's still hot. That part's different. I drink it while it's hot now. I don't know if the year taught me that or if I just got older. Both, probably. Most of the things I learned that year turned out to be like that — half about the tool, half about me, impossible to separate cleanly. Which is, I think, what makes them worth keeping.