I’ll admit, I was fully bought into the Copilot ecosystem for a good six months. Integrated it into VS Code, used it for everything from boilerplate cloud formation to Python lambda handlers. But a couple of months ago, I hit a wall. I found myself spending more mental energy *reviewing*, *correcting*, and *second-guessing* its suggestions than I would have just writing the code myself. It felt like I had an overeager intern who needed constant supervision.
The tipping point was during a complex refactor involving some distributed session management. Copilot kept offering plausible-looking but subtly wrong patterns based on older code it had seen. I’d accept a block, realize it wasn't quite right, and then have to unwind my own thought process to debug *its* logic. That context-switching—from my problem-solving flow to being a code reviewer—introduced a surprising amount of friction.
So I switched back to a curated library of my own snippets. The difference in cognitive load was immediate and stark.
* **My snippets are predictable.** They are my own patterns, born from past mistakes and refined for my projects. I know exactly what they do and where they fit.
* **The mental model is simpler.** Instead of thinking "what will Copilot suggest here?", I think "which of my tools solves this?" It’s a shift from open-ended generation to selective retrieval.
* **No hidden context pollution.** Copilot’s training on public code means its suggestions sometimes carry assumptions that don’t align with my team’s specific conventions or our cloud architecture’s constraints.
This isn’t to say Copilot is bad. For greenfield projects or exploring a new language’s syntax, it’s phenomenal. But for deep, architectural work in familiar domains—especially where consistency and precision are critical—I found the overhead of managing its “creativity” outweighed the benefits. It made me realize that for my core workflows, I don’t need an AI pair programmer; I need a well-organized toolbox.
I’m curious if others have had a similar experience. Has anyone else moved back to a more “manual” approach after using AI coding assistants? I’m particularly interested in hearing from folks working in complex, established codebases where the patterns are already set.
~jason
~jason
That's a fascinating point about the cognitive overhead of switching from problem-solver to reviewer. Your distributed session management example is key. Copilot's suggestions are fundamentally probabilistic aggregates of training data, not reasoned designs. In observability, we see a parallel: you can't effectively monitor a system by just averaging telemetry from a thousand other systems; you need intentional, context-specific instrumentation.
My own compromise has been to use snippets for well-defined, high-ceremony patterns, like a standardized Prometheus metric definition block or a Kubernetes liveness probe template. But I've kept Copilot for the tedious, boilerplate-heavy tasks where the cost of a mistake is low, like populating configuration structs. The critical factor is having the mental model to know which category the current task falls into.
Sounds about right. It's an automation tool that makes you do more work. The "overeager intern" bit is spot on. They're great for generating text but terrible at reasoning.
I've seen it blow up configs in subtle ways. Like suggesting an Ansible playbook using a deprecated module parameter that *looks* correct but fails in newer versions. You spend more time vetting its output than you'd spend just writing the damn thing.
Snippets are deterministic. They do what you told them to do, no surprises. That's a feature, not a limitation.
Keep it simple
It's the review cost that gets you. You spend more on supervision than the tool saves.
For procurement, it's the same with any vendor AI. They sell it as a time saver, but the validation and error correction cycle eats the ROI. You end up managing the tool instead of your actual work.
What's your snippet library look like? Just local files or something managed?