ACCU on Sea 2026 - The Future of C++

There was a lot of forward thinking at this conference, and not just the typical “What is coming in the next standard(s)?” kind of forward thinking. This was more along the lines of what will our industry look like in the near future.

The next 20 weeks of systems engineering

This was the opening keynote from Andrei Alexandrescu. Exceptionally funny and filled with interesting materials like any Andrei talk. He acknowledged that we are in a MASSIVE transition period for our industry as a result of AI/LLMs. This entire talk was trying to predict the future based on past and current experiences. He ended with 7 predictions:

1. AI will define and use its own abstractions -> Currently LLMs are very good at using abstractions it has learned from its training data. BUT it is pretty useless at creating its own abstractions. Andrei feels like this will change sooner rather than later. I’d believe this considering how insane the improvements have been since around December 2025.
2. Software projects will increase in size -> This is kinda an obvious, but probably still worth stating. I think Andrei means that they will increase in size in a substantial way. Not just iteratively.
3. “As-if” rule on steroids coming to compilers -> Andrei feels like compilers will start incorporating LLMs for optimizations. I am a little iffy on this one. This might happen but perhaps not in the way that it sounds from this point. To me this reads like “Compilers will start to introduce optimization passes that are executed by an LLM” which I don’t think will happen… From what I learned from compiler writers at the Shading Languages Symposium if a compiler is not deterministic, it ain’t much of a compiler. LLMs are by their very nature, non-deterministic. I feel like people wouldn’t appreciate it if it was possible for their program to not be byte-for-byte identical on every compile of the same source code. However, I feel like maybe Andrei was hinting at a more subtle use of LLMs in the compiler stack here. I will need to re-watch this talk when it comes out on YouTube.
4. Compilers will be architected for dialogue with agents -> This is something I can see happening. Getting an LLM to describe the code that it compiled. Or describing error messages to make it easier for people to understand what went wrong. Compiler Explorer already has this feature with Claude Explain. The assembly from this godbolt from my Pointer Parameter Problem blog generates the following explanation from this feature:

It even tells me how many tokens this took to generate, and the cost to the compiler explorer team. Neat!

5. Prompt engineering has no future -> With the rise of Meta-Cognition (The ability for LLMs to think and refine ideas by arguing with itself essentially), there is no real need to pay people to craft prompts. LLMs are the best at writing their own prompts. This makes a lot of sense to me. From my playing with Copilot CLI, I have never written my own skill. I am always prompting whatever model I am using to generate skills from my own prompt. Then I will get copilot to update skills based on the learnings that it has had in a particular session.
6. There might be a revival of specification languages -> It was pointed out that the language that we all use to interact with LLMs is markdown. Everything is written in English in markdown files. We might get more efficient token usage if we were able to write in a more terse and expressive language than English. I can see this happening.
7. We are in the “bubble sort” era of ai-assisted coding -> At the minute we are very inefficient with our use of AI. Just like bubble sort is very inefficient. But soon we will start discovering faster and more efficient uses of AI. Yeah this is a given. The progress this year alone has been insane. I have no idea what will happen on this front in the next couple of years.

There were 2 other pretty interesting thoughts that Andrei explored during this talk:

1. Andrei believes that we will stop seeing new production ready programming languages soon. Obviously people will keep creating them as a hobby. But new programming languages that enterprise applications will actually deploy will stop being a common thing. New programming languages were often created in the past to fill some niche or some specific goal. However, if we have general languages like C++ already and we have AIs to wield them, there ain’t much point in writing new languages outside of learning and hobby projects.

2. “Musk is wrong”. Elon predicted that AI will write machine code, bypassing higher level languages entirely. However, Andrei believes that this is quite silly, and so do I. The most important thing for great LLM usage is expressive abstractions. The more expressive an abstraction, the smaller the context window required, and the fewer tokens required for the LLM. Programming languages are great for this. Lower level languages are less efficient than higher level languages for this reason. Abstraction is important. This was also recently discussed on Episode 293 of ADSP.

Reflection

Reflection, reflection, reflection! The most exciting new thing in C++ since lambdas… probably even more exciting! I watched 2 talks on reflection:

1. CallMeMaybe: Building modern runtime reflection via C++26
2. Writing portable C++26 reflection

while many other talks at least referenced reflection in some way.

In my recent blog post C++26 - Enter Static Reflection, I had this note at the top of the post:

What was made quite clear from these talks is that there are no “cute idioms” using reflection yet. This is a whole new world and no one has any idea what the limits are yet. This is what makes everything so exciting about reflection. Anyone could discover anything.

An interesting thing to note is that the two talks I saw, talked about reflection in 2 very different ways:

1. CallMeMaybe -> Full of excitement and fun with all the cool stuff you can do with reflection
2. Writing Portable C++26 Reflection -> Full of caution about the whole new array of foot-guns that reflection makes available to the programmer, and how to avoid some of them.

Safety

Safety is a big challenge for C++. I spoke about this a bit in my BeCpp 2026 trip report. Now that reflection has been delivered, I feel like the next REAL step in the future of C++ is safety. Unfortunately, I did not go to any of the safety focussed talks…

… but there were quite a few talks on safety. One in particular that I missed was “The Future of C++ is Memory Safe” from Jon Bauman. The good news is that I sat beside him at the speaker’s dinner so I got to pick his brains a little on the topic. Jon feels that we need to have a strict, safe subset of the language where safety can be enforced by the compiler. This will be a talk that I will be looking out for on YouTube.