More AI usage per developer did not produce VS Code weekly releases. The product's own engineers report that the reverse happened: the release system had to change around agents, from agent-ready repositories to staged rollout monitoring. Shipping faster was the easy stage. Holding quality and learning faster were the constraints that decided the cadence.
VS Code weekly releases: what changed and why
VS Code weekly releases mean Microsoft's editor now ships a new version every week instead of every month. Harald Kirschner, a principal product manager on Visual Studio Code, said the team changed cadence after roughly ten years of monthly releases. The trigger was rebuilding the whole release system around agents rather than adding more AI to daily work.
The monthly train started with VS Code 1.0 and ran for about a decade, with an odd side effect the team liked to point out: the January release notes shipped in February. Open the release notes for January in February and you were not a month late, that was just how the iteration was tracked. The cadence matched the development velocity of the time. Agents changed what that velocity could be, and slow parts of the pipeline started to matter more than they had when humans were the only consumers of CI.
The framing Kirschner used splits the work into three stages. Shipping code faster is the easy part. Holding quality while the volume rises is harder. Learning faster, so the team ships the right things, is hardest. Weekly releases depend on all three, and each stage exposed a different bottleneck.
A small team serving more than 50 million users is the constraint behind the whole story. Recovery from a bad release costs more when the product is an installed application rather than a website, so speed without control would have been a net loss. Kirschner makes the point directly: this is not about token-maxing, spending every day inside an AI tool. It is about evolving the system that ships the software.
The measurement that started the whole effort was code survival, the share of agent-written code that actually gets committed instead of being read and thrown away. VS Code tracked it early and saw it climb. That climb in developer trust is what made more agent-written code acceptable in the first place.
| Stage | What it fixes | Main investment | Evidence the team cites |
|---|---|---|---|
| 1. Ship faster | Agents can work in the repository at all | AGENTS.md, skills, Typescript Go builds | Roughly 10x faster builds |
| 2. Hold quality | Volume arrives without breaking users | Component browser, launch skill, mandatory GitHub Copilot review, automatic triage, staged rollouts | Automated review mandatory on every pull request |
| 3. Learn faster | The team ships the right things | VSC-Bench evals, prototyping, daily sprints | 70x token spread on a five-character eval |
Stage one: making the codebase agent-ready
An agent-ready codebase is the precondition for shipping faster. The first artifact is an AGENTS.md file that maps where things live without bloating context. VS Code's team treats that file as a living document, updated whenever an agent makes a mistake. Kirschner noted that teams which already invested in developer experience and onboarding documentation get a head start, because agents read the same material humans do.
Skills carry domain knowledge that previously sat with one person. Accessibility was the example VS Code used early: best practices were encoded into a skill, reviewed and maintained by the accessibility area owner, so every engineer and every agent could apply them without pulling in a specialist. The general pattern is to find the person who is always asked the same question and encode what they know.
The litmus test VS Code applies is whether a product manager can edit the product codebase end to end and have engineering accept the result. Kirschner does this himself in the VS Code repository. If it works out of the box, locally, without breaking at ship time, the repository is ready for agent throughput. If it only works for one power user with a personal setup, it is not.
Why slow CI compounds with many agents
Build and CI latency compounds when agents run in parallel. Humans tolerate a slow pipeline by context switching or reviewing another pull request while it runs. Ten or twenty agents waiting on the same step do not, and every slow stage multiplies across the fleet.
VS Code addressed this by moving to Typescript Go, which the team measured at roughly 10x faster builds. Every automatic pull request opened by an agent needs that build-and-lint loop to get feedback and correct itself, so cutting build time changes how many agent tasks can be in flight at once. Kirschner described it as a massive improvement, one of the largest single gains in the transition.
The first wave of gains is easy to see and easy to describe: one experienced engineer builds a skill and a toolchain, ships quickly, and others copy the pattern. One example Kirschner gave was filing a large early pull request for an ask-questions tool, then bringing it to the team to try in the product. Within a few weeks it became a polished, designed experience, because the scrappy version made the idea concrete and opened the discussion. The interesting problems arrive after the volume of code, pull requests and issues grows. Community pull requests merged went up too, not down, which is not what most people expect when AI writes more of the code.
Letting agents run the app to close the feedback loop
Agents cannot judge UI work they cannot run, so VS Code invested in giving them direct access to the application. Kirschner's rule is blunt: if your agent cannot use your product directly to get the feedback of whether it all works, that is a large investment you keep paying for on every UI change. Two mechanisms do the work here: an automated component browser and a launch skill driven by Playwright, the browser automation library.
The component browser rebuilds and screenshots every component whenever the codebase changes, then highlights visual differences. A pull request that adds a back button to a customization screen triggers comparisons across affected components, so reviewers see unintended ripple effects, such as a moved element or a missing icon, without running the app themselves. This catches the classic agent failure where the model reports the UI looks perfect, and it is misaligned when you open it. Even with SVG and the latest models, that still happens. VS Code asks developers to attach a screenshot or video with every UI pull request, and the automated comparison fills that role.
The launch skill opens the editor, clicks through a named scenario, captures logs along the way, and verifies a fix before and after the change. An engineer can start that run, move to the next task, and return when the agent reports the result. VS Code is a web application running in Electron, all HTML, which is why Playwright works there. Kirschner pointed to Xcode MCP as the equivalent for iOS, where the agent builds an app, opens it, clicks through it, and takes screenshots without Xcode involved, and to Android tooling for the same purpose on other platforms.
This is the part of the harness that most teams skip. Desktop and web apps that agents can launch and drive get a self-correcting loop. Apps they cannot reach send every UI verification back to a human.
Mandatory GitHub Copilot code review before humans look
Code review is the next large investment after raw shipping speed. VS Code enabled automated review through GitHub Copilot and, in Kirschner's account, the team was not convinced at first. Review quality improved over the following weeks and months, and automated review became mandatory on every pull request. In a repository with no budget-based risk ceiling, every agent-opened pull request would otherwise trigger the most expensive review run by default.
The operating rule is that humans do not OpenAI pull request until automated review comments are resolved. GitHub Copilot code review now supports configurable effort levels, so a repository can dial the depth of analysis up or down based on risk and on the cost of the review run. Low, medium and high effort map to different cost-benefit trade-offs; more improvements were still coming at the time of the talk.
Combined with the component browser and the launch skill, review moves earlier. The agent produces evidence, the automated reviewer checks the diff, and the human reviews a pull request that has already been through two passes. Human attention moved later in the process instead of being removed.
Issue triage, error stacks and auto-filed fixes
Issue volume grew in both directions. VS Code, one of the largest open-source projects on GitHub, saw more high-quality reports because AI helps people write clearer issues in their own language, and more automated low-quality submissions at the same time. Manual triage stopped scaling, so agents now filter spam, enrich reports, translate them and assign area owners, with a human layer available to correct mistakes, including a browser extension for merging duplicates. That human feedback is fed back into the agent work, which is the part teams forget when they automate triage.
| Layer | What handles it | What a human still does |
|---|---|---|
| Triage of reports | Agents plus deterministic rules for filtering, enrichment, translation, owner assignment | Correct agent mistakes, merge duplicates via a browser extension |
| Error stacks | Fingerprinting and grouping of full-stack errors, automatic issue filing | Approve the pull request the agent opened |
| Pull request review | Mandatory GitHub Copilot review at a configured effort level | Merge, after all review comments are resolved |
Staged rollouts replace full-day-one releases
VS Code previously shipped release day at 100% once testing passed, which the team now describes as a yolo release. Installed applications make rollbacks expensive, so the release process increasingly resembles a staged web deployment.
Rollouts now go out in stages with monitoring of error logs and issues at each step, so a problem can be caught while only part of the audience is affected. This change was overdue, and agent-driven volume made the cost of a bad release higher than it had been.
VSC-Bench evals, prototyping and daily sprints
The third stage is learning faster, which starts with evals for an agentic product. VSC-Bench is VS Code's internal evaluation suite, and adding a scenario from an issue is designed to be as easy as possible. When an issue asks for a new scenario, an agent picks up a template and bootstraps the scenario. Developers can then hill climb against the suite, confirm improvements offline, and run online experiments afterward, which is the classic product lifecycle applied to an agentic product.
One published experiment shows why harness behavior matters more than model branding. A trivial eval that writes a file containing a five-character hello world string cost the most expensive model about 70 times more tokens than other models, and it was not the high-reasoning model. Token consumption is a property of the model interacting with the harness, not of model quality alone, and the team deliberately does not name the models in that write-up.
Prototyping changed shape as well. Kirschner reported that most of his work does not land as product pull requests. Prototypes start conversations in daily meetings, get revised overnight, and drive decisions faster than a monthly review cycle allowed. Smaller squads with durable ownership of narrow workstreams replaced broader, longer-running work.
The error stack example, end to end
The error pipeline is larger than triage. VS Code collects about 51 billion telemetry events per day, filters them down to error stacks that include a full stack, then groups and fingerprints them. A mix of agents and deterministic systems files an issue assigned to a specific area owner with a pull request attached that attempts a fix.
Kirschner showed one case where the agent traced a cancellation request missing from an RPC protocol, found the change responsible, and opened the pull request for a human to merge.
- Raw telemetry comes in at roughly 51 billion events per day.
- The pipeline filters to errors that carry a complete stack trace.
- Errors are grouped and fingerprinted to collapse duplicates.
- An issue is filed and assigned to the owning area.
- An agent opens a pull request with an attempted fix and initial diagnosis.
- A human approves the merge.
The grading of such a system is the useful detail. Triage is a mix of agents and deterministic rules rather than agents alone, and a human still approves the final pull request. The goal is a more stable codebase without engineers reading every raw stack trace.
FAQ
What are VS Code weekly releases?
VS Code weekly releases are the editor's current cadence of shipping a new version every week, replacing the monthly schedule that ran from VS Code 1.0. Microsoft's VS Code principal product manager Harald Kirschner described the change as a consequence of rebuilding the release system around AI agents.
When did VS Code switch from monthly to weekly releases?
The change was described at the AI Engineer World's Fair in San Francisco in 2026, with the team reporting the move several months earlier. The video was published on 3 October 2026, so treat the exact week of the first weekly build as unconfirmed from this source.
Did more AI usage per developer cause the weekly cadence?
No. Kirschner explicitly rejected token-maxing as the mechanism. Agent-ready codebases, faster builds, mandatory automated code review, staged rollouts and internal evals changed the system, and the cadence followed.
What is code survival and why does it matter?
Code survival is the share of agent-written code that gets committed instead of discarded. VS Code measured 55% with ChatGPT.1 and later 86% with Claude uses the trend as a proxy for developer confidence in shipping agent output.
What is Typescript Go used for in this workflow?
Typescript Go is the TypeScript toolchain ported to Go, and VS Code measured it at roughly 10x faster builds. Faster builds shorten the feedback loop for every agent-opened pull request, which matters when many agents wait on the same pipeline.
Does GitHub Copilot code review replace human reviewers?
GitHub Copilot code review is now mandatory on every VS Code pull request, but humans still approve the merge. The rule is that a human does not OpenAI pull request until automated review comments are resolved, which moves human attention later in the process rather than removing it.
How does VS Code handle the extra issues AI generates?
Agents filter spam, enrich and translate reports, and assign area owners, while a human layer corrects mistakes. Error stacks are fingerprinted and turned into issues with attached pull requests, and the initial triage mixes agents with deterministic rules.
What is the single most valuable investment if you only pick one?
Giving the agent a way to run the application, because that is the loop almost every team skips. Build speed, review and rollouts make agent output safe to merge, but an agent that can launch the app and check the result is the difference between a self-correcting loop and a human standing in the middle of every UI change.
Can smaller teams copy this system?
Parts of it transfer to smaller teams: an AGENTS.md map, skills that encode specialist knowledge, automated review and staged rollouts do not require scale. This article is not affiliated with Microsoft or VS Code, and the tooling changes quickly, so check current documentation before adopting any step. For Brazilian teams, resources such as Gustavo Dev Doido and the Crazystack Typescript track cover similar release engineering habits, and the Bootcamp do Dev Doido applies them in project work.
Related reading and a recap
The talk sits alongside two written pieces the team points to: an article on what 50,000 runs of a five-line eval taught the VS Code team about harness behavior and token cost, and guidance on improving token efficiency in GitHub Copilot. Both focus on the loop around the model rather than the model itself, which matches the release engineering argument in the talk.
If one idea carries across all three stages, it is that each acceleration reveals the next bottleneck. Faster shipping exposes review. Solved review exposes rollout risk. Controlled rollout exposes whether the team is building the right thing. Kirschner's closing advice is to find and fix that bottleneck rather than adding more agents to the same pipeline, and to keep tuning how agents get feedback, because the cycle repeats.
Skala Blog
Turn the talk into something people can read
The bottleneck Kirschner describes cuts both ways. A team can have a system that ships weekly and still lose the knowledge inside a recorded talk, because the ideas never leave the video. A Skala Blog article from a YouTube URL turns it into something searchable, quotable and easy to revisit.
If you have a video where you explain a system, walk through a lesson or argue for an opinion, the transfer is the same one this article made from a conference recording. Paste the link at Skala Blog, let the transcription run, and edit the generated article.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits