For most teams, shipping faster with AI turns out to be the easy part. The harder question — one that took the VS Code team years of iteration to answer — is whether the entire delivery system around the code can keep pace.
VS Code serves more than 50 million users with a relatively small engineering team. Until recently, that meant monthly releases. Today, the cadence is weekly, with daily product feedback loops on top. The change didn’t come from asking developers to work harder. It came from rebuilding the pipeline that surrounds the code: CI/CD, code review, issue triage, error handling, and the feedback loops that tell a team whether it shipped the right thing at all.
Faster code is only layer one
The VS Code team frames the challenge in three layers. The first — shipping faster — is relatively easy to unlock with AI coding tools. Agents write code quickly, and developers can review and merge more of it. But speed alone exposes the second layer: quality. When agents are generating pull requests continuously, every bottleneck in the build and review system compounds. A slow CI run that was tolerable at monthly release cadence becomes a real blocker when ten agents are working in parallel.
The solution here was partly infrastructure. Switching to TypeScript Go gave a ten-times build speed improvement. At the scale of parallel agent work, that kind of multiplier has outsized impact on how fast any individual fix can land.
The third layer is the one most teams miss: shipping the right thing and learning from what ships. This requires product taste, and it requires fast feedback loops that surface whether a change worked. Without both, faster shipping just means faster accumulation of things that didn’t quite land.
Making the codebase readable to agents
One of the more practical ideas from the VS Code approach is the concept of agent-readiness — treating the codebase as something agents need to navigate, not just humans. That means maintaining lightweight documentation files (called `agents.md`) that map the codebase for agents, and encoding specialist knowledge into callable skills. Accessibility best practices, for example, used to require pulling in a dedicated specialist. Now that expertise is distilled into a skill any agent can invoke.
A useful litmus test for agent-readiness: can a non-engineer make a meaningful change to the codebase and have it accepted by engineering with minimal rework? If the answer is no, the codebase is still organized primarily for human experts, and agents will struggle with it too.
The UI problem agents still can’t solve alone
One persistent challenge is UI verification. Agents routinely report that a UI change looks correct when it doesn’t. The VS Code team built a component browser that takes automated screenshots of every UI component on every change, diffs them, and flags regressions. Every pull request must include a screenshot or video of the implemented change before a human reviewer looks at it.
They also built a `/launch` skill that uses Playwright (a browser automation tool) to open VS Code, click through a scenario, and validate before-and-after state — so agents can self-verify UI fixes without requiring a human to click through every time.
The broader point is that closing the UI feedback loop requires deliberate tooling. Agents need a way to see what they built.
Automation at the top of the funnel, humans at the exceptions
The same logic applies to issue triage. AI tooling has made it easier for users to file better bug reports, but it has also increased the volume of automated and low-quality submissions. The VS Code team runs a pipeline that filters spam, enriches and translates issues, and assigns them to area owners — all before a human touches them. A Chrome extension lets human reviewers flag incorrect assignments, and that feedback flows back to improve the pipeline.
At the far end, telemetry from 51 billion daily events filters down to error stacks with full traces, which the pipeline fingerprints, buckets, and uses to file roughly ten issues per day — each assigned to an area owner, each with an automatically opened pull request containing an initial diagnosis. Humans approve the fix; the mechanical work is largely done.
What the cadence shift actually required
The move from monthly to weekly releases — and now to daily product feedback loops — wasn’t primarily a question of writing more code. It required staged rollouts with monitoring at each step (rolling back a desktop install is expensive; gradual rollout is the cheaper way to derisk). It required eval suites that could be bootstrapped from existing issue templates. It required rethinking what a daily stand-up is for.
The prototype has replaced the release plan. Most prototypes don’t land directly as pull requests. They start conversations, and the conversations drive the daily product discussion. That’s a different rhythm from planning a monthly release, and it requires different infrastructure — both technical and social — to sustain.
For teams watching this from the outside, the lesson isn’t “use AI to write more code.” It’s that AI-generated velocity will eventually expose every slow or fragile part of the delivery system. The teams that benefit most will be the ones that treat those bottlenecks as the real problem to solve.
Text summarized and optimized using Anthropic’s models and reviewed by a human.