An AI coding integration can be supported in one editor while a particular feature remains unavailable in another. Compatibility evidence connects the exact IDE, extension, operating system, account policy, and feature. The result is a brief that explains whether a planned workflow is documented and what still needs a local validation check.
Primary sources checked on 8 October 2026. Worked examples and sample records below are illustrative; they do not represent product tests or real customer findings.
Write the integration requirement as a workflow
Name the action your developer needs: inline completion, repository chat, agent mode, code review, tool access, or command-line assistance. Then record IDE name and version, extension version, operating system, remote-development mode, and account plan. A statement that a product supports an editor is too broad to prove all these actions work in that configuration.
Separate installation compatibility from feature compatibility. An extension can install successfully while a model selection option or organizational policy prevents a particular workflow. A remote container can also change where tools execute. The evidence brief should make those boundaries explicit before someone interprets a successful installation as a complete acceptance test.
Use the provider’s feature matrix
GitHub’s official Copilot feature matrix compares support across IDEs and versions. Inspect the row for the requested feature and the relevant surface. Read any partial-support or qualification notes rather than reducing every nonempty cell to yes. A matrix for the latest version should not automatically be applied to an older editor.
Follow the linked installation and feature documentation as needed. Capture the current observation date and the version conditions. A third-party tutorial can explain a workflow but may use outdated extension behavior. Keep those examples separate from the provider’s current compatibility statement. The primary matrix establishes the published support scope, not a guarantee about every repository.
Check account policy and prerequisites
A technically supported feature may be disabled by organizational settings, unavailable on a plan, or restricted by network policy. Record those prerequisites separately from editor support. If a developer cannot see the feature, investigate the account and policy context before concluding that the IDE is incompatible.
Do not ask an assistant to infer enterprise policy from a screenshot. Use the organization’s authorized settings or administrator confirmation. Keep secrets and tokens out of the evidence pack. A useful brief can state that the feature is documented for the editor but blocked by a known policy, which gives the team a different next action from a missing technical capability.
Build a configuration evidence table
Use one row per required feature and configuration. Include official support statement, version requirement, partial-support notes, account prerequisite, local observation, and outcome. Labels such as documented, observed, blocked, and unresolved are clearer than a single compatible checkbox. They show whether the conclusion comes from a provider page or an executed check.
In an illustrative case, chat is documented for two editors while an agent feature has qualified support in one. The project may still proceed with chat, but its agent-based workflow needs further validation. Do not convert that finding into a ranking of the whole editors. The scope is the requested integration behavior, not general IDE quality.
Run a small acceptance check when authorized
Use a disposable sample repository with a clear task and a known expected result. Check that the integration can access the intended files, use the documented tools, and preserve review controls. Avoid granting broad privileges just to make a demo work. Record configuration and output so the result can be repeated after an update.
Treat model behavior and integration plumbing as separate checks. A poor answer does not necessarily mean the extension is unsupported; a missing permission does not prove the model cannot solve the task. Capture errors and feature availability independently from answer quality. This makes troubleshooting faster and keeps compatibility evidence from becoming an unsupported performance claim.
Produce the compatibility brief and refresh rule
Summarize which parts are documented, observed, qualified, or blocked. Give each unresolved prerequisite an owner and a next check. State the exact editor and extension versions. Link the relevant primary matrix and feature page. Avoid a timeless works everywhere conclusion because coding integrations change frequently.
Recheck after IDE upgrades, extension upgrades, policy changes, or a switch to remote development. Preserve the previous configuration result so regressions can be investigated. The finished brief should help a team choose a supported path for its actual workflow and prevent time being wasted on assumptions that a brand-level compatibility statement never established.
Review and preserve the finished compatibility evidence brief
Before handing over the result, perform a review that starts from the evidence rather than the generated prose. Pick a clearly supported item, a disputed item, and an item with missing information. Write the expected treatment of each before reading the proposed conclusions. Then open the cited originals and compare the result with those expectations. Check the surrounding text, headings, dates, and qualifications, because a citation can point to the correct document while supporting a narrower statement.
Ask a colleague to use the finished deliverable without your explanation. They should be able to locate the original records, identify unresolved questions, and understand which statements are direct evidence and which are your interpretation. Revise any place where they must guess. Keep the reviewed output, source manifest, prompt, and correction history together. Record the review date and the event that should trigger another check. When a source changes, preserve the earlier assessment and explain which conclusions were affected rather than silently replacing the evidence.
Do not equate an empty result with the absence of a problem. Check that all intended inputs were included and readable. Explain exclusions and merged records. A useful handover makes incompleteness visible and assigns a next action to the person who can resolve it.
Frequently asked questions
Does IDE support imply every feature works?
No. Check the feature-specific matrix, version conditions, and any partial-support notes.
Is successful installation sufficient?
It establishes installation, not all permissions, account access, or workflow behavior.
Can enterprise policy affect compatibility?
It can block an otherwise supported feature. Record policy and technical support separately.
Should I test with a production repository?
Prefer a small disposable representative repository before granting access to sensitive or consequential code.
What triggers a recheck?
IDE or extension updates, account policy changes, new features, and changes to remote or container development.
