visual-studio-code

Getting more from each token: How Copilot improves context handling and model routing (opens in new tab)

GitHub is improving Copilot’s efficiency by optimizing both how context is handled and which model performs each task. Prompt caching and deferred tool loading reduce repeated overhead in long agentic sessions, while Auto selects models based on task complexity and real-time system conditions. The goal is to preserve quality while using tokens, compute, and cost more intelligently. ## Prompt Caching and Deferred Tools - Copilot sessions repeatedly include instructions, repository context, conversation history, tool definitions, and task state. - Prompt caching allows repeated prompt prefixes to reuse model state instead of being recomputed on every request. - Tool search loads tool definitions only when needed, rather than placing every full schema into context on every turn. - This is especially valuable for sessions involving MCP tools, terminal commands, file operations, workspace search, and other actions. - The approach reduces fixed per-turn overhead while preserving access to a broad toolset. ## Auto Model Selection - Copilot Auto chooses a model based on the task rather than requiring developers to select one manually. - Quick explanations, focused edits, and complex multi-file changes often benefit from different levels of reasoning. - Evaluations found that no single model consistently performs best across all tasks. - Auto uses more efficient models when they can achieve comparable results and selects stronger reasoning models when the task demands them. - The objective is not simply lower cost, but matching model capability to the work. ## How Auto Routes Tasks Auto combines two signals: - **Real-time model health** - Considers availability, utilization, response speed, error rates, and cost. - Avoids selecting a model that is technically capable but currently overloaded or unreliable. - **Task-aware routing with HyDRA** - Evaluates reasoning depth, code complexity, debugging difficulty, and tool-orchestration requirements. - Identifies models capable of meeting the task’s quality threshold, then chooses the best fit among them. - The system can be tuned toward maximum quality or greater cost savings. ## Cache-Aware Routing - Switching models during every turn can reduce efficiency by invalidating cached prompt prefixes. - Auto therefore keeps the same model during a conversation so the cache can continue building. - It changes models at natural cache boundaries: - The first turn, when no cache exists yet. - After context compaction, when older turns are summarized and the prompt prefix resets. ## Multilingual Routing - Copilot’s routing system was trained on conversations spanning 16 language families, including CJK and European languages. - Evaluations covered production VS Code chat data across 19 languages. - Routing accuracy remained within four points of the English baseline across language groups. - No statistically significant quality gap was observed between the language groups. Copilot’s efficiency strategy combines smarter context management with adaptive model selection. Caching and on-demand tools reduce repeated work, while cache-aware Auto routing chooses an appropriate model without unnecessarily sacrificing quality or session efficiency.

GitHub for Beginners: Getting started with Git and GitHub in VS Code (opens in new tab)

VS Code provides an integrated way to manage Git and GitHub without leaving the editor, reducing context switching and simplifying common version-control tasks. The post walks beginners through initializing a repository, staging and committing files, creating branches, tracking edits, and reviewing diffs. It emphasizes that Git manages source code locally, while GitHub hosts repository copies remotely. ## Git, GitHub, and VS Code - **Git** is the program used to manage source code and version history. - **GitHub** hosts copies of Git repositories. - **VS Code** uses Git to provide a graphical workflow for managing code and synchronizing it with GitHub. - Following along requires installing both Git and VS Code. ## Initializing a Repository - Open a project folder in VS Code through the **Explorer** panel. - Select **Source Control** and click **Initialize Repository**. - VS Code creates a local Git repository, initially using the `main` branch. - The branch can be renamed through the Command Palette: - macOS: `Shift-Command-P` - Windows/Linux: `Ctrl-Shift-P` - Choose **Git: Rename Branch**. ## Staging and Committing Files - Newly detected files appear with a **U**, meaning “untracked.” - Click the plus sign beside a file—or beside **CHANGES** to stage everything. - Staged files receive an **A** indicator. - Enter a commit message in the Source Control panel and click **Commit**. - Git commits changes locally; they are not uploaded to GitHub until they are pushed. ## Creating and Switching Branches - Use the Command Palette and select **Git: Create Branch…**. - Enter a branch name such as `new-features`. - VS Code creates the branch and automatically switches to it. - The active branch is displayed in the bottom-left status bar. - Branches allow developers to work on features separately from `main`. ## Understanding Change Indicators VS Code displays edits directly in the editor gutter: - A green line marks newly added code. - A blue patterned line marks modified existing code. - A red arrow marks deleted code. - Modified files appear under **CHANGES** in the Source Control panel. - Hovering over a file provides controls to open it, discard changes, or stage it. - The **CHANGES** header also provides actions for reviewing, discarding, or staging changes across all files. ## Reviewing Diffs - Clicking a changed file opens a side-by-side comparison of the current and previous versions. - The diff menu’s **Inline View** option displays changes in a single editor pane. - Inline diffs can also be edited directly, allowing corrections before staging or committing. VS Code’s Source Control integration gives beginners a practical, visual workflow for Git. A typical process is to initialize a folder, create a working branch, inspect edits, stage selected files, commit them with a descriptive message, and then push the commits to GitHub.

Building a general-purpose accessibility agent—and what we learned in the process (opens in new tab)

GitHub is piloting a general-purpose accessibility agent that answers accessibility questions and automatically fixes straightforward issues in front-end code. The agent has reviewed 3,535 pull requests and resolved 68% of identified issues, especially problems involving structure, control names, status messages, text alternatives, and keyboard focus. GitHub’s experience shows that an accessibility agent is most effective as an augmentation of human expertise, supported by a strong foundation of manually documented accessibility work. ## Goals and Results - The agent serves two purposes: - Provide just-in-time accessibility guidance through GitHub Copilot CLI and VS Code. - Detect and automatically remediate simple, objective accessibility issues before production. - It evaluates pull requests that modify front-end code. - Its five most common issue categories are: - Making structure and relationships understandable to assistive technologies. - Giving interactive controls clear, concise names. - Ensuring users receive important status announcements. - Providing text alternatives for non-text content. - Maintaining a logical keyboard focus order. - Example fixes can identify mismatches between visual order and screen-reader reading order, then suggest code changes that developers can commit directly. ## An Augmenting, Not Universal, Tool - GitHub frames accessibility through the social model of disability: barriers are often created by how digital environments are designed and built. - The agent is intended to help engineers remove those barriers, not “solve” accessibility independently. - It is not a silver bullet capable of handling every accessibility scenario. - Clearly limiting its responsibility helped GitHub launch the experiment more quickly and gain broader internal support. ## Why Manual Accessibility Work Matters - New and upcoming regulations, including the European Accessibility Act and the Americans with Disabilities Act’s planned WCAG 2.1 AA requirements, increase the importance of accessibility investment. - Organizations without established processes for manually identifying and fixing accessibility problems will be at a disadvantage. - GitHub already had a mature issue-management process containing: - Structured problem reports. - Reproduction steps. - Severity, service-area, and WCAG metadata. - Links to fixing pull requests. - Acceptance criteria. - Centralizing these issues in one repository made the collection a valuable reference corpus for the agent. ## Using Historical Issues as Training Material - The agent examines past accessibility issues and related pull requests to find applicable code and language patterns. - LLMs’ fuzzy matching can be useful here because it helps connect new problems with similar historical examples. - Generic instructions such as “follow accessibility best practices” are insufficient. - LLMs often reproduce accessibility antipatterns because their training data contains decades of inaccessible code. - Manually cataloged issues and organization-specific fixes provide contextual examples that are more useful than short, generic accessibility checklists. GitHub’s experience suggests that teams should first build reliable human processes for reporting and remediating accessibility issues. Once that structured knowledge exists, an agent can help apply it consistently and efficiently—while remaining a complement to, rather than a replacement for, accessibility expertise.

How to detect and prevent Contagious Interview IDE attacks (opens in new tab)

Contagious Interview attacks abuse VS Code’s automated tasks to execute malware when victims open a malicious repository and trust its workspace. GitLab developed low-level EDR detections around `node-pty`’s `spawn-helper`, allowing it to identify hidden background process execution while avoiding normal interactive developer activity. The article recommends combining runtime detection with IDE configuration hardening. ## The Contagious Interview Attack Path - North Korean threat actors use fake job interviews to persuade targets to download and review malicious code repositories. - Repositories can include a `.vscode/tasks.json` file configured to run automatically when the folder opens. - After the victim grants workspace trust, the task executes without obvious interaction. - Example payloads: - Detect the operating system. - Download a platform-specific second-stage payload. - Pipe it directly into `bash`, `sh`, or `cmd` using patterns such as `curl | bash`. - Resulting malware may steal passwords and cryptocurrency, deploy infostealers, and establish persistence for abuse of corporate access. ## Low-Level Detection with `spawn-helper` - GitLab looked below the VS Code layer because similar attacks can affect VS Code forks and other Node- or Electron-based IDEs. - VS Code uses the popular `node-pty` library to launch subprocesses. - `node-pty.spawn()` invokes a `spawn-helper` binary, which becomes a child process of the Node application. - This makes `spawn-helper` a useful operating-system-level signal for background task execution. ## Reducing False Positives - GitLab used Purple Team exercises to reproduce the attack and reviewed EDR telemetry. - Background VS Code tasks use `spawn-helper`, while foreground interactive processes such as the integrated terminal use a Code Helper binary. - Detections can therefore focus on processes launched invisibly, without user interaction. - GitLab further tuned alerts to identify suspicious commands such as background `curl | <shell>` execution rather than flagging every automated task. - The resulting detection produced no false positives despite widespread VS Code usage internally. ## Additional Prevention Measures - Runtime EDR monitoring is only one layer of defense. - Organizations can proactively harden their fleets by deploying global VS Code configuration that disables automatic task execution. - Combining IDE restrictions with process telemetry and behavioral detection provides broader protection against malicious repository-based attacks. Organizations should disable automatic task runs where practical and monitor low-level subprocess behavior, especially invisible `spawn-helper` executions that download or pipe remote content into a shell.

The VS Code Method: Tightening a developer’s inner loop | Figma Blog (opens in new tab)

The post argues that developers are most productive when they can sustain the “inner loop”: writing, compiling, debugging, and iterating without disruptive context switching. VS Code’s approach is to bring more outer-loop activities—collaboration, project management, design inspection, and AI assistance—into the editor. The result is not only faster development, but better code quality, greater energy, and improved developer satisfaction. ## The Inner Loop and Flow - The inner loop is the repeated cycle of writing code, compiling, debugging, and continuing in the code editor. - The outer loop includes activities outside the editor, such as: - Checking bug trackers - Updating tickets - Responding in Slack or Teams - Reviewing documentation - Switching between projects and terminals - Staying in the inner loop builds “inertia,” increasing speed and productivity over time. - Interruptions also cause developers to lose mentally loaded context, including edge cases and future plans for the code. ## Reducing Distractions in VS Code - VS Code uses features and extensions to help developers remain focused inside the editor. - Zen Mode hides interface elements and creates a distraction-free workspace. - Even small UI changes, such as collapsing a sidebar, can interrupt concentration as the brain recalibrates. - Developers can customize VS Code with extensions that match their preferred workflows. ## Bringing Outer-Loop Work into the Editor - The broader goal is to move as many tasks as possible into the developer’s existing workflow. - Integrations can reduce switching between: - VS Code and GitHub - Code and project-management tools - Development tools and design platforms - The Figma for VS Code extension lets developers access and inspect designs without leaving the editor. - AI tools such as GitHub Copilot provide proactive, non-intrusive code suggestions. - GitHub reports that Copilot increases coding speed by 55%, while 75% of AI-using developers report greater fulfillment. ## Collaboration Without Breaking Focus - Collaboration is essential but often disruptive when it requires meetings or prolonged chat exchanges. - VS Code integrates GitHub features so developers can manage issues, review code, and submit pull requests from the editor. - The ideal collaboration model lets multiple people remain in their own inner loops rather than requiring constant synchronous interaction. - Direct comments and embedded collaboration can preserve focus while keeping teams connected. ## A More Connected Developer Workflow The VS Code team envisions an inner loop that eventually includes all the tools developers need. Until then, teams should prioritize integrations that eliminate unnecessary switching and tedious manual work. Keeping developers in flow improves productivity, code quality, energy, and overall happiness.

Dev Mode: Building a Design Tool that Works Harder for Developers | Figma Blog (opens in new tab)

Figma built Dev Mode to make developers first-class participants in product design rather than secondary users of a designer-focused tool. The team initially emphasized code generation, but real-world differences in teams, workflows, and codebases exposed its limitations. By combining developer research, the acquisition of Visly, and a broader focus on inspection and collaboration, Figma shifted toward reducing the gap between design and code. ## Designing for Developers as Core Users - Figma’s multiplayer canvas was created for entire product teams, including product managers and developers. - Developers were already using Figma to explore work in progress, despite the tool not being optimized for their workflows. - By 2023, developers represented roughly one-third of Figma’s users. - The goal became a tailored developer experience that did not require developers to learn or navigate design-centric interactions. - Proposed directions included: - Component playgrounds - Code snippets - GitHub and Storybook integrations - Developer-specific resources - Design inspection and change comparison ## The Visly Acquisition - Figma acquired Visly in 2021, bringing in eight designers and engineers who had built a React UI development tool. - The Visly team contributed: - Extensive research into developer tooling - Practical experience with development workflows - A developer-oriented perspective and intuition - Their involvement accelerated Figma’s efforts and helped the company understand how developers work across different environments. ## Moving Beyond a Codegen-First Strategy - Early versions of Dev Mode focused on code generation: automatically translating designs into code according to predefined rules. - Codegen could save hours or even days when designs mapped cleanly to implementation. - Testing showed that successful code generation in controlled scenarios did not necessarily work in production. - Companies differ in their: - Team structures - Engineering practices - Toolchains - Codebases - Workflow conventions - These variations made it difficult to generate universally useful code, prompting the team to reconsider codegen as the central solution. ## Redefining Design-to-Code Handoff - Figma’s broader objective was to break down the traditional “handoff wall” between designers and developers. - Dev Mode was positioned as a dedicated space where developers could inspect designs, compare changes, work with VS Code, and access implementation-oriented information. - The team continued refining the product through beta feedback, including daily customer requests collected through an internal Slackbot. - Rather than assuming developers would live inside a design tool, Figma focused on making the parts of the design process they needed more accessible and useful. Dev Mode’s central lesson is that developer tooling must reflect real engineering practices, not just generate code from idealized designs. A practical developer experience combines accurate design context, collaboration, integrations, and workflow flexibility with code generation where it genuinely helps.