Building and customizing solutions using Microsoft 365 Copilot APIs and tools
Copilot and GitHub Copilot are AI assistants that generate suggestions based on patterns learned from large code datasets and, in some products, from surrounding project context. They do not maintain a persistent, project-wide “memory” of all prior changes in the way a human collaborator does, and they can absolutely generate incorrect or breaking changes that require expert review.
For development scenarios like a C# VSTO add-in, the documented role of GitHub Copilot in Visual Studio is as an assistive tool, not an authoritative refactoring engine:
- In Visual Studio, GitHub Copilot provides inline completions and next edit suggestions as “ghost text” in the editor. These are proposals that must be explicitly accepted or rejected, line by line or block by block, by the developer.
- Copilot’s suggestions are generated by models trained on public code; they are not guaranteed to be correct for a specific solution structure (such as VSTO add-in startup classes, Ribbon registration, or manifest wiring), and they can easily break a working add-in if accepted wholesale without regression testing.
- Copilot does not track a full history of all code it has suggested to a project. Source control (for example, Git in GitHub or Azure Repos) remains the primary mechanism for versioning, diffing, and rolling back changes.
From the product perspective:
- GitHub Copilot in Visual Studio is explicitly positioned as an AI pair programmer that “helps you be more productive and efficient when writing code,” by generating whole lines or blocks of code based on the current context, comments, or function signatures. It is not described as a safe, automated “final reviewer” that can refactor an entire solution without risk.
- IntelliCode and Copilot are separate AI features. IntelliCode focuses on ranking and improving IntelliSense-style completions and API usage suggestions based on patterns from thousands of open-source repos and the current file context. GitHub Copilot focuses on generative completions and natural-language-to-code.
Given the behavior described (large-scale modifications, claims that files are “corrupted,” and suggestions to recreate projects), the recommended engineering practices around these tools are:
- Treat all Copilot output as untrusted until reviewed.
- Use Git or another VCS so every Copilot-assisted change can be diffed, tested, and reverted.
- Prefer small, localized suggestions (e.g., a single method or class) over allowing Copilot to rewrite core startup or registration code for frameworks like VSTO, where boilerplate and manifest wiring are strict.
- Use Copilot primarily for:
- Generating boilerplate code, unit tests, or example implementations.
- Drafting code from natural-language comments.
- Exploring alternative implementations that are then manually integrated.
For broader Copilot behavior across Microsoft products:
- Microsoft positions Copilot as a family of AI assistants across Microsoft 365, Dynamics 365, GitHub, and security products, designed to enhance productivity but with the explicit expectation that users review and verify generated content.
- Documentation for Copilot in Word, for example, explicitly notes that GPT-based features may produce unexpected or inaccurate content and that users must review and verify what is generated.
In short, the experience described is consistent with the documented nature of Copilot: it is a powerful but fallible assistant that requires strong developer oversight, robust use of source control, and incremental adoption rather than wholesale automated refactoring of a mature solution.
References: