What does this solve?
Most of a developer's workday is spent not on difficult decisions, but on typing predictable text: wrapping around an API call, parsing the response, error handling, a table of test cases, the next DTO. Copilot appends this text directly in the editor while the cursor is in the file.
The second closed pain is questions about someone else’s code. Instead of searching the repository and reading three layers of calls, a question is asked in the chat indicating a file or the entire project, and the answer comes with links to specific places.
The third is the routine around the pull request. A rough description of the changes, the first pass of the diff review, and a response to the comment “what’s going on here” are all done without switching to another tool, because everything lives inside the platform, where the code already lies.
The fourth is small tasks that people don’t get around to: updating a dependency, correcting an error text, completing a missed test. They can be assigned to an agent and receive a draft pull request for review.
How it works
The product is divided into several different mechanisms with a common name. Mixing them is harmful: they have different contexts, different qualities and different risks.
Additions in the editor
Gray text at the cursor position, accepted by the Tab key. The context is collected locally: the current file before and after the cursor, adjacent open tabs, file path and language. Hence the practical consequence is to keep open the files on which the current code relies: interface, model, neighboring similar handler. A closed tab means that the model will not see this and will come up with her own.
The model for additions was chosen for reasons of speed: the response must keep pace with typing. There is no need to expect deep conclusions from her.
Chat
Chat works in two views: a side panel and an inline mode directly in the editor, where the answer is applied as an edit. There are slash commands for common tasks - explain the selection, fix it, generate tests, write a documenting comment. There are context participants: accessing the workspace expands the search to the entire project, accessing the terminal pulls up the last output of the command. Individual files are added to the context by explicit link.
For repositories on the platform, a remote code index is built, due to which the search for the project is faster and finds more than a local crawl. The freshness of the index affects the responses: a newly created branch with new files may respond worse than the main one.
Agent mode in the editor
Mode where the model itself selects files, makes edits in several places, runs the build and tests, reads the output and continues until the result. Commands are executed with confirmation. The work ends with a set of edits in the working copy, which remain to be reviewed and committed.
Agent that opens a pull request
The task is assigned to the agent directly on the platform. He raises the isolated environment, takes the repository, makes edits, runs checks and opens a draft pull request with a description of what has been done. Then the usual process: review, comments, revision. The thread protection rules and mandatory checks continue to apply; such a pull request cannot be merged without a person.
Review
Copilot is assigned as a reviewer on a pull request and leaves comments on the diff lines: missing check for empty value, inconsistent naming, forgotten error handling. Useful as a first pass, cutting off the obvious before a human sees the diff.
Repository instructions
Permanent context is specified by the file .github/copilot-instructions.md in the repository: stack, conventions, prohibitions, command to run tests. Additionally, instructions are tied to path masks - their own rules for tests, their own for migrations. The files are in git, so the command gets the same behavior.
Management at the organization level
The administrator turns functions on and off by policy, maintains a list of excluded content - paths and repositories whose contents are not sent and for which add-ons do not work, and manages a filter for matches with public code. User actions are visible in the audit log. All this is set up before the team is trained, and not after the incident.
Useful scripts
- Wrapping around an external API: client, response models, error code processing - where the format is known and uniform.
- Table of test cases for a pure function: boundary values, empty inputs, incorrect types.
- A quick answer to the question “where is this used” and “why is there such a calling order” on an unfamiliar repository.
- First pass of review on a pull request: obvious omissions are cut off before a human opens the diff.
- Small isolated tasks from the queue, given to the agent: text editing, dependency update, missing test.
- Parsing a failed command in the terminal without copying the output to the browser.
Limitations
The add-on does not know the architecture. It relies on the current file and open tabs, so it confidently repeats the local style and passes by as intended: it writes its request to the database where there is a repository in the project, or duplicates a helper located in a neighboring module.
Atypical stack sags. Quality is directly related to the amount of public code in that language and framework. The company's internal library and rare dialect turn sentences into plausible fiction.
Matches with public code. A long fragment may coincide with someone else's code under an inconvenient license. The match filter is enabled at the organization level, rather than relying on the attentiveness of the developer.
Context limited. Chat responses depend on the freshness of the index, and additions depend on what is open right now. “The model doesn’t see” is the most common reason for a bad hint, and it can be cured by adding the file to the context, and not by reformulating the question.
The cloud agent is cut off from the internal loop. It will not reach a closed service, private batch registry or test base without explicitly setting up the environment. It will not solve problems with integrations.
The review remains on the person. A draft pull request from an agent goes through the same checks as any other one. Automatic approval of such changes turns CI into the only barrier to production.
The metric for accepted tips is deceiving. The share of accepted additions is growing due to the habit of pressing Tab. It says nothing about the number of defects or delivery time.
Data and Compliance. What goes into the service and how it is stored is determined by the organization’s plan and settings. For a regulated industry, this is a separate document and a separate approval.
How to check the result
See which files the chat has referenced. The answer without links to the project code is based on general knowledge about the language and has nothing to do with this repository.
Check exceptions by doing: open a file that is excluded by policy and make sure that no additions are received for it and the chat does not quote it. An entry in the settings without such a check is an assumption.
Ensure that the public code match filter is enabled at the organization level and not left to the discretion of each developer.
On a pull request from an agent - a full review and a mandatory human approver in the rules of the branch. The tests in CI are the same as for people, without any concessions.
Test repository instructions with an experiment: give a task that violates the written convention and see if the model follows the rule. The instruction, which does not affect the output, is written as a wish.
Measure the benefit along the flow: time from the start of the task to the merged pull request, the number of returns from the review, the number of defects that reached the point of sale. These figures are compared before and after rolling, for periods of equal composition.
For bad add-ons, first check the composition of open tabs, then everything else. The desired interface and the adjacent similar module in adjacent tabs change the quality of the tips more than any settings.
Rule: a hint is accepted only after checking that the model has seen the files on which the edit depends.