Deep Engineering #44: Sándor Dargó on C++26, Adoption Traps, Compiler Gap, and Maintainability
On C++26 adoption decisions, the fallback plan most teams skip, what the compiler gap costs in practice, and keeping large C++ systems maintainable
Building an AI-Powered Internal Developer Platform from Scratch
Hone your skills to design, implement, and ship an AI-powered internal developer platform from scratch with Ajay Chankramath.
📅 25th and 26th April 2026 | 11:00 AM to 3:00 PM ET
Use code DEEPENG50 for 50% off, or grab the 2-for-1 deal
Includes access to The Platform Engineer’s Handbook by Ajay Chankramath upon release (eBook worth $35.99)
✍️ From the editor’s desk,
Welcome to the 44th issue of Deep Engineering!
C++ just had its most consequential standard in years finalized. Contracts and static reflection are expected after a decade of committee work, and the async execution model is in. This has the conference circuit energised, blog posts are multiplying, and most production teams are continuing to ship C++17 or C++20 while they wait for compiler support to catch up and patterns to settle.
The ISO C++ Foundation also opened its 2026 annual developer survey this week, the single biggest opportunity the global C++ community gets each year to tell the standards committee and tooling vendors what actually matters in practice. If you write C++ at any scale it is worth ten minutes of your time before it closes next week.
This week we are featuring Sándor Dargó, senior software engineer at Spotify, on what responsible C++26 adoption decisions should look like in production, what most teams get wrong, why fallback plans need to be on every adoption checklist, and what the gap between a finalized standard and a production system actually costs. The feature is based on our live interview with him and you can watch or read the full Q&A here.
Dargó also spoke at length in that session about clean code, cognitive load, and what it actually costs teams to optimize for the wrong things. We have collated those insights alongside our previous conversation with Sam Morley, mathematician and C++ researcher at the University of Oxford, into this separate piece “Clean Code Is a Trap, Decompose Instead for Physics and Performance” published this week.
Let’s get started.
View the latest HubSpot Developer Platform updates in Spring Spotlight
See what’s new for the HubSpot Developer Platform!
Ship faster with AI coding tools like Cursor, Claude Code, and Codex. Build MCP-powered AI connectors, run serverless functions with support for UI extensions, and use date-based versioning to streamline roadmap planning.
Check → HubSpot Developer Platform
Most C++ Teams Get Feature Adoption Wrong, and What the Pragmatic Ones Do Differently
by Saqib Jan with Sándor Dargó
C++26 is heading to its final approval ballot. Contracts and static reflection are expected. The feature set is the largest the language has seen in years, and the C++ community is already deep into discussing what it means. And yet, while they wait for compiler support to catch up and patterns to settle, engineering teams are starting to ask how to prepare for when they can actually ship it.
That gap between what the standard says and what teams can actually ship is not a failure of ambition, but the normal condition of C++ in production. It has looked roughly the same across every major standard transition for the past fifteen years. “The engineering teams that navigate it well have learned to keep understanding and adoption on separate timelines,” says Sándor Dargó, senior software engineer at Spotify. “It serves well to invest deeply in knowing a feature years before you need to ship it, because conflating the two is where most adoption mistakes gain foothold.”
Dargó has a different set of questions he likes to ask first. His framework is intentional and straightforward. The feature set is not the starting point. What matters is whether the team can live with the code a year from now, when the engineer who introduced it has moved on and compiler support is still uneven across platforms. Proven and maintainable is not playing it safe. It is what keeps production systems running while the language moves underneath them.
At Spotify, where he works on large-scale C++ systems with a hard requirement that the code stays clean, maintainable, and operable over time. He has observed teams navigate standard transitions from C++11 through C++23, and the pattern he sees repeat is always the same one. “Teams focus on what the standard says, and they underestimate the distance between the standard and the compiler, between the compiler and the toolchain, and between the toolchain and the production system that has to run reliably when all of this settles,” he said. “Everyone is talking about contracts and reflection. That’s going to change everything. I’m not sure about the time scale though. If you look at C++23 support right now, even that is not complete yet, especially if you look at the differences across compilers. You go on cppreference, check what’s implemented on which compiler, and we are simply not there yet.”
That observation shapes everything that follows in Dargó’s approach to feature adoption, and it is worth understanding precisely what he means by it.
The gap between the standard and the production system
The C++ standard finalizes on a schedule. Compiler vendors implement on a different one, and they do not always agree on approach, especially for genuinely new features that require significant infrastructure rather than incremental additions. Small library extensions arrive with almost no implementation lag because compilers already have the machinery to support them. But contracts and reflection are not small library extensions. Both require compilers to build something they have never built before, and different vendors will make different choices along the way, as they did with modules in C++20.
Dargó cited modules in our live interview as the clearest recent example of how this plays out in practice. Vendors diverged, build system integration took years to stabilize, and teams that moved early discovered that the standard’s guarantees did not insulate them from the fragmentation that came from uneven implementation across compilers. “There might be a bigger gap, just like we saw with C++20 modules. I hope it won’t be that problematic. But I don’t think I’ll be able to use those in a production environment in the next one or two years.” Dargó, drawing on his years of engineering experience leading high-velocity teams at Spotify, a company with engineering resources that most teams do not have. If Dargó is not planning to ship contracts or reflection to production in the next two years, the average multi-platform C++ team operating with a mixed compiler pipeline and a long-lived codebase should be thinking in similar terms.
This does not mean the features are not worth understanding. It means the time horizon for understanding and the time horizon for shipping are different, and most adoption conversations conflate the two.
Cautious is not the same as resistant
Dargó’s posture toward new features is not skepticism. It is a more specific kind of discipline that he applies before any adoption decision, and it comes down to two distinct questions that most teams skip. The first is whether the usage pattern is proven in a production environment with real operational constraints, not in a blog post or a conference demo. The second is whether the feature actually solves a problem in the specific codebase, rather than just offering a more modern way to write something that was already working. “If they only bring a different syntax, that’s not really good. If they actually solve a problem in your codebase, in your use case, then it’s good. And let’s discuss why and how that’s the right solution.”
The distinction between a genuinely useful adoption and a syntactic upgrade matters more than most teams want to admit, because every feature adoption comes with a cost that does not appear in the initial pull request. The team has to understand the feature well enough to review code that uses it, to debug it when it breaks, and to maintain it when the engineer who introduced it has moved to a different team. “You cannot just push the new way of coding. You should share the knowledge and discuss what these new features actually bring. Deep down, everyone wants to learn about these things, and we all want to start using them as soon as possible.” Dargó acknowledges that impulse is not wrong. But the enthusiasm of the early adopter on the team and the readiness of the rest of the team to live with the decision are two different things, and adoption decisions that ignore the second tend to create the kind of complexity that shows up as maintenance debt two years later.
No one puts the fallback plan on the checklist
The most operationally concrete principle Dargó applies to feature adoption is also the one that almost no team’s adoption checklist includes. Before shipping code that uses a new compiler feature, make sure you can roll back the compiler version without having to change the code. This constraint is not about being conservative for the sake of it. It is about what happens when a compiler update introduces a regression or a new feature behaves differently than expected on a specific platform, and the fastest path to stability is to revert the compiler version rather than to fix the code.
Dargó walked through the alternative. “Move to a new version, start using concepts from C++20, and then in two weeks they say there’s a problem, we must go back. And then you realize it’s not just updating the compiler version, you actually have to change the code.” At that point the team is no longer choosing between a rollback and a fix. They are choosing between a broken build and a risky code change under pressure, and neither is a good position to be making decisions from. The fallback plan requirement changes how the team thinks about adoption from the start because it sets a concrete constraint on which features can be used and how deeply they can be integrated before the team has sufficient confidence in the compiler support. For single-platform, single-compiler environments, that constraint is loose. For multi-platform pipelines with mixed compiler versions, it is the gate that determines what gets shipped and what gets saved for a later standard cycle.
Making trade-offs explicit before someone else makes them implicit
The broader philosophy Dargó brings to C++ at scale is that complexity is always the enemy, and the job of a senior engineer is to reduce it through the daily decisions that accumulate into the character of a codebase over time. Clean code reduces cognitive load. Smaller binaries reduce operational cost. Eliminating undefined behavior reduces hidden risk. New language standards reduce boilerplate and enable safer abstractions. And all of these things connect, in Dargó’s framing, to the same underlying goal: making large C++ systems more maintainable and more evolvable over the years that teams and requirements will inevitably change.
But maintainability does not happen by default. It requires making trade-offs explicit at the moment they are made, in the code itself, not just in the code review thread that will be forgotten. Dargó has been on the receiving end of what happens when this does not happen. He came into a codebase, saw code that looked wrong, began cleaning it up, and realized too late that the seemingly redundant choice was affecting binary size in a way that mattered operationally. Some pull requests had already merged before the context became clear. “Trade-offs there will be. But make them conscious and share the knowledge.” That principle applies to binary size decisions and it applies equally to feature adoption decisions. The team that adopts contracts without documenting why, which problem it was solving, what compiler version it was verified on, and what the fallback plan is, has introduced complexity that is invisible until the moment it becomes a production incident.
What C++26 actually changes and when it matters
Contracts and reflection are genuinely significant features. Contracts bring the language its first formal precondition and postcondition system, giving teams a way to enforce interface discipline through the language rather than through documentation and convention. Static reflection enables code generation, serialization frameworks, and tooling that the language simply could not support before in any ergonomic way. Both of these things will change how C++ gets written over the next decade, and engineers who understand them deeply before the production window opens will be in a stronger position than those who try to learn them under delivery pressure.
But a decade is closer to the right time scale for thinking about the full impact than a release cycle is. The standard has finalized, but the compilers have not caught up. And the community has not yet established the patterns worth following or the misuse patterns worth avoiding. For engineering leaders building roadmaps, Dargó’s framework points toward a clear separation between understanding and shipping. Invest in understanding contracts and reflection now, run experiments on non-production code, track compiler support as it lands, and build team knowledge before the toolchain is ready. Then, when the support is solid, the patterns are clear, and the fallback plan can be written, adoption becomes a technical decision rather than a leap of faith.
Dargó likes to put it in simple words. “Being among the first adopters is sometimes good. Sometimes it’s better to be in the second line.” For most production C++ systems with multi-platform requirements, long-lived codebases, and teams where knowledge has to be shared rather than siloed, the second line is where proven and maintainable gets built. The first line is where the lessons come from that make the second line possible.
🔍 In case you missed it…
Clean C++ Code, and the Hidden Cost of Complexity with Sándor Dargó
Sándor Dargó has spent years making large C++ systems easier to maintain, safer to change, and cheaper to run.
Clean Code Is a Trap, Decompose Instead for Physics and Performance
Engineering teams obsess over clean code because they want software to look organized and logical in the text editor.
🛠️ Tool of the Week
vcpkg — open-source C and C++ package manager
vcpkg removes the dependency management friction that makes compiler and toolchain transitions harder than they need to be, letting teams verify library support across targets without manually managing platform-specific build configurations.
Parallel file installation for faster builds
2,773 ports in the curated registry, each validated across all major triplets
Dependabot support for automated dependency vulnerability tracking
OpenSSL packaging security fix on Windows
📎 Tech Briefs
Spotify publishes how it used Honk, Backstage, and Fleet Management to migrate thousands of datasets - Details how background coding agents reduced the manual overhead of large cross-repository migrations at scale.
GitHub ships C++ Language Server for Copilot CLI in public preview - Extends semantic C++ code intelligence to the command line, giving Copilot symbol definitions, call hierarchies, and type data beyond what grep returns.
Clang/LLVM 22.1.4 released - Patch release of Clang 22, the compiler with the most active C++26 feature tracking. Teams on Clang should update.
MSVC Build Tools 14.51 release candidate ships in Visual Studio 2026 Insiders - Adds expanded C++23 conformance, CWG and LWG issue resolutions, and runtime performance improvements. Stable release expected in May.
cppreference.com returning to read-write after ISO C++ Foundation takes over infrastructure - Herb Sutter announced the Foundation is taking over hosting and maintenance for cppreference, the primary compiler support reference for the C++ community.
That’s all for today. Thank you for reading this issue of Deep Engineering.
We’ll be back next week with more expert-led content.
Stay awesome,
Saqib Jan
Editor-in-Chief, Deep Engineering
If your company is interested in reaching an audience of senior developers, software engineers, and technical decision-makers, you may want to advertise with us.
Thanks for reading Packt Deep Engineering! Subscribe for free to receive new posts and help grow our work.
C++ committees are the ultimate design-by-committee coordination problem - ten years to ship reflection means the cost of consensus exceeded the cost of just writing the code.