Why Developers Are Quietly Turning Off Copilot and Cursor

The Quiet Reversal

A pattern keeps surfacing in Hacker News threads, Lobsters comments, and dev Mastodon: experienced developers turning Copilot off. Not for a podcast take, not as a Luddite stunt — for the work that actually requires understanding. The k10s.dev post that lit up HN this month was the latest, but it joins a year of similar reversals from people who use these tools daily and ship code for a living.

The framing matters. This isn’t “AI bad.” It’s “I noticed I got worse at my job, and I want to figure out why.”

What the measurements actually show

The Model Evaluation and Threat Research group ran a randomized trial in July 2025 with 16 experienced open-source maintainers working on their own repositories. They sampled 246 real tasks and let the developers use Cursor Pro with frontier models on half of them.

Before starting, the developers predicted AI would make them 24% faster. After finishing, they self-reported being 20% faster. The actual measured time told a different story: they were 19% slower.

Sixteen developers is a small sample. The result still matters because it captures something honest power-users notice eventually: the speedup you feel is not the speedup you ship. METR’s debrief points at context-rebuilding overhead. The model generates plausible code; you spend the savings re-reading it, fixing subtle drift, and unwinding design decisions you wouldn’t have made yourself.

A separate Microsoft and Carnegie Mellon paper from early 2025 surveyed 319 knowledge workers across 936 GenAI use cases. The finding most relevant to coding: higher confidence in the AI correlated with less critical thinking effort. Higher confidence in yourself correlated with more. The authors call this cognitive offloading — outsourcing the judgment work along with the typing work. For code, the judgment work is most of the job.

Stack Overflow’s 2024 Developer Survey is the third data point. Roughly 76% of respondents were using or planning to use AI tools in their development process. Only about 43% said they trusted the accuracy. The gap between adoption and trust is the part nobody puts on a vendor slide.

When hand-coding actually wins

Across the HN threads and lobste.rs discussions on this topic, four scenarios show up repeatedly where developers report hand-coding produces better outcomes:

Learning a new language or framework. The retrieval-practice effect is one of the most replicated findings in cognitive science: you retain what you struggle to recall, not what you read. Tab-completing your way through a Rust tutorial gives you the same illusion of competence as highlighting a textbook. Two weeks later, you can’t write the borrow-checker pattern from memory because you never built the recall pathway.

Debugging code you wrote with assistance. This is the sharp edge. Bugs in AI-generated code aren’t usually syntax errors — they’re “I don’t actually know what this function does” errors. If you didn’t build the mental model when the code went in, you have to build it now, under pressure, while the bug is live. The time you saved typing gets refunded with interest.

Designing data models and module boundaries. AI tools default to plausible-looking patterns from training data. They will happily generate a schema that works and is wrong for your system. The choices here compound for years. Hand-thinking, on paper if necessary, is how senior engineers earn their seniority.

Writing code in a domain you intend to own. If you’re the person who will maintain this module for the next two years, the up-front investment in understanding every line pays back constantly. If it’s a one-off script you’ll delete next week, the calculus inverts.

A pragmatic middle path

The developers who’ve thought about this longest don’t quit AI tools — they segment them. The pattern that keeps appearing:

• AI on for boilerplate, scaffolding, well-defined transforms, and shell one-liners. You’re not learning anything from writing the 400th useState hook by hand.
• AI off for design work, learning, debugging, and any code where “I understand exactly what this does” is a hard requirement.
• AI inverted for tests: write the test by hand, let the model write the implementation, then read that implementation as if you were reviewing a junior’s PR.

The hidden variable is metacognition — knowing what you don’t know. The Microsoft study found that workers with weaker self-confidence offloaded the most, which is exactly backwards from what you’d want. Junior developers, who most need to build understanding, are the most likely to delegate it away. The fix isn’t moralizing; it’s structural. Keep a running log of what you would have had to look up if the AI weren’t there. That log is a map of the skills atrophying.

What this means for your week

You don’t need to delete Cursor to fix this. You need to notice when you’ve stopped thinking. Three concrete moves:

1. Time one feature this week with the AI off. Not a toy project — real work. Compare against your last similar feature.
2. Pick one area where you want depth (a language, a subsystem, a paradigm) and declare it AI-off. Treat it the way you’d treat a piano practice room.
3. Audit the last week of accepted suggestions. For each non-trivial one, can you explain why that code is correct? The ones where you can’t are the debt.

The developers writing these “I’m going back” posts aren’t nostalgic. They’re calibrating. The question isn’t whether AI tools are useful — they obviously are. It’s whether the version of you that uses them every minute is the version of you that you want to be in five years.