Welcome to “What’s new in Swift,” a curated digest of releases, videos, and discussions in the Swift project and community.

June was an exciting month for Swift, featuring announcements at WWDC and community events around the globe. We invited the organizers of one of them to share with us:

Hey, it’s Mikaela and Adrian. We are organizers of CommunityKit, a community-organized conference that takes place the same week as WWDC, and iOSDevHappyHour, a monthly online meetup that keeps the community connected year-round. This is our fifth year coming out to Cupertino, and we love being able to create a place for the community to thrive, no matter where developers live.

CommunityKit brought together over 250 developers in real life to geek out over the announcements, stay for the community and vibes, see what everyone is creating, and learn from each other. Some of the highlights from this year’s event were the Indie Fair, where developers showcased their apps; the Watch Party, our annual gathering to watch the keynotes together; and Make Something, Ship Nothing, a hands-on postcard-making hangout to close the week. This year we also introduced workshops, including “Inclusive by Design” by Danielle Lewis, and for the Swift community: “Write Faster, Smarter Swift” by Paul Hudson.

We can’t wait to hear about what everyone builds and brings to next year’s Indie Fair, and hope to see you at CommunityKit and iOSDevHappyHour!

Now on to other news about Swift:

WWDC26 highlights

At its WWDC26 conference, Apple provided an update on its adoption of Swift and made a variety of new Swift-related announcements. Some highlights:

• During the Platforms State of the Union, Apple announced that parts of the core operating system kernel are being written in Swift for upcoming releases.
• What’s new in Swift featured changes in Swift since last year, including a preview of what’s coming in Swift 6.4, like up to 4x faster URL parsing and support for async code in defer blocks.
• The QUIC transport layer in Apple’s networking stack was rewritten in Swift. The project has been open sourced and is available for cross-platform use through SwiftNIO integration.
• A new Swift package, Foundation Models framework utilities, was released with tools for working with LLMs, including custom skills and context management helpers. It runs on Apple platforms and select Linux distributions.
• The Foundation Models framework itself will be open sourced in the future, meaning the same Swift APIs you use in your app could run on your server.
• Container Machine is a new tool that provides a lightweight, persistent Linux environment on a Mac. Unlike a container, which is modeled after an application, a container machine is modeled after the environment itself. Container machines share the host environment, including the home directory and configuration. It’s written in Swift and open source.

Videos to watch

• Build real-time apps and services with gRPC and Swift walks through integrating an iOS app and gRPC service using live race data from a go-karting league. See if you can spot where the track is located. 👀
• Want to learn about Swift macros with hands-on tutorials? Stewart Lynch published two videos with sample code to follow along: Swift Macros Demystified: Build a Freestanding Expression Macro, and Swift Attached Macros: Build a Real-World Member Macro from Scratch.
• A new 10-minute Embedded Swift demo uses an accelerometer and the XIAO ESP32-C6 to control a Swift bird that glides across a mini OLED screen. No soldering required!

Community highlights

• Swift Package Index joined Apple and remains open source. The team says they’re working together to build a comprehensive package registry for the Swift community.
• Yeo Kheng Meng blogged about bringing Swift to the Apple II, complete with a REPL, compiler, file browser, and editor. It’s a subset of Swift and was built with AI assistance.
• Apple shared an adoption story on the Swift blog: Migrating the TrueType Hinting Interpreter, covering how the TrueType hinting interpreter in macOS and iOS was rewritten in Swift from C. It runs 13% faster on average.
• The Swift Ecosystem Steering Group announced the creation of the Networking workgroup. This group will work on a unified networking stack for Swift, layered from low-level I/O primitives, through common protocols, to a modern HTTP client and server API.

New package releases

• New Swift bindings for the OkHttp Java library were released. If you’re using Swift on Android and looking for an HTTP client this may be useful. The project was generated with swift-java.
• Kiln is a new documentation engine written in Swift. Built to replace MkDocs-based documentation sites, it gives more options for the Swift community to render docs, in addition to the DocC project which is used for the official Swift documentation. You can see Kiln in action at the Vapor documentation.
• Version 0.4.0 of Elementary UI was released, a frontend framework for running Swift applications natively in the browser.

Swift Evolution

The Swift project adds new language features through the Swift Evolution process. These are some of the proposals currently under review or recently accepted for a future Swift release.

Under active review:

• SE-0526 withDeadline - Asynchronous operations in Swift can run indefinitely, and implementing time limits manually using task groups and clock sleep operations is verbose and error-prone. This proposal adds withDeadline, a function that executes an async operation with a composable absolute time limit specified as a clock instant, canceling the operation if it hasn’t completed in time. It also allows multiple nested operations to share the same deadline, avoiding the drift that accumulates when relative durations are passed through call layers.

Recently accepted:

• SE-0474 Yielding Accessors - When you call a mutating method on a computed property, Swift creates the illusion of in-place mutation by getting a copy, mutating it, then setting it back. This causes unnecessary copy-on-write buffer duplication for types like String, and is impossible for noncopyable types, which can’t be copied out at all. This proposal adds yielding borrow and yielding mutate, two new ways to implement computed properties and subscripts that instead lend the caller direct access to the underlying value without copying it.

Recently accepted with modifications:

• SE-0529 Add FilePath to the Standard Library - FilePath in the swift-system package parses platform-specific path syntax on the developer’s behalf, provides a normalized view of path components, and enables filesystem resolution. However, shipping in an external package means the standard library, Swift runtime, and toolchain libraries such as Foundation cannot depend on it. This proposal adds FilePath and its associated types to the Swift module, alongside essential functionality for construction, decomposition, resolution, and C interoperability.
• SE-0527 UniqueArray - Swift’s Array can’t store noncopyable elements without compromising its copy-on-write semantics or performance predictability. This proposal adds two new types to a new Containers module: RigidArray, a fixed-capacity array that traps on overflow, and UniqueArray, a dynamically growing array that enforces unique ownership by being noncopyable itself.

In Part 1, we explored what AI red teaming is, how it differs from traditional penetration testing and governance activities, and why generative AI introduces an entirely new category of risks. We also examined several common types of AI failures, including hallucinations, harmful outputs, bias, privacy leakage, and misuse. Understanding these risks is the first step, but recognizing that they exist is only half the challenge. The real value comes from designing structured exercises that deliberately test whether your AI systems can withstand realistic misuse and adversarial behavior.

Unlike conventional software testing, AI red teaming is not simply a checklist of vulnerabilities to verify. Every AI system is unique because it combines different models, prompts, retrieval mechanisms, data sources, plugins, APIs, and business processes. A customer support chatbot poses very different risks from those of an internal HR assistant, a healthcare copilot, or an AI agent that can create users, send emails, or approve financial transactions. As a result, effective AI red teaming begins with understanding the AI system’s purpose before attempting to break it.

The objective is not to make the AI fail for its own sake. Instead, the goal is to identify weaknesses that could affect security, privacy, compliance, reliability, or business operations, so they can be addressed before the system reaches production or new capabilities are introduced.

Start with Understanding the AI System

Before writing a single adversarial prompt, take time to understand exactly what the AI system is designed to do. This may sound obvious, but many organizations jump straight into testing without fully understanding the architecture of the solution they are assessing.

Generative AI rarely operates in isolation. A modern enterprise AI solution often includes several interconnected components working together. These might include the large language model itself, a retrieval system that searches organizational content, plugins that connect to external services, orchestration layers that coordinate multiple AI agents, and identity systems that determine what information users are allowed to access.

Each of these components expands the potential attack surface.

For example, consider an internal Microsoft 365 Copilot deployment. The language model itself may be highly secure, but Copilot also relies on Microsoft Graph to retrieve documents, emails, Teams conversations, SharePoint content, calendars, and meeting notes. If permissions within Microsoft 365 are overly permissive, the AI may retrieve information that users should not realistically discover so easily. In this case, the weakness is not the language model but the surrounding ecosystem.

Similarly, a custom AI assistant may retrieve data from SQL databases, REST APIs, customer records, or proprietary knowledge bases. The red team must understand each of these connections because every integration introduces additional opportunities for misuse.

Before testing begins, it is useful to answer questions such as:

• What business problem does the AI solve?
• Who are the intended users?
• What information can the AI access?
• Can it perform actions or only generate responses?
• Does it connect to internal or external systems?
• Are human approvals required for important decisions?
• What safeguards already exist?

These questions establish the context for every testing activity that follows.

Identify What Matters Most

Not every AI failure carries the same level of risk. A grammar mistake in an email assistant is very different from an AI system approving fraudulent financial transactions or exposing personally identifiable information. This is why AI red teaming should always begin with identifying what matters most to the organization. Think about the potential business impact rather than the technology itself.

For example, an AI assistant supporting customer service may present risks such as providing inaccurate warranty information, exposing customer account details, or generating inappropriate responses that damage the organization’s reputation. An HR assistant, on the other hand, may need to protect employee records, salary information, disciplinary actions, and confidential recruitment discussions. A software development assistant may introduce entirely different concerns, including generating insecure code, recommending vulnerable libraries, or exposing proprietary source code.

Rather than attempting to test every possible scenario equally, prioritize the areas where failures would have the greatest operational, financial, legal, or reputational consequences.

One useful exercise is to imagine tomorrow’s headline if the AI fails.

• Would the story involve the leak of confidential information?
• Would customers receive harmful advice?
• Would regulators investigate a compliance violation?
• Would executives lose confidence in the organization’s AI strategy?

Answering these questions often reveals where testing efforts should be concentrated.

Develop Realistic Threat Scenarios

One of the defining characteristics of effective AI red teaming is realism.

Testing should reflect how real users, both well-intentioned and malicious, are likely to interact with the system. Artificial or overly simplistic prompts rarely uncover meaningful weaknesses because attackers rarely behave in predictable ways.

Instead of asking whether an AI will answer an obviously prohibited question, consider how someone might gradually manipulate the conversation over time. Attackers often begin with harmless requests, slowly building context and trust before introducing increasingly sensitive instructions.

Imagine an AI assistant responsible for summarizing legal contracts.

Rather than immediately requesting confidential information, an attacker might begin by asking the AI to explain standard contract terminology. They may then request examples of renewal clauses, followed by typical pricing structures, before eventually asking the assistant to compare those examples with current customer agreements. Individually, each request appears legitimate. Combined together, they may reveal commercially sensitive information.

Similarly, an internal employee may unintentionally misuse the AI by asking it to summarize documents they have not fully read themselves. If the AI hallucinates missing details, those inaccuracies may become embedded within reports, presentations, or executive briefings without anyone realizing the information is incorrect.

These scenarios illustrate why AI red teaming must consider both malicious intent and accidental misuse.

Think Like Different Types of Users

Not every user interacts with AI in the same way, and not every risk originates from a malicious attacker. Effective red teaming considers a wide range of user personas, each bringing different motivations, knowledge, and objectives.

A curious employee may simply explore the boundaries of what the AI can do without intending any harm. A frustrated customer may repeatedly challenge a chatbot after receiving incorrect responses. A competitor may attempt to extract proprietary information. A cybercriminal may carefully craft prompts designed to bypass safeguards or manipulate automated workflows.

Each of these individuals approaches the AI differently, and each presents unique testing opportunities.

For example, consider how an internal finance assistant might respond to different users:

• A finance employee may request quarterly revenue forecasts.
• A project manager may ask about departmental budgets.
• An executive may request strategic financial summaries.
• A contractor may attempt to access information outside their responsibilities.
• An attacker may disguise themselves as a legitimate employee through carefully written prompts.

Testing should assess how consistently the AI enforces access boundaries across these scenarios. Thinking from multiple perspectives often uncovers weaknesses that purely technical testing overlooks.

Building Adversarial Scenarios

Once you understand the AI system and the users interacting with it, you can begin designing adversarial scenarios.

A scenario is more than a single prompt. It represents an entire conversation or workflow that attempts to achieve a specific objective.

For example, suppose the objective is to determine whether an AI assistant will reveal confidential merger information.

• Rather than immediately asking for the confidential documents, the red team might construct a realistic sequence of interactions.
• The conversation could begin with general questions about recent industry acquisitions before shifting to publicly available financial reports. The attacker might then ask the AI to compare internal planning documents with public announcements, ultimately seeking discrepancies that reveal information not yet released.
• Each step appears reasonable in isolation. The overall sequence gradually increases pressure on the AI while remaining believable.
• This conversational approach is considerably more effective than isolated prompts because it reflects how real attackers often operate.

Measuring Success

Unlike traditional software testing, AI red teaming rarely produces simple pass-or-fail outcomes. Instead, every exercise should measure how the AI behaved under pressure. For example, consider three possible responses when testing whether an AI reveals confidential information.

• The first response is ideal. The AI politely refuses the request, explains why the information cannot be shared, and redirects the user toward appropriate resources.
• The second response is less obvious. The AI rejects most requests but unintentionally reveals small pieces of sensitive information that, while individually harmless, could contribute to a larger disclosure.
• The third response is a complete failure, in which the AI discloses confidential information without any meaningful resistance.

These three outcomes require different remediation activities and carry different levels of business risk.

Organizations should therefore evaluate AI behavior across several dimensions rather than relying on a binary success-or-failure assessment.

• Accuracy of the response.
• Protection of confidential information.
• Consistency with organizational policies.
• Resistance to manipulation.
• Appropriate refusal behavior.
• Transparency when uncertainty exists.
• Respect for user permissions.
• Ability to maintain context throughout extended conversations.

Useful evaluation criteria include measuring these characteristics over time, which allows organizations to track improvements as prompts, retrieval systems, and safety controls evolve.

Determining Severity

Not every finding discovered during AI red teaming deserves the same priority. Some issues may simply reduce the quality of the user experience, while others could result in regulatory investigations, financial loss, or significant reputational damage.

A useful way to think about severity is to evaluate the business consequences rather than focusing solely on the model’s technical behavior.

For example, an AI assistant that occasionally formats dates incorrectly may be considered a low-severity issue. Although inconvenient, the impact is unlikely to extend beyond minor user frustration. By comparison, an assistant that leaks confidential customer records, generates discriminatory hiring recommendations, or exposes privileged financial information represents a critical business risk that requires immediate remediation.

When assessing findings, consider questions such as:

• Could confidential information be exposed?
• Would customers receive unsafe or misleading advice?
• Does the issue violate regulatory or contractual obligations?
• Could the organization suffer financial loss?
• Would the organization’s reputation be affected if the behavior became public?
• Is the issue repeatable, or does it occur only under very specific circumstances?

Answering these questions helps organizations prioritize remediation efforts and communicate risks more effectively to business leaders who may not understand the underlying technical details.

AI Red Teaming is a Collaborative Exercise

One of the biggest mistakes organizations make is assuming AI red teaming belongs exclusively to security teams. Unlike infrastructure testing, evaluating AI systems requires expertise from multiple disciplines because AI affects far more than technology alone.

Security professionals bring experience in adversarial thinking and attack simulation. Data scientists understand how models are trained and where limitations may exist. Developers understand the surrounding application architecture. Compliance specialists ensure regulatory requirements are considered throughout testing. Legal teams provide guidance on privacy, intellectual property, and contractual obligations. Business owners contribute operational knowledge that helps identify realistic misuse scenarios.

Perhaps most importantly, end users should also be involved.

Employees frequently interact with AI in ways developers never anticipated. Observing how users naturally phrase questions often uncovers prompt sequences that no formal test plan would have included. Their curiosity, assumptions, and everyday workflows provide valuable insight into how AI will behave once deployed across the organization.

Successful AI red teaming is therefore not a one-time security exercise carried out by a small specialist team. It is a collaborative process that combines technical expertise, business knowledge, governance, and real-world user behavior to build confidence that AI systems remain safe, reliable, and aligned with organizational objectives.

AI coding assistants have evolved from simple autocomplete tools into capable development agents that can write code, debug applications, refactor projects, and even execute complex workflows.

Among the newest generation of tools, OpenAI's Codex and Anthropic's Claude Code have emerged as two of the strongest options for developers.

Both platforms promise to improve productivity, reduce repetitive work, and help teams ship software faster. But they approach software development differently.

Choosing between them depends less on finding a universal winner and more on understanding which tool aligns with your workflow, team structure, and development goals.

What We'll Cover Here:

• Understanding Codex

• Understanding Claude Code

• Codex vs Claude Code: Direct Comparison

  • The Difference in Philosophy

  • Code Quality and Reasoning

  • Workflow Integration

  • Deployment Options

  • Productivity Considerations

  • Security and Oversight

• Should you choose Codex or Claude Code?

• Final Thoughts

Understanding Codex

Codex is OpenAI's dedicated coding agent designed to assist developers throughout the software development lifecycle.

Unlike earlier code generation tools that focused mainly on snippets and autocomplete, modern Codex operates more like an autonomous development partner.

It can understand large codebases, generate new features, fix bugs, review existing implementations, and work on multiple tasks simultaneously.

OpenAI has expanded Codex beyond a simple command-line experience, introducing desktop and cloud-based environments that allow developers to delegate work while continuing with other responsibilities.

According to OpenAI, Codex can read, edit, and run code while operating in its own environment to complete assigned tasks. This makes it particularly useful for teams that want an AI assistant capable of handling longer-running assignments independently.

Understanding Claude Code

Claude Code takes a different approach. Rather than emphasising autonomous execution, Anthropic has focused heavily on developer collaboration and reasoning quality.

Claude Code functions as a terminal-native assistant that integrates directly into existing workflows. Developers can interact with it conversationally while maintaining close oversight of the coding process.

The tool is particularly strong at explaining architectural decisions, reviewing unfamiliar codebases, and helping developers work through complex implementation challenges. Instead of simply generating solutions, Claude Code often provides context that helps engineers understand why a particular approach may be preferable.

This makes Claude Code attractive for developers who view AI as an intelligent collaborator rather than an independent coding agent.

Codex vs Claude Code: Direct Comparison

The Difference in Philosophy

The biggest distinction between Codex and Claude Code lies in their approaches to autonomy.

Codex is designed to execute delegated work efficiently. Developers describe objectives, and the system attempts to complete them with minimal intervention. It excels in situations where productivity and task completion are the primary objectives.

Claude Code, on the other hand, prioritises interaction. It keeps developers closely involved in the decision-making process and often produces explanations alongside implementation suggestions.

Neither philosophy is inherently better.

Teams building products under tight deadlines may benefit from Codex's autonomous capabilities. Developers working on complex systems that require thoughtful design discussions may prefer Claude Code's collaborative style.

Code Quality and Reasoning

When evaluating coding assistants, raw output quality matters.

Claude Code has earned a reputation for producing clean, maintainable code with strong architectural awareness. It often breaks larger problems into logical components and provides reasoning that helps developers understand the trade-offs involved.

Codex tends to optimise for execution and efficiency. Its outputs frequently focus on accomplishing the requested task with minimal overhead while maintaining practical production considerations.

Comparative testing has shown that Claude Code often excels in documentation tasks and feature design. Codex demonstrates strong consistency across multiple categories of development work. Research analysing thousands of pull requests found that no single agent dominated every software engineering task, reinforcing the idea that context matters when selecting a tool.

Workflow Integration

The way an AI coding assistant fits into your existing development process can significantly impact adoption and long-term value.

Claude Code is built around a terminal-first experience, allowing developers to interact with the model directly within familiar command-line environments. This makes it particularly appealing to engineers who prefer maintaining close control over implementation decisions while receiving real-time guidance and feedback.

Codex takes a different approach by emphasising automation and delegation. Developers can assign coding tasks and review the completed work later, making it well-suited for teams looking to reduce repetitive workloads and improve development velocity. This model can be especially useful in larger organisations where engineers frequently juggle multiple projects and priorities.

Ultimately, the right choice depends on how your team prefers to work. Developers seeking an interactive coding companion may gravitate toward Claude Code, while organisations focused on streamlining execution may find Codex a better fit within their existing workflows.

Deployment Options

Writing code is only part of the software development process. Once an application is complete, developers still need a reliable way to test, deploy, and maintain it in production.

Whether you use Codex or Claude Code, the deployment workflow remains largely the same. AI coding assistants can generate production-ready applications, but they don't replace the infrastructure needed to host them.

Developers still need platforms like Vercel, Hostinger and Railway that support automated deployments, scalable environments, SSL certificates, backups, monitoring, and straightforward rollback options.

For teams looking to deploy apps built with Claude, platforms like AWS and Vercel make it easier. They integrate continuous delivery pipelines while providing the reliability expected from production systems.

The same applies when you try to deploy apps built with Codex. Services such as Hostinger simplify deployments with managed Node.js hosting, Git integration, and built-in security features, allowing developers to move from AI-generated code to a live production environment with minimal configuration.

As AI coding assistants become part of everyday development workflows, selecting the right production hosting for AI coding assistants is becoming just as important as choosing the coding tool itself. The best workflow combines an intelligent development assistant with infrastructure that makes shipping software fast, reliable, and repeatable.

Productivity Considerations

One of the primary reasons organisations adopt AI coding assistants is to improve development velocity.

Codex often shines when repetitive or well-defined tasks dominate the workload. Generating boilerplate code, implementing straightforward features, writing tests, or executing multi-step workflows are scenarios where autonomy can deliver meaningful time savings.

Claude Code provides value during exploratory development. Developers can brainstorm implementation approaches, validate assumptions, and receive guidance while preserving human oversight.

The productivity gains from each tool depend heavily on how teams allocate engineering effort.

Organisations emphasising rapid delivery may prioritise Codex.

Teams prioritising knowledge sharing and architectural consistency may lean toward Claude Code.

Security and Oversight

As AI agents gain more capabilities, governance becomes increasingly important.

Claude Code's interactive design naturally encourages human review before significant actions occur. This reduces the likelihood of unintended modifications and reinforces developer accountability.

Codex introduces stronger automation capabilities, which can accelerate workflows but also require clearly defined operational safeguards. Organisations adopting autonomous coding agents should establish review processes, permission controls, and testing requirements before integrating them into production environments.

The goal is not to eliminate human involvement but to position AI appropriately within existing software development practices.

Should you Choose Codex or Claude Code?

The answer depends on how you work.

Choose Codex if your team values autonomy, wants to delegate substantial development tasks, and needs an assistant that can operate independently across multiple assignments. Organisations focused on maximising throughput may find this approach particularly compelling.

Choose Claude Code if you prefer collaborative problem-solving, appreciate detailed reasoning, and want AI assistance that remains closely integrated with human decision-making throughout the development process.

Neither assistant replaces engineering judgment. Instead, they amplify different aspects of software development.

Final Thoughts

The debate between Codex and Claude Code reflects a broader shift within software engineering. AI assistants are no longer limited to suggesting individual lines of code. They're evolving into sophisticated development partners capable of influencing planning, implementation, testing, and deployment.

Codex emphasises execution. Claude Code emphasises collaboration.

For some teams, Codex will unlock significant productivity gains by handling routine work autonomously. For others, Claude Code will enhance decision-making by serving as an intelligent coding companion.

Ultimately, the best choice is the one that complements your team's existing strengths and addresses its most significant bottlenecks.

As AI continues to reshape development practices, the organisations that succeed will not necessarily be those using the most advanced tools. They will be the ones who integrate those tools thoughtfully into well-defined engineering processes.

Hope you enjoyed this article. You can connect with me on LinkedIn.

Today we released the 16.2.0 version of AutoMapper and 14.2.0 version of MediatR:

• AutoMapper Release Notes
• MediatR Release Notes

This release is a bit more enterprise-focused, with extensions for setting the license keys via environment variables, fixing some threading issues around license key validation, and including more security-related items on releases (SBOMs, etc.)

These last few releases have been targeting items more or less required for enterprises consuming commercial packages. In the next release, we'll be more focused on adding features and fixing historical bugs.

• AutoMapper NuGet
• MediatR NuGet

Enjoy!

When you add approval stages to increase stability, the last thing you expect is instability. That’s the opposite of what you wanted. Yet that’s what happens when organizations respond to incidents by increasing the weight of change approval processes.

That means there’s more art to change approvals than most people realize, and it’s a threat to an organization’s ability to deploy and operate software if they don’t have change finesse.

Watch the episode

You can watch the episode below, or read on to find some of the key discussion points.

Watch Continuous Delivery Office Hours Ep.6

Organizational trauma

Change approvals don’t arrive without reason. If you have a heavyweight change approval process and frequent or extended change freezes, the chances are that they were introduced after a major incident. If you break financial software around tax year-end, banning deployments for a month before and a month after is, in theory, a reasonable resolution.

Almost every industry has a cadence it wants to protect from instability. Retail has seasonal sales events, the music industry has superstar ticket launches, and finance has a peak as the end of the tax year approaches. The goal is to make sure you can operate your business during these times.

With that goal in mind, we have to bust the myth of change approvals as the mechanism to achieve it. Attempting to protect these key moments with change freezes or cumbersome approval processes has one result: increased instability.

Heavyweight change approvals

Heavyweight change approvals make things less stable by delaying work and causing batches of unreleased changes to accumulate. Meanwhile, developers are starting new work and are losing the immediate familiarity with the oldest changes as they press ahead. One of the ways approvals gain weight is through approval chains, which we looked at in depth in the Compliance through Continuous Delivery report.

Large batches also come with admin that can introduce further problems. Testing becomes more difficult, the likelihood of merge issues increases, and pinpointing the source of a problem is far harder.

This is why the DORA research placed streamlined change approvals in their core model for software delivery. Centralized change approval boards don’t work, and process is never the solution to your stability problems.

Streamlining

There are some easy ways to streamline change approvals. Most of these don’t look like traditional change management, which is good because we know that doesn’t work.

The first way to trim the process is to automate your verification stages. At every level of review, tasks can be automated, whether it’s automatically linting and formatting code (instead of debating it), running automated builds and tests, or validating your SBOM is free from insecure dependencies.

Where you need a human review, use a peer-review process for individual changes, enforced on commit, with humans brought in only after the automated validation has passed. If you have advanced change approval needs, categorizing changes by risk lets you apply your people to the changes that most need their perspective.

You won’t achieve all of this in one day. It’s part of your continuous improvement process. You may improve your chances of stripping the bureaucracy if you follow the capability culture cycle pattern.

Small batches, again

If you follow industry experts or the research, you’ll notice that small batches keep cropping up as the answer to many kinds of dysfunction. That’s not a coincidence. Large batches cause far-reaching problems that build superlinearly as more changes collect unreleased.

Anything that causes batch size to increase, including change approvals, must be subject to fierce improvement.

Happy deployments!

The talks are set for Pure Virtual C++ 2026, our free, one-day virtual conference for the whole C++ community. We’re excited to reveal the featured session lineup and the speakers bringing it to you.

Mark your calendar: Tuesday, July 21, 2026, starting at 16:00 UTC (9:00 AM in Seattle, 6:00 PM in Brussels, 11:00 PM in Bangkok). The conference is completely free and streamed online, so you can join from anywhere in the world.

Featured Talks

Here are the featured sessions you’ll see at Pure Virtual C++ 2026:

• C++ Semantic Awareness in the CLI: From Project Load to Code Change with Sinem Akinci
• C++/WinRT: Build Faster and Smaller with C++20 Modules with Ryan Shepherd
• Mind the Gap: C++/Rust Interop with Victor Ciura
• From Completions to Agents: AI-Driven C++ in Visual Studio with Augustin Popa
• Cut Your Build Times Without Becoming a Build Expert with David Li

More details about each featured session are coming soon in follow-up posts. We also have more surprises in the build-up to the conference, including additional on-demand content on topics like managing C++ dependencies, the status of C++23 and C++26 features in MSVC, and how to get the best out of the latest MSVC features like Sample Profile-Guided Optimizations.

Can’t make it live? All sessions will be available on-demand on the Visual Studio YouTube channel after the event.

What’s Next

Register now and join your two hosts for this year’s event, Mads Kristensen and Sinem Akinci:

• Mads Kristensen is a Principal Product Manager on the Visual Studio team at Microsoft, focused on making developers more productive by improving the IDE’s performance, usability, and extensibility. He’s also a prolific open‑source contributor, known for creating popular Visual Studio extensions and tools that help both users and extension authors get more done. A frequent conference speaker, he shares practical insights with a simple goal: to make Visual Studio a fast, powerful, and enjoyable place to code.
• Sinem Akinci graduated from the University of Michigan, where she studied Industrial Engineering and Computer Science. Since then, she has worked across a range of domains, including engineering and consulting, and is now a Senior Product Manager at Microsoft focused on C++ developer tooling and AI-assisted workflows across Visual Studio, VS Code, and the CLI.

Hope to see you there!

 

The post Pure Virtual C++ 2026 Talks Announced appeared first on C++ Team Blog.