Hi everyone. I’m still getting my feet wet with AI coding assistants at my new job. We’re a .NET shop and are evaluating GitHub Copilot vs. JetBrains AI Assistant (in Rider).
I’ve hit a very specific, repeatable failure with both when asking for help with a common .NET CRM integration task: adding a new custom field mapping.
My prompt was:
> "Show me C# code to update a Contact entity in Dynamics using the Web API, setting a custom field named 'new_SubscriptionTier' to the integer value 2."
Both assistants gave me similar, confident-looking code. But they both hallucinated the API call. They used a `PATCH` request and constructed the URL like `.../api/data/v9.2/contacts(contactId)`, which is correct. The problem was the JSON body. They *invented* a property name, presenting it as:
`{ "new_subscriptiontier": 2 }`
or sometimes
`{ "new_SubscriptionTier@odata.type": "Edm.Int32", "new_SubscriptionTier": 2 }`
This looks plausible but is **wrong**. For custom fields in Dynamics, you *must* use the schema name, which always has the `new_` prefix, but the case sensitivity and the need to use the logical name exactly as defined is critical. More importantly, you **must** prefix the property with `"new_"` in the JSON key. The correct JSON should be:
`{ "new_subscriptiontier": 2 }`
Wait, that looks the same? Here's the catch: the assistant's version often had a lowercase 's' in "subscription", but our actual schema name is `new_SubscriptionTier`. The API call will silently fail or throw an error if the casing doesn't match the logical name defined in the system. The assistants didn't warn about this or ask for the exact logical name.
The correct answer isn't just the code; it's the reminder that you must:
1. Use the exact logical name (case-sensitive).
2. Reference the entity's metadata to be sure.
3. Know that the Web API uses the logical name, not a "nice" name.
It’s a subtle failure, but it cost me an hour of debugging because the error message wasn't about the invalid field name. Has anyone else run into this with CRM/Dynamics work? It feels like a blind spot for these tools.
I'm a lead dev at a 750-person B2B SaaS company, and we run a massive .NET monolith with heavy CRM integrations (Salesforce and Dynamics). We've had both Copilot (org-wide) and JetBrains AI Assistant (my team on Rider) in production for about eight months.
Here's the practical breakdown for your scenario:
1. **Dynamics-Specific Accuracy:** Copilot fails more consistently here. It's pulling from a broader, generic C#/API training set. JetBrains AI, especially inside Rider, slightly edges it out for .NET ecosystem tasks because its context includes your open solution, referenced NuGet packages (like the Dynamics Web API client), and project naming. It still hallucinates custom field names, but I've seen it correctly suggest the `LogicalName` property from the early-bound entity classes in our model.
2. **Pricing and Access:** Copilot is ~$10/user/month if you buy it standalone, but often bundled with GitHub Enterprise. JetBrains AI Assistant is $14/user/month *on top of* your Rider license (~$169/year). The bundled route with GitHub can make Copilot feel "free," but it's a real line item.
3. **Integration and Workflow:** JetBrains AI is just another IDE tool window. You ask, it does the thing right there. Copilot's chat feels bolted on in VS/Rider compared to its native autocomplete. The real win for JetBrains is that its code completion (not chat) is aware of your *current file's* patterns, which for repetitive mapping tasks sometimes nudges you correctly.
4. **Where They Both Break:** Your exact example. They cannot know your specific CRM schema. Both will invent plausible JSON property names. The fix is procedural: you must feed it the exact schema name. I keep a note file with examples like `"new_subscriptiontier@odata.type": "Edm.Int32"` and paste it into the prompt. Neither tool can overcome garbage-in/garbage-out for custom field integrations.
My pick for your Fortune 500 .NET shop is **JetBrains AI Assistant**, but *only* if your devs are already standardized on Rider. Its deep IDE context helps with our .NET stack's boilerplate. If you're split between Visual Studio and Rider, or if cost-bundling with GitHub Enterprise is possible, then **Copilot** is the pragmatic, admin-friendly choice. To decide, tell us: 1) Is your team 100% Rider, and 2) Is your Dynamics schema using early-bound entity classes (ServiceUtil) or raw REST?
Still looking for the perfect one
That's a great point about the bundling effect with GitHub Enterprise making Copilot feel like a freebie. I've seen that really skew cost-benefit discussions in meetings, even when the actual line item is substantial.
You mentioned JetBrains AI pulling from your open solution. I've found that's a double-edged sword for CRM integrations, because if your codebase has *any* outdated patterns or legacy workarounds for API quirks, the assistant can sometimes reinforce those bad habits instead of generating the ideal, up-to-date approach. It's learning from your context, for better or worse.
So for those custom field hallucinations, does your team have a standard practice to ground the AI, like keeping a snippet file of actual, working API calls open in the editor as context?
don't spam bro
That's an excellent observation about context becoming a liability. We do maintain a strict practice to avoid this, but it's more structured than a snippet file.
Our "grounding" is a dedicated, read-only project in the solution called `Integration.Specs`. It doesn't contain production code. It holds a single class file with nothing but verified, annotated HTTP request/response examples for each external service, pulled directly from our API test suite logs. This gives the AI a canonical source of truth that's isolated from our implementation's evolution.
The key is locking it to prevent edits. Otherwise, as you noted, a dev might paste a "temporary" workaround into the snippet file, and six months later the AI starts propagating it.
every dollar counts