Share Episode         
         
Sauce Labs CTO Anoop Tripathi addresses the root causes of broken test suites and why teams frequently become numb to intermittent test failures. Anoop shares concrete lessons from his career, detailing how bad practices like embedding fixed sleep routines instead of signal-based waiting ruin test reliability. We discuss the necessity of designing products for testability from day one—such as using pair programming where one developer writes the implementation while the other writes the test suite, or building dedicated test interfaces directly into the application architecture. We also analyze the hidden business costs of poor quality, where engineering debt forces sales teams to spend their time managing upset clients instead of acquiring new revenue.

We explore organizational anti-patterns—such as teams claiming to be 'Agile' with one-year sprint cycles, or shipping debug builds to production because release builds continuously crash, highlighting a pair-programming model where one developer writes the code while another writes the corresponding tests

Finally, we tackle the dangers of chasing vanity metrics, from engineers writing automated assert pass statements to claim fake coverage, to organizations bragging about more code. Anoop distinguishes between output gain and outcome gain, warning that LLMs are creating a massive testing and review crisis by generating 20-page documentation files for minor features.

• Quality Iron Triange of Software
• Book: Sapiens
• ✨ Episode: DORA Report
• ✨ Episode: Grafana — Managing Open Source

• Warren - Proof of Quantum Consciousness - Paper
• Annop - Book: Genesis: Artificial Intelligence, Hope, and the Human Spirit

After a week of writing about vocabularies with nineteen and thirty-six keys, Mintlify is a relief. There is essentially one: x-mint. It appears in twenty-eight providers, 881 times across 92 OpenAPI documents, with three barely-used siblings — x-mint-groups, x-mint-global-content, x-mintlify-name — each showing up in exactly one provider.

Heygen, Honeycomb, Writer, Kalshi, Loops, Lightdash, Authlete, Retell AI, Prime Intellect, MoEngage, Portkey, Yapily, Sendcloud, Anchorage, Kajabi. Twenty-nine companies in the union.

Here is what is inside it, from HeyGen:

x-mint:
  href: /reference/generate-from-template-v2

A link. That is the common case. The key sits on an operation and says the human-readable documentation for this lives here, pointing at a path in the documentation site. It also shows up at the document root and on schemas, carrying a bit more, but the dominant use is that one field.

I like this for a reason that has nothing to do with cleverness. It is the smallest possible solution to a real problem, and the problem is one I complain about constantly: the OpenAPI document and the documentation site are two artifacts that describe the same API and usually have no idea the other exists. You can go from the docs to the reference because a human wrote a link. Going the other way — from a machine-readable operation to the page that explains it — is almost never possible. x-mint makes it possible, in one field, with no ceremony.

That matters more now than it did five years ago, and I want to be specific about why rather than just gesturing at agents.

When something automated is working with an API and hits a wall — the schema is technically complete but the semantics are unclear, there is an ordering constraint the contract does not express, an error means something particular that only the prose explains — the useful next move is to go read the documentation. But it can only do that if it knows where the documentation is. Right now the usual answer is a search, which is a guess. A pointer in the contract is not a guess. It is twenty-eight companies each saying, per operation, the explanation is exactly here.

That is a genuinely valuable piece of wiring and it is currently legible only to Mintlify.

I also want to note what Mintlify did not do, because in a series where I have counted thirty-six keys for one vendor, restraint deserves mentioning. Mintlify could easily have grown a dozen keys — theming, ordering, visibility, grouping, playground configuration. Every documentation platform has those concerns. Instead nearly all of it stayed in the platform’s own configuration file, and only the thing that genuinely has to be per-operation ended up in the contract. The three one-provider siblings look to me like experiments that did not spread, which is what healthy vocabulary growth looks like.

So this is the easiest ask in the series.

Register x-mint. One key. One file. It is a link relation and its shape is a small object with an href. The description could be three sentences. And because it is so simple, it has a decent chance of being the one other people copy — an operation-level pointer from a contract to its human documentation is not a Mintlify-specific idea, it is something every API should probably have, and registering it as a concrete, deployed, working example is how an idea like that graduates from one vendor’s convention to a pattern people reach for. I would genuinely like to see this one become general.

Sponsor the OpenAPI Initiative. Mintlify is a young company and this is the lightest version of the ask. But the product reads OpenAPI documents as its primary input, and the health of that format is a direct input to the business. Whatever the smallest meaningful membership is, it is worth doing, and it signals something to the twenty-eight customers publishing your key.

Get involved. The specific thing I would want from Mintlify in a Special Interest Group is the linking conversation. OpenAPI has externalDocs, which exists at the document, operation and tag level and is, by any honest measure, underused and underspecified. Mintlify has effectively built a better externalDocs for the operation case and has twenty-eight companies using it. That is not a criticism of the spec’s authors — externalDocs predates the world where a machine needs to follow the link. But it is a live example of a specification feature that did not quite work, replaced by a vendor key that did, and that is precisely the kind of evidence that improves a specification. Bring x-mint to the group as an argument about externalDocs, and the result might be that Mintlify gets to stop maintaining an extension.

Tomorrow, Fern, where the SDK naming decisions are the design decisions.

I have written twice recently about the two excuses I hear most often when I walk a company through their public API presence. The first is that they have partner APIs, not public APIs. The second is that if they publish their API documentation their competition will just copy what they do. Both excuses are really the same excuse wearing different clothes, and I have been looking for one link I can send to the people who keep making it. This is that link.

Go read Microsoft’s open source program page. Not the marketing, the program. It is a company that two decades ago called open source a cancer, publishing the operational details of how it now puts over 70,000 engineers on GitHub Enterprise Cloud across more than 100 GitHub organizations, consuming more than 200,000 open source components every month, “working in the open.” Their stated release policy is that Microsoft code “should be released under the MIT license absent a compelling reason to do otherwise.” The default is open. The burden of proof sits on the person who wants to keep something closed.

That is source code. That is the crown jewels, the actual implementation, the thing your API documentation is not. And a company with more intellectual property to lose than almost anyone on earth decided the default answer is yes.

They Did Not Get There By Being Careless

The part worth reading closely is how they made it safe, because this is where the “our competition will copy us” objection actually lives. Nobody at these companies is really afraid of the competition. They are afraid that publishing means losing control, and they have no machinery for publishing with control, so “no” is the cheapest answer available to them.

Microsoft built the machinery. Their program rests on three words — eliminate, automate, delegate. Eliminate the dated policies. Automate the detection, the inventory, the legal and security alerts. Delegate the decisions to the business groups closest to them. Every build at the company is connected to an internal inventory system that registers the open source it contains, generating a bill of materials, security alerts against known CVEs, and legal alerts when a component carries obligations. Every employee has an open source attorney assigned to their organization who is familiar with their business goals. The legal review, when one is triggered, arrives as a work item in the engineering system the developer already lives in, not as a meeting they have to beg for. They self-certify against OpenChain 2.1 so that everyone downstream can trust the result.

That is not recklessness. That is a governance program that makes the open path the cheap path, which is exactly what most API teams have never built and exactly what they are describing when they tell me their legal team will not let them publish. Your legal team has not said no. Nobody has ever built them a process for saying yes.

Their Release Checklist Is Your API Documentation Checklist

Here is the part that made me want to write this post. Microsoft’s checklist for releasing a project to the world maps almost line for line onto publishing an API publicly. It is the same work.

That last row is the one I want the partner-API crowd to sit with. Microsoft does not say everything must be public. They say decide, and they give both answers a real home. What most companies telling me “we only have partner APIs” have actually done is not decide. There is no inventory, no review path, no publishing pipeline, no cleanup pass, and no owner. “Partner” is the label they hang on the absence of a program, and it sounds strategic right up until you compare it to a market where their competitors made the other choice on purpose.

And Then There Is Microsoft’s Own API Estate

I would be a hypocrite if I held Microsoft up as the model and did not measure them with the same ruler I use on everyone else. Their API estate on APIs.io is 176 rated provider profiles across 1,453 APIs, and the blended estate rating is 34.0. The spread is 75.6 points, from Power Query at 80.0 all the way down to 4.4. Eleven surfaces are exemplar. Fifty-one are thin. Eighteen are barely there at all.

So the same company that built a world-class program for releasing source code has not run that program over its APIs. The open source side got the inventory, the automation, the default-yes policy, the assigned attorney, and the staffing requirement. The API side, by and large, did not — and you can see the result as a 75-point spread in what an agent meets when it shows up at different Microsoft doors.

That is the actual lesson here, and it is a more useful one than “be like Microsoft.” This was never about being big enough, brave enough, or unafraid of your competition. It is about whether anyone has built the program. Microsoft built one for source code and it worked at a scale nobody thought possible from that company. The same company’s API surface shows you, in public and in numbers, what it looks like when nobody has.

So Publish The Menu

If your position is that publishing your API documentation hands something to your competition, you are arguing that your API documentation is more sensitive than Microsoft’s source code. It is not. It is the menu, not the recipe, and not the kitchen. You still control access with authentication, authorization, rate limits, plans, and contracts — the same way Microsoft still controls what ships in a product while its code sits on GitHub in the open.

Meanwhile the cost of not publishing has changed. Your documentation is not just read by developers now. It is crawled, indexed, and turned into the training data and the live context that decides whether the agents your future customers are using know your API exists. Those agents do not know to email your sales team for a PDF. They evaluate the market they can see, and you are not in it.

Your competition already published. Microsoft published its source code and then published the playbook for how it did it safely. If you want to know where you actually stand before you argue about this any further, the Kin Score rubric is public — go read what it measures, look up your own company, then look up the three competitors you worry about most.

I’ve read all the stories this week about the dangers of AI. That we have to slow down, because of just how dangerous AI is. I see lots of smart folks falling for the stories and becoming skeptical that it is not just a marketing tactic of these AI companies. Which is partly true, but when you zoom out and consider the wealth of information being omitted and the general ignorance of how technology operates at scale, you are left concerned, but in a very different way.

Agents are just autonomous compute. Not really anything new, you just have a robust knowledge base behind it now by default to help you execute the automation. The cloud really allowed us to rapidly scale our automation, but you still had to deploy the knowledge behind it–AI has combined compute and the knowledge in ways that allow you to crawl, probe, hack, automate, and run a myriad of tasks without really understanding what you have available to you. We are putting this capability into the hands of every individual who wants it. No training or licensing required, the only thing limiting you is what you are willing to spend on your agents.

Next you have large enterprises who have been massively scaling their IT infrastructure for this entire century, rapidly expanding the surface area of the technology they need to operate their businesses. When you combine that with recent efforts to reduce payroll and push teams to do more with less, hire younger lower paid workers who likely weren’t around to build any of these systems. You end up with a very porous, fragile, and sprawling surface area of sites, applications, APIs, and cobbled together 3rd-party services. This makes for an amazingly insecure business surface area that management doesn’t fully understand how it works. These are the people choosing to go all in on artificial intelligence, mandating that their teams use AI for everything.

After that you have a wonderfully exploitative ecosystem of 3rd-party services that are backed by venture capital who are anywhere from their series A through D, which are moving fast and breaking things, while also reaching a point where more profit MUST be extracted to satisfy investors. With each 3rd-party service boring a hole into the firewall of each business, providing another surface area for crawling, probing, and extracting, while also potentially falling short on security, privacy, and what is needed to defend against the onslaught of autonomous compute being unleashed in this moment. The average SaaS or 3rd-party portfolio of companies has massively grown in the last decade, outsourcing business onto the open web.

This is the environment we are framing AI as dangerous in. Is it AI that is dangerous, or the way we do business in 2026? When you give researchers at OpenAI, Anthropic, or any other startup access to robust agentic autonomous compute and have it run without rigorous guardrails, or you give your average employee within an enterprise the same robust agentic autonomous compute. What did you think would happen? When business leadership goes all in on using AI for everything after two decades of connecting every part of their physical and virtual business to the Internet. What did you think was going to happen? Every enterprise and startup I’ve had access to internally is a shitshow. Moving fast. Poorly managing risk. Operating completely insecurely about being left behind and rendered meaningless by the market.

Is it AI that we need to slow down, or business. Isn’t that what regulation is for? Finding the right velocity for safely and securely operating businesses within different industries? Yes, we should regulate AI. But we should also be regulating business in general. You can’t be all anti-regulation for business, pro venture capital, and go all in on AI, and then pretend to be concerned about what is happening. AI isn’t dangerous. AI unleashed on half-ass business operations is dangerous. AI unleashed on half-ass Internet enabled supply chains is dangerous. AI unleashed and mandated by management that doesn’t understand AI or their IT operations is dangerous. Let’s stop pretending AI is going to kill us, when there is a laundry list of things that will kill us that we’ve been ignoring for years, but all of a sudden we want to enable with AI.

There is nothing more frustrating during a focused coding session than waiting several minutes for a large solution to compile after changing just a couple of lines of code. For engineering teams working on microservices, enterprise web APIs, or desktop client apps, sluggish inner-loop builds eat away hours of productive engineering time every single week.

Before fine-tuning your project system, make sure you have installed the latest release through our dedicated Visual Studio 2026 download hub, and check out our overview of what is new in Visual Studio 2026. In this practical optimization guide, we walk through configuring out-of-process parallel MSBuild nodes, setting up solution-wide local artifact caching, and eliminating cascading project recompiles to cut your build times by up to 65%.

Table of Contents

• Why Incremental Build Times Matter for Developer Velocity
• Enabling Out-of-Process Parallel MSBuild Nodes in Visual Studio 2026
• Configuring Solution-Wide Local Artifact Caching in Directory.Build.props
• Predictive Dependency Graphing to Avoid Cascading Recompilations
• Hardware and Anti-Malware Exclusions for Blazing-Fast Disk I/O
• Verifying Your Speedup with MSBuild Structured Logging
• Frequently Asked Questions (FAQ)
• End Note

# Run parallel multi-core compilation across all available CPU nodes
dotnet build MySolution.sln -m -v:m

<Project>
  <PropertyGroup>
    <!-- Enable Visual Studio 2026 Build Acceleration -->
    <AccelerateBuildsInVisualStudio>true</AccelerateBuildsInVisualStudio>

    <!-- Activate local content-addressable compilation caching -->
    <UseBuildCache>true</UseBuildCache>

    <!-- Share compiled NuGet and intermediate artifacts across projects -->
    <BuildCachePath>$(MSBuildThisFileDirectory).buildcache</BuildCachePath>
  </PropertyGroup>
</Project>

# Generate a detailed MSBuild binary log to diagnose compilation bottlenecks
dotnet build MySolution.sln /bl:build.binlog

Over the past few months, we have continued shipping monthly Visual Studio 2026 releases, delivering improvements across all stages of the development cycle. In this blog post, we’ll recap everything that changed from version 18.7 through 18.10 (released this month) that is relevant for C++ developers. This includes new tools for maintaining and navigating C++ projects, along with Git, GitHub Copilot, and debugging improvements that support the way large native codebases are built.

Some headlines include the GitHub Copilot modernization experience (now generally available) to guide you through MSVC upgrades, a deeper semantic index to accelerate code navigation, discoverable MSVC Build Tools versions across installations, and support for Git worktrees and submodules directly in the IDE.

For the previous set of updates, see What’s New for C++ Developers in Visual Studio 2026 versions 18.1 through 18.6.

C++ reliability improvements

Across Visual Studio 2026 versions 18.7 through 18.10, we fixed 272 C++ bugs reported through Developer Community and internal testing.

These fixes include C++ IntelliSense diagnostics and include resolution, compiler and code-generation issues, a std::regex regression, debugger stability, and a C++ Solution Explorer context-menu issue.

Modernize and manage C++ projects

Upgrade MSVC projects with GitHub Copilot

GitHub Copilot modernization for C++ is now generally available. This modernization agent helps upgrade MSBuild and CMake projects to a newer version of the Microsoft C++ (MSVC) Build Tools. It assesses the codebase, builds an upgrade plan, updates project settings and source code, and validates fixes for issues such as stricter conformance, deprecated standard library functions, new warnings, and linker errors.

The agent has two flow modes. Automatic mode proceeds through assessment, planning, and execution with less intervention. Guided mode pauses between stages so you can review the scope and proposed approach before changes are applied. You can switch modes as the upgrade progresses.

Before you start, use the Visual Studio Installer to select the GitHub Copilot modernization optional component. You also need a GitHub Copilot subscription and an MSBuild or CMake C++ project.

Right-click a solution or project in Solution Explorer and select Modernize or enter @Modernize in GitHub Copilot Chat. For MSBuild projects that reference an unavailable MSVC version, the Setup Assistant can also offer to launch the modernization agent after retargeting the project. The agent focuses on issues caused by the MSVC upgrade and adapts its task list when one fix reveals another problem. You remain in control of the scope and can stop, redirect, or resume the work.

Use PackageReference in native C++ projects

Visual Studio 2026 introduced experimental support for NuGet PackageReference in native .vcxproj projects. Package references live directly in the project file, support transitive dependency resolution, use NuGet’s global package cache, and can be conditioned by configuration or platform with normal MSBuild syntax.

Enable the experience in a project or Directory.Build.props:

<Project> 
    <PropertyGroup> 
        <EnableNativePackageReferenceSupport>true</EnableNativePackageReferenceSupport> 
    </PropertyGroup> 
</Project>

You can then edit the project file directly or use Manage NuGet Packages in Visual Studio:

<ItemGroup>
    <PackageReference
        Include="Microsoft.Windows.CppWinRT"
        Version="2.0.240405.15" />
</ItemGroup>

We continue to recommend vcpkg for acquiring and managing C and C++ libraries. But NuGet PackageReference is useful for NuGet-distributed SDKs and binaries, internal NuGet feeds, and repositories that need a consistent distribution workflow across native C++ and .NET projects.

The initial implementation is off by default and remains unsupported for C++/CLI projects targeting .NET Framework versions and limited for some cross-language project references. Read NuGet PackageReference for C++ Projects in Visual Studio for current limitations and workarounds.

Discover pinned MSVC Build Tools versions across installations

Visual Studio 2026 can now locate an exact pinned MSVC Build Tools version (major.minor.patch) in another Visual Studio or standalone Build Tools installation. This helps teams update the IDE independently while retaining a known-good compiler version for reproducible local and continuous integration builds.

Previously, Visual Studio only searched other installations for a matching toolset if your current install had no toolset installed at all for your target platform toolset version. This change removes this restriction.

Opt in with EnableVCToolsVersionDiscoveryand specify the required VCToolsVersion:

<PropertyGroup>
    <EnableVCToolsVersionDiscovery>true</EnableVCToolsVersionDiscovery>
    <VCToolsVersion>14.43.34604</VCToolsVersion>
</PropertyGroup>

When the requested version is not available in the current installation, Visual Studio searches other installations instead of requiring a manually assigned VCToolsInstallDir. This gives teams two complementary paths: use the modernization agent when it is time to upgrade or pin an exact MSVC Build Tools version when compatibility and repeatability are the priority. See the Visual Studio July update post for more.

Preview the next MSVC Build Tools updates

Work on MSVC Build Tools version 14.52 continued with monthly updates to the preview builds shipping in the Visual Studio Stable Channel (and even faster updates in the Insiders Channel).

In the July and August previews, frontend and modules updates include support for default-initialized new[] expressions in constant evaluation with modules, more robust argument-dependent lookup and module serialization, and clearer diagnostics for calling-convention mismatches, incompatible compiler options, and unusable compiled libraries.

The backend added Armv9.2 LUTI2 support and improved ARM64 vectorization, load pairing, and instruction selection. x64 and x86 updates expanded APX instruction selection and improved conditional comparisons, vector constants, and tail calls. The optimizer gained additional loop, induction-variable, devirtualization, and expression-reassociation improvements. The linker and debugging tools also improved incremental linking, PDB growth and determinism, large debug-information streams, and module type merging.

AddressSanitizer can now use the MSVC disassembler as a fallback instruction-length decoder, reducing unrecognized-instruction failures, and diagnoses incompatible use with /clr. These previews also include Code Analysis reliability improvements and fixes for compiler crashes, miscompilations, module regressions, and invalid AVX-512 code generation.

For the detailed change lists, see the July 2026 and August 2026 MSVC Build Tools preview posts. You should also look at the STL Changelog for a full list of standard library improvements.

Navigate large C++ codebases faster

Whole Codebase Indexing is a preview feature that adds richer symbol-use information to the C++ browse database. Instead of repeatedly computing some relationships on demand, Visual Studio can reuse semantic data that has been indexed as you work.

The deeper index improves features that use the IntelliSense engine, including semantic colorization, Go to Definition, and Find All References. It also gives Copilot’s find_symbol tool faster access to these code navigation features and enables CodeLens references for C++. In Microsoft’s testing with Bullet3 and LLVM, many navigation and colorization scenarios improved by 2x or more, although results and indexing costs vary with the codebase.

To enable the feature, open Tools > Options > Languages > C/C++ > IntelliSense > Browsing & navigation > Whole codebase semantic index, then enable faster code navigation and colorization. Learn more in Faster Code Navigation and GitHub Copilot Tools with Whole Codebase Indexing.

Optimize the builds you run every day

GitHub Copilot build performance for Windows now evaluates iterative builds as well as clean builds. That distinction matters because an optimization such as a precompiled header can make a full rebuild slightly slower while improving the edit-build-debug loop that developers repeat throughout the day.

Ask Copilot Chat to “make my build faster”. The agent captures a baseline, proposes an optimization, measures the result, and rolls back changes that do not help. If a change is not beneficial in a clean build, the agent can test a comparable iterative build before deciding whether to keep it.

Review changes with GitHub Copilot

Copilot review now scales from a selected block of code to working changes, commits, and pull requests. Select any block of code in the editor and choose Copilot Actions > Review Selection for a focused review. Findings appear as inline comments so you can inspect and address them in context.

For a conversational review, switch to the Git agent in GitHub Copilot Chat. Ask it to review uncommitted work, select the Copilot review control in Git Changes, or attach a commit in chat. You can also start this review from the post-commit infobar or from a commit in the Git Repository window. Findings appear inline and in a navigable list, and you can continue the conversation to investigate a finding or request a suggested fix.

Visual Studio also provides a local commit-review workflow. Enable Review Git changes locally and provide suggestions from comments under Tools > Options > GitHub > Copilot > Source Control Integration, then right-click a commit in the Git Repository window and select Review Commit. You can select two commits to review the range between them. These reviews remain local to the Visual Studio session. Both review workflows support GitHub and Azure DevOps repositories.

Copilot review is another source of feedback, not a replacement for compiler diagnostics, Code Analysis, tests, or human review. It is most useful when you give it a clear scope, such as reviewing ownership changes, thread synchronization, error handling, or API usage before opening a pull request.

The broader pull-request experience also lets you inspect changes without checking out the branch, comment and resolve threads, review commits, approve changes, and complete or merge the pull request from Visual Studio. For a walkthrough, see Review Pull Requests Without Leaving Visual Studio.

Work across large Git repositories

Keep multiple branches active with worktrees

Visual Studio 2026 added integrated Git worktree management. A worktree gives another branch its own working directory, so you can keep some half-finished C++ changes intact while investigating a bug or preparing a fix on another branch.

In the Git Repository window, right-click a branch and select New Worktree From.

You can create a worktree from an existing branch, a new branch, or a commit, then open it in the current window or a separate Visual Studio instance. Worktrees appear alongside branches and can be removed from the same window when they are no longer needed.

Manage submodules without leaving Visual Studio

Submodules are also first-class objects in Visual Studio 2026. The Git Repository window has a dedicated Submodules section, Git Changes shows their state, and the repository picker displays the relationship between the parent repository and its submodules.

You can add, update, remove, discover, and navigate submodules in the IDE. They are read-only by default, which helps prevent accidental edits to a dependency. To work inside them, go to Tools > Options > Source Control > Git, find Automatically activate multiple repositories, and select Yes, include submodules.

Other Git improvements include a multi-file summary diff for working changes, commits, and pull requests, comparison of a historical file version with the working tree, pull-request activity timelines, and automatic completion after required approvals and policies pass. Read the Visual Studio August update for the full set.

Debug C++ applications

Attach to processes in Podman containers

Visual Studio 2026 extends Attach to Process to Podman containers. Start the container, open Debug > Attach to Process, choose Podman as the connection type, select Find, and then choose the process you want to debug. The experience supports both .NET and C++ containers without additional debugger configuration.

Investigate bugs with focused tests

The Debugger Agent has also added a test-driven investigation workflow. Starting from an issue, stack trace, or intermittent failure, it can create or identify a focused test, debug through the failure using runtime state, propose a fix, and rerun relevant tests. This builds on the agentic issue-to-resolution experience covered in the previous roundup. See The Visual Studio Debugger Agentic Workflow Gets a Test-Driven Upgrade for details.

More control over Copilot

Share instructions and custom agents across an organization

Visual Studio 2026 added organization-level instructions and custom agents. GitHub organization and enterprise owners can publish shared agents for workflows such as build triage, dependency upgrades, portability checks, or code-review conventions. Visual Studio detects those agents and identifies their organization source in the agent picker. Organization-level instructions can express shared preferences, but they are not a policy-enforcement mechanism. If you’re an administrator, see Preparing to use custom agents in your organization or Preparing to use custom agents in your enterprise.

Choose the right model and thinking effort

Model controls also provide more information about capabilities, context-window size, and cost. For supported models, you can choose low, medium, or high thinking effort. Lower effort suits straightforward questions, while higher effort can help with architecture, difficult template diagnostics, algorithms, or hard-to-reproduce concurrency issues.

Bring your own model

Bring Your Own Model (BYOM) lets you connect that agent to a Microsoft Foundry deployment or use your own key with another supported provider, whether or not you are signed in to GitHub. The release notes also refer to this capability as Bring Your Own Key (BYOK).

BYOM is available as a preview and supports Microsoft Foundry, OpenAI, Anthropic, and Ollama, including custom endpoints for OpenAI and Ollama. Model capabilities vary, and not every model supports every Agent Mode tool. Read Bring Your Own Model in Visual Studio for setup, provider, and governance details.

Next Edit Suggestions Improvements

Long-distance next edit suggestions are now available. Copilot can suggest related edits elsewhere in the active file when Extended range suggestions are enabled under Tools > Options > Text Editor > Inline Suggestions.

• Did you know? There is also a “Next edit suggestions eagerness” setting in Tools > Options, giving you control over how frequently these suggestions appear. Use the search box in the Options UI to find it fast.

Try Visual Studio 2026 and share your feedback

Download Visual Studio 2026 to try these new features and benefit from the latest bug fixes and performance improvements. Also check out the release notes for a full list of everything that’s new.

Want to get ahead? Get a sneak peek at Visual Studio 2026 version 18.11 improvements now via the Insiders Channel.

We want to hear how these changes work in real C++ projects. Report problems or suggest improvements through Help > Send Feedback in Visual Studio and visit Developer Community.

The post What’s New for C++ Developers in Visual Studio 2026 (18.7 – 18.10) appeared first on C++ Team Blog.