Developing a VSCode AI extension: what breaks without it
The built-in assistant in the editor sees the open file and cursor position — and nothing else. It doesn't know that part of the logic lives in another module, what conventions the team has adopted, or which decisions have already been rejected as unsuccessful.
This leads to false model suggestions: it confidently proposes nonexistent methods and fields, pulls in someone else's logging style, and reproduces an outdated call contract.
The code formally looks like it works, but it violates architectural agreements, and it's easier to rewrite manually than to debug.
The bottleneck when working with code shifts: generation has sped up, but checking every suggestion has not. Engineers start rechecking everything the assistant inserts, and it turns into an expensive search bar that no one trusts.
Developing a VSCode AI extension for a specific project removes this at the data access level: the workspace is indexed in full, and the project context in suggestions is your modules, internal services, and review rules, not an averaged example from open sources.
Next, we break down how this is addressed: from indexing and restricting access to closed parts of the project to metrics that show the share of accepted suggestions is growing while rewrites after them are falling.
What changes in the team's work after implementing the assistant
The assistant doesn't change the project architecture — the team's working cadence changes.
The effect of implementation is visible in four metrics that we capture before the start and one month after: time to the first meaningful edit in an unfamiliar module, share of rejected suggestions, number of repeat fixes to the same place, and speed of passing code review. Below is what drives each one.
First — time to edit unfamiliar code. Without an assistant, this period goes into restoring connections: where a function is called, where data comes from, which test catches a regression.
An extension in VS Code with access to the repository index returns this in a single request along with call sites, and the edit begins immediately, not after analyzing half the project.
Second — share of rejected suggestions. This is an honest indicator of context quality: if the model proposes solutions outside the project's accepted conventions, more than half the answers are rejected.
We reduce the share not with wording in chat, but with factual material — project rule files, type schemas, and reference modules that are pulled into every request.
Third — repeat fixes during code review. There are fewer of them when a suggestion accounts not for the open file, but for the consequences of the change: calls from neighboring modules, migrations, input validations. An edit made once and in the right layer doesn't come back for a second round.
Fourth — speed of code review. With fewer rejected suggestions and repeat edits, changes arrive more compactly and along responsibility boundaries, so the reviewer spends time on logic rather than rewriting, and the pass closes on the first attempt.
Assistant operation modes: local, own server, external service
The model connection mode is a data decision, not a convenience decision. It determines whether a source code fragment leaves the perimeter, who is responsible for availability during peak hours, and what happens if the network goes down.
That's why in the extension we immediately build in a switchable model access layer: changing the mode is a configuration edit, not a rewrite of logic.
| Option | When it fits | Limitations |
|---|---|---|
| Local model in the editor | Code must not leave the developer's machine; offline operation is needed; autocomplete and repository index search | Requires workstation resources, lower quality on complex tasks, model updates must be done at each location separately |
| Own model server in the perimeter | Unified access rules, shared cache and request log, team of five or more engineers, custom fine-tuned models | Requires dedicated capacity and maintenance, latency depends on the network to the server, server failure stops everyone |
| External model service | Maximum quality on complex tasks, no own infrastructure, need for fast experiments | Code goes to a third party, license and retention policy checks are required, mode depends on provider limits |
Hybrid mode
In practice, a combination wins: routine autocomplete and repository search are handled by a local model, while analysis of architectural questions and test generation go to a server or external service.
We define routing by a rule based on request type and context size, while the request log remains unified — you can see which mode was used and how long it took.
How we manage implementation: stages of engineering work
Developing an AI extension for VS Code starts not with code, but with analyzing how the team works today.
We look at which actions are repeated dozens of times a day, where time is lost switching between the editor and external services, and only after that do we decide what to automate.
This way the extension covers a real area of work rather than becoming just another panel in the interface.
- Development process audit — we analyze the team's typical tasks, repository structure, test coverage, and operations that consume routine time.
- Editor integration scheme — we define which data goes to the language model, where access keys are stored, and how the extension behaves when the network is lost.
- Prototype on one scenario — the most frequent action, explanation of a code area, or test generation, is assembled into a working editor command and time is measured before and after.
- Setup and build — configuration for your code conventions, access policies, installation on work machines via the internal package registry.
- Testing on real scenarios — we run the assistant on live tasks and see what share of suggestions are accepted without edits and which have to be rewritten.
- Handover and team training — documentation, short walkthroughs, and a feedback channel through which we refine the extension after launch.
Each stage ends with an artifact: an audit report, an integration scheme, the built extension, and validation metrics.
Artifacts and access policies: what the team retains
After handover, the team retains not a folder with source code, but a set of artifacts that make it possible to develop, review, and safely operate the extension without us.
We transfer them to the customer's repository along with rights and settings, rather than leaving them in developers' personal accounts.
- Build and release configurations — extension manifest, separation of development and production builds, telemetry parameters; the build is reproduced with one command on a clean machine.
- Deployment scheme — where the proxy to the model sits, how requests are routed, which storage holds the keys, and which step performs rollback to the previous version.
- Code access policies — which files the extension reads, what leaves the perimeter and what remains local, who issues and revokes tokens.
- Assistant usage regulations — which prompt techniques are allowed, how to verify model suggestions before commit, what to record in the edit description.
- Extension documentation — architecture diagram, list of commands and settings, extension points for the team's internal rules.
- Developer instructions — how to set up the environment, run checks, release a new version, and distribute it to users.
- Model maintenance procedure — how to change request templates, how to evaluate quality on your own task set, how to disable unsafe responses.
Case study: code review in a distributed team
What it was like before implementation
A distributed team maintained one repository: edits arrived almost around the clock, and there were two reviewers.
A changeset waited for the first review for an average of 26 hours, and a third came back for rework — almost always due to the same mechanical comments: naming, logging, error handling at module boundaries.
What we changed
We built an extension for Visual Studio Code that knows the specific project's rules: style agreements, forbidden constructs, test requirements.
The assistant reads the changeset, compares it with these rules, and leaves comments directly on the lines of code — before a human sees the edit.
What changed by metrics
Time to first substantive review dropped from 26 hours to 40 minutes, and the full review cycle — from two days to six hours.
The share of returns for rework fell from 34% to 11%, and reviewers switched to architectural questions: logic, service boundaries, impact on adjacent modules.
The rules live in the repository next to the code: when agreements change, the assistant is updated with the same set of edits as the services themselves.
We handle false positives as ordinary defects — a complaint about a comment turns into a rule edit, so the noise share doesn't grow as the project grows.
What to do if the company already has its own model service?
If the company already has its own model service, there's no need to rewrite it.
In this scenario, the extension is a layer on top of the existing service: we connect to your perimeter as an external source, specify the address, authentication method, and response format, while request and context preparation lives inside the extension. The model stays where it was deployed, together with logs and access policies.
Transferring project rules means translating the team's agreements into declarative settings.
Code style, mandatory checks before insertion, restrictions on working with closed modules, and access levels are described in one place and read by the extension at startup, so rules are edited without rebuilding.
Compatibility with the current stack is determined by what your service exposes. If the interface is standard, integration comes down to configuration; if the format is custom, the adapter is written within the extension boundaries and doesn't affect the core. Then service updates don't break the developer's working tool.
We address access separately: keys don't end up in editor settings or repository files, and tokens are stored in secure storage. Rights are inherited from the employee's account, so code visibility remains within the same boundaries as before.
We analyze what you already have deployed and come back with an assessment — where a layer on top is enough and where a thin adapter is needed.
Questions asked before project start
Doubts before starting a project are almost always the same: where data goes, what the team retains, and who is responsible for operation after handover. Below are short answers to the point; we go through the details on a call, looking at your infrastructure.
Where do model requests go?
Requests either go to a model inside your perimeter or to an external provider — this is switched by configuration, without rewriting the extension logic. In the closed option, nothing goes outside.
Logs are written locally, and you set the volume yourself: you can store only metadata about the call, without file contents.
What happens to the internal code repository?
Indexing only covers directories permitted by the access policy. Data is kept in the session memory or local storage — it isn't uploaded to third-party servers. Access is granted to a service account, and rights are revoked with a single key change.
How are project rules updated?
Rules and code suggestions are described by configuration files inside the repository. Your team edits them through ordinary review, and rebuilding the extension isn't needed — just update the file and restart the session. This way rules remain transparent and enter the change history.
What about support after handover?
We hand over source code, setup description, and deployment instructions — the build is installed from your internal registry. After that we provide support: compatibility with the current editor branch, rule edits, incident analysis. We define in advance what is included in support and what is considered a separate task.
Let's discuss the task: how work on the assistant begins
Work on an assistant inside the editor begins not with code, but with analyzing scenarios.
The extension lives in the developer's daily cycle, so it's important to understand which actions it should accelerate, what data is needed for that, and where the boundaries of what's permissible lie. The more specific the input data, the more accurate the estimate and work plan.
What is needed from the customer at the input:
- list of tasks the assistant covers: code generation from file context, explanations of someone else's module, search across internal documentation, automated tests;
- where models run: external provider, corporate gateway, or local deployment — architecture and privacy requirements depend on this;
- data restrictions: what cannot be transmitted outside, how long to store context, what goes into logs;
- how the current process is structured: languages, repositories, build checks, so the extension fits into it rather than sitting on top;
- access requirements: single sign-on, roles, issuing and revoking keys;
- composition of the pilot group — how many developers we use to validate the effect.
At the first step, we analyze these scenarios and leave the ones that produce a measurable result in the first iteration.
Then we build a map of interaction with the model: call points, context preparation, cache, timeout handling — and define acceptance criteria: response time, share of accepted suggestions, correctness on internal code. The extension is built for Visual Studio Code and doesn't require retraining the team.
Describe the task and the current process — we'll come back with an estimate, a stage plan, and a list of risks.
