My results after disabling all other IntelliSense - Copilot alone wasn't enough.

Your observation about proprietary libraries aligns with my experience testing Copilot's limitations in low-data domains. The model's training corpus likely contains minimal exposure to your internal APIs, making it a weak retrieval system for specific method signatures.

I've found the optimal setup retains IntelliSense for type checking and documentation, while using Copilot for code generation within those constrained contexts. A hybrid approach treats Copilot as a generative layer on top of a traditional LSP's deterministic output. This is supported by the findings in the "Code Completion with Neural Attention" paper, where hybrid models outperformed either approach alone.

For your marketing scripts, you might configure language-specific settings: disable Copilot's inline suggestions for JavaScript/TypeScript files where your internal libraries are heavily used, but keep it enabled for Python boilerplate sections. The VS Code setting `github.copilot.enable` can be scoped by language.

Of course it fell short. You're expecting a general-purpose model trained on public repos to know your company's private API details. That's like asking a city cab driver for directions inside a secure government facility.

The real issue here is the vendor lock-in you're sleepwalking into. You're not just disabling IntelliSense, you're disabling your editor's ability to understand your actual codebase in favor of a cloud service guessing what you might want. When GitHub's API has an outage or they change their pricing model (and they will), you're left with an editor that doesn't know how to read your own project.

Keep IntelliSense on. Use Copilot for the boilerplate it's good at. Anything involving your internal libraries? That's what your editor's language server is actually for. Don't pay a monthly fee to lose basic functionality.

The vendor lock-in point is spot on, but the real cost isn't just the monthly fee. It's the institutional knowledge drain. After three Salesforce-to-Hubspot migrations, I've seen what happens when teams stop reading their own API docs because a tool gives them a fuzzy, good-enough answer. When the contract gets reviewed next quarter and Copilot gets cut, you've got a team that never learned the actual library patterns.

Your internal language server is a deterministic map of your own territory. Replacing it with a probabilistic autocomplete for everything is like throwing out your building's blueprints and relying on a contractor's best guess because he's worked on some other buildings. The outage isn't just an API blip, it's a complete context collapse.

We treat these tools as productivity boosters, but they're actually creating a silent dependency on an external system that has zero obligation to understand your business logic. That's a much bigger strategic risk than slow boilerplate typing.

Exactly. That "good-enough answer" from Copilot becomes a crutch, and the team's mental model of the API erodes. I've seen it with internal TypeScript utilities. Someone gets a plausible-looking suggestion, accepts it, and now there's a pattern floating around that nobody really understands because the docs were never consulted.

The deterministic language server is key. I wonder if there's a middle ground, like a plugin that could prioritize IntelliSense from your internal LSP for proprietary modules, but still allow Copilot to chime in for generic patterns. You'd keep the map but get the occasional shortcut on well-trodden paths. Has anyone tried to configure something like that in VS Code's settings per-workspace?

Copilot alone is like asking a GPS for directions in your own backyard. It knows streets, not your secret garden path.

For boilerplate, sure, it's a time-saver. But for your internal API? That's like using a general contractor to repair a spaceship's custom wiring. You need the schematics, which is what IntelliSense pulls from your code.

I never turn IntelliSense off. Copilot gets to play in the sandbox of well-known patterns, but the real work needs a map.

That exact scenario is why I keep IntelliSense on for anything involving a custom package.json or our internal Python wheels. Copilot's guesses for our internal SaaS client library were often subtly wrong, like suggesting `client.fetch_lead(vendor_id)` when the actual param is `partner_id`. Those small errors create debugging debt.

Have you looked at the per-language settings in VS Code? You can turn down Copilot's suggestion frequency just for, say, JavaScript files, but leave it more active for your Python boilerplate. It's a granular fix that doesn't force an all-or-nothing choice.

The per-language suggestion frequency is a great practical tip. I've had success setting it lower for our Salesforce Apex classes where the internal namespace is everything, but leaving it high for generic JS/TS utilities.

Your example about `partner_id` vs `vendor_id` hits home. We caught a similar mismatch in a Zapier integration script where Copilot suggested a deprecated webhook field. It looked right, but the actual flow failed silently for a day. That's the debugging debt you mentioned.

Maybe we could also version control a small custom snippet file for those internal API patterns? Feed the deterministic map into the probabilistic helper, so to speak.

That's a really clever idea about the custom snippet file. It turns a vague "be careful" into a concrete team workflow.

I've seen similar work with a shared `.code-snippets` file for VS Code, but the version control aspect is key. It prevents drift and makes the snippets part of onboarding. The trick is keeping it lean, or it becomes another outdated artifact you have to maintain. Maybe one pattern per internal module?

Oh, the "good-enough answer" crutch is so real, and it hits close to home with CRM migrations. I once saw a junior dev build a whole segment of a HubSpot integration using Copilot's guesses for our custom object schema. It looked plausible, but the field mappings were subtly off, and it created a data integrity mess that took a week to untangle. The team's mental model of the actual API had completely faded because they'd stopped looking at the reference docs.

I love your idea for a middle-ground plugin. I haven't seen one, but the per-language and per-workspace settings are the closest I've gotten. You can absolutely prioritize IntelliSense for, say, your `company-internal` VS Code workspace, while letting Copilot run wild in a generic utilities folder. It's not perfect, but it fences off the "secret garden paths" from the public street map.

That debugging debt you mentioned - it's the silent killer. It's not a dramatic outage, it's just a slow, creeping accumulation of "why doesn't this work?" moments that erode velocity. Maybe the real middle ground is a team rule: if Copilot suggests something for an internal API, you have to open the docs tab just to glance at it before you accept.

You've identified the core limitation perfectly. The "mixed results" you experienced aren't just anecdotal; they're a predictable outcome of the probabilistic nature of the tool versus the deterministic nature of your internal codebase.

For internal APIs, Copilot's suggestions are essentially advanced pattern matching based on public code. It's statistically guessing what your `fetch_lead` method might be called, based on thousands of public repos. IntelliSense, fed by your language server, is reading the actual, local source or type definitions. That's why it knows the parameter is `partner_id` and can show you the exact docstring.

The optimization isn't about disabling one for the other. It's about configuring them as complementary systems. Treat Copilot as a statistical engine for high-frequency, low-context tasks (your boilerplate), and IntelliSense as the deterministic lookup for your proprietary, low-frequency, high-importance code. The per-language suggestion frequency tweak mentioned by others is the most straightforward way to enforce this split.

Exactly. The split works. But "boilerplate" as a category is tricky.

A junior dev sees a React `useEffect` pattern as boilerplate. Copilot nails it. But that same pattern in a custom auth hook is now high-context. Copilot will give you a statistically common, but possibly insecure, implementation.

The per-language setting helps. A better signal is file path. If the module is under `src/libs/` or imports an internal package, throttle Copilot to near-zero. For `node_modules` or standard library imports, let it run.