I work in ML. The ImageNet analogy is doing a lot of heavy lifting here and it does not hold up.

ImageNet worked because image classification has a ground truth. A picture of a cat is a cat. You can label 14 million images and have humans agree on what they depict. The labels are objective.

Code quality is not objective. "Modern, idiomatic C++" is a moving target that the committee itself disagrees about. Is std::optional<T&> idiomatic? Depends on which mailing you read. Is structured bindings in a range-for idiomatic? Depends on who you ask. Is co_await on a sender idiomatic? P2300 hasn't shipped outside NVIDIA's stack.

ImageNet didn't need to resolve philosophical debates about what a cat is. A curated C++ dataset would need to resolve philosophical debates about what good code is - and those debates are literally what the committee does for a living, slowly, and without consensus half the time.

The paper proposes domain tags (ai/, embedded/, finance/) as if that's sufficient quality control. It is not. You need pedagogical scaffolding - progressive complexity, explicit rationale for each design choice, anti-pattern comparisons. A flat corpus of "good" examples is how we got the current mess of stackoverflow-trained models in the first place.

The goal is right. The analogy undersells the difficulty by a factor of ten.

can we please just get networking in the standard before we start governing AI. priorities, people.

Read the whole thing. Thrust I is 90% restating what ISO/IEC JTC1 SC22 N5991 already says. The "author is the intelligence of record" principle, the prohibition on AI-generated normative text, the copyright concerns - that document covers all of it.

What P4023 adds is (a) making it explicit for WG21 context, (b) the "no bots in meetings" rule, and (c) the direct acknowledgment that AI slop is already happening. Point (c) is the interesting one. The DG is putting it on paper that they've seen low-quality AI-generated submissions. That's a political statement as much as a policy one.

Thrust II is where the new content is, and also where the paper is weakest. More below.

From the paper:

Library designers are encouraged to create APIs that are human consumable because it also helps agents to consume. Make intent evident, reducing the context required for an AI agent to use them correctly.

This is exactly backwards. APIs that are easy for humans and APIs that are easy for machines are not the same thing. Human-friendly APIs use overloading, implicit conversions, ADL, and contextual defaults. Machine-friendly APIs use explicit types, no overloading, flat namespaces, and named parameters.

Consider:

// human-friendly (overloaded, contextual)
auto result = connect(host, port);
auto result = connect(endpoint);
auto result = connect(uri, opts);

// machine-friendly (explicit, discoverable)
auto result = tcp_connect_to_host_port(host, port);
auto result = tcp_connect_to_endpoint(endpoint);
auto result = tcp_connect_to_uri(uri, opts);

An LLM doesn't know which connect overload to call without reading the header. A human knows from context. These are different design pressures. The paper glosses over this entirely.

so to summarize: C++ is so complex that even AI can't write it correctly, and the solution is... more papers

meanwhile in Rust, the compiler just tells you what's wrong. no curated training dataset needed. the type system is the training data.

The paper lists domain tags: ai/, embedded/, finance/. As someone who has written embedded C++ for two decades: 99% of C++ training data online is web examples with std::cout and heap allocation. My production code has zero dynamic allocations, no exceptions, no RTTI, and compiles for a Cortex-M4 with 256K flash.

A "curated dataset" that includes an embedded/ tag is meaningless unless someone decides which embedded style. MISRA C++? AUTOSAR? Bare-metal RTOS? Safety-critical avionics? These are different worlds with different rules. The paper treats "embedded" as one thing. It is not.

I want this dataset to exist. I do not believe a volunteer effort can produce it. This needs institutional backing and money.

The dependency nobody is talking about: you cannot curate "safe modern C++" training data until you define what safe C++ is.

The paper says "favoring spans over pointers" and "null ptr checks." But the safety profiles work (P3081) is still in flight. The boundary between "safe" and "unsafe" C++ is actively being debated in SG23. Training an AI on today's definition of "safe" means retraining when the profiles ship and the definition changes.

Three-point version of the problem:

1. P4023 says "train AI on safe patterns"
2. P3081/P2759/P3651 are still defining what "safe" means
3. The dataset can't be curated before the definition stabilizes

The DG is proposing a dataset that depends on committee output that doesn't exist yet. That's a sequencing error.

I work in HFT. We have been generating C++ with internal tooling for two years. Our training data is proprietary. Our patterns are proprietary. The code that matters - the code where nanoseconds count - will never appear in a public dataset because it's worth money.

A public curated corpus will produce AI that writes competent library code and terrible performance-critical code. Which is fine for 90% of use cases and useless for the 10% that pays my salary.

The paper doesn't grapple with this. The best C++ is behind NDAs.

I have used Claude and GPT to help draft committee papers. Not generate - help draft. Research summaries, consistency checks, finding prior art, rewriting unclear paragraphs. The quality after human review is indistinguishable from fully human-written papers. I know because reviewers have told me my recent work is "noticeably clearer."

The governance section is solving a problem that doesn't exist yet. The real problem is not "AI is writing bad papers." The real problem is "bad papers exist and now people can produce them faster." That's a quality bar issue, not an AI issue.

imagine being replaced by an AI that can't even get std::variant visitor syntax right

The paper lists "Sender/Receiver over Callbacks" as a training data preference. Let's check the receipts.

P2300 (std::execution) was voted into C++26 but has zero production deployments outside of NVIDIA's stdexec. The API surface is complex enough that even experienced async developers need days to internalize the model. The reference implementation is a research artifact, not a production library.

We are asking AI to learn patterns that humans haven't adopted yet. The corpus would contain sender/receiver examples that approximately nobody has written in production. How is that "curated, human-validated" data? It's aspirational data. We're training the AI on what we wish people wrote, not what they actually write.

I teach C++ to undergrads. The biggest AI problem isn't training data - it's that students submit AI-generated code they don't understand. It compiles. It passes the basic tests. And it has three undefined behaviors that only show up under ASan.

Last semester I got a submission that used reinterpret_cast<int*>(&float_val) to "convert" a float to int. The student couldn't explain why it worked on their machine. The AI gave them code that looked correct, compiled without warnings, and violated strict aliasing. No amount of curated training data fixes this - the AI doesn't understand UB any more than the student does.

The paper's heart is in the right place. But the crisis in my classroom isn't "AI generates C++98." It's "AI generates plausible-looking C++20 that's subtly broken in ways that require deep understanding to detect."

From the tooling section:

Make compilers answer questions about argument types and modern usage possibly connecting to MCP

MCP is a specific protocol from Anthropic that has existed for about a year. It might not exist in three years. Why is a directions paper - a document meant to set strategy for the next decade - name-dropping a specific vendor protocol? This is like a 2015 directions paper saying "possibly connecting to Google+."

The underlying idea - structured compiler queries for AI agents - is sound. But pin it to the concept, not the implementation. LSP took a decade to get where it is. MCP might be a footnote by C++29.

Half the papers in the last mailing read like ChatGPT wrote them. The DG knows this. That's why Thrust I exists. This isn't preemptive governance - it's reactive damage control dressed up as strategy.

Thrust II is basically asking for Boost 2.0 but for training data. The paper name-drops the Beman Project as a potential home for this kind of initiative, but Beman is already stretched thin incubating actual libraries for standardization. Adding "curate a massive cross-domain C++ corpus" to their scope without additional resources is wishful thinking.

The paper says "WG21 cannot solve this alone" but never identifies who can. Boost doesn't have the infrastructure for dataset curation. Beman doesn't have the funding. Academic groups could contribute but need grants. The only orgs with both the data and the money are the compiler vendors (Google, Microsoft, Apple, NVIDIA), and the paper doesn't ask them to do anything specific.

I want to see this happen. I don't see a mechanism for it to happen.

the paper says "Algorithms over Loops: Biasing generation toward <algorithm>." my brother in Christ, #include <algorithm> adds 2 seconds to my compile time

Honest question: if we had this magical curated modern C++ dataset, who decides what's "modern" and "idiomatic"? The committee that took 3 years to agree on a range adaptor closure semantics? The same body where SF/SA votes split 12-11?

Edit: I'm told the range adaptor thing was actually resolved fairly quickly. The point stands for basically everything else.

the fact that Bjarne Stroustrup co-authored a paper about AI governance for C++ is peak 2026

Read the whole thing twice. The real gap nobody is talking about:

Section 3 says:

the C++ ecosystem needs a curated, human validated collection of modern examples of high-quality dataset of Modern, Idiomatic C++

Section 5 says:

Make compilers answer questions about argument types and modern usage possibly connecting to MCP

These are two completely different strategies. One crowdsources quality through human curation. The other automates discovery through compiler tooling. The paper never reconciles them. Are we training AI on curated examples, or are we giving AI tools to query the compiler directly? Because those two approaches have fundamentally different failure modes, resource requirements, and timelines.

A paper that's setting "strategic direction" should at least acknowledge when its two thrusts point in different directions.

Edit: to be fair, maybe the answer is "both." But the paper doesn't say "both" - it just presents them adjacently without connecting the dots.

tl;dr: AI is both the future and the problem and the solution and we need a dataset and also governance and also tooling and also the ecosystem should do something and also we can't do it ourselves. got it.

disclosure: this comment was written by Claude