• Long-time C++ committee member
  • Contributed to wording or features in C++17, C++20, C++23, C++26 (almost certainly), and C++29 (likely)
  • std::mdspan, std::execution, std::atomic_ref, std::linalg, variadic operator[]
  • Former chair of Study Group 9 (Ranges)
• Former CppCon program chair (2022 and 2023)
• Former purveyor of Cute C++ Tricks

• Joined Anthropic in February 2025, currently working on Claude Code

• …convince you that AI coding agents are going to change the way software engineering works
• …convince you that vibe coding is the future of software engineering, or a good thing, or a bad thing, or sustainable.
• …tell you about how AI is going to replace you, or in general talk about the social impacts of AI
• …justify the environmental impact of AI

• I do want to help you thrive in a world where you have a limited ability to control the existence of AI

• Understand LLMs and coding agents at a high level
  • Especially the parts that are most relevant to understanding how to use them to write code
• Learn to think about coding agents as a tool
• Improve your mental model for how and why LLMs make mistakes
  • And learn how to anticipate and avoid these mistakes
• "Learn how to learn" to use coding agents more effectively
• Geek out about the future of C++ and where coding agents fit in that picture

• How do we make a chat bot out of this context window?
• It's shockingly primitive: just add special token sequences (e.g., \nHuman: and \nAssistant:) to separate prompt from response, and throw it all into the context window. Literally:

• This means that long conversations can use a lot of tokens very quickly!

• February 2019: GPT-2
  • 1.5B parameters
  • ~40GB of training data
• June 2020: GPT-3
  • 175B parameters
  • ~570GB of training data
• In a very vague sense, pre-training represents a "compression" of the training data
  • The surprising thing is that this appears to have some things in common with the "compression" of data that our brains use: conceptual generalization
  • This might be one reason that when we ask it to "decompress" the data, sometimes it displays emergent behaviors that are surprisingly human

• Consider the model completing this code snippet:

• Several completion candidates:

  widget foo nullptr

  std::move(widget) std::move(foo) make_unique<Widget>()

  ; 42 🌼

• How do we differentiate between these candidates?

• How do we differentiate between these candidates?
  • Probably ASCII
  • Look at the return type—it can't be an int or void
  • Returning foo would be a use-after-move
  • "Factory pattern" understanding means that nullptr seems pretty unlikely
  • Probably we wouldn't initialize something and then throw it away immediately
  • People usually name the variable to be returned by widget_factory() something like widget

• We probably have a full spectrum of "probability distributions" in this room between these two completions
  • Confession: my distribution probably looked something like
    • widget: 93%
    • std::move(widget): 7%

• Before looking this up, my distribution probably looked something like
  • 11: 33%
  • 14: 22%
  • 17: 40%
  • 20: 5%

• At some point we realized that XML, JSON, and other structured markup languages are "just" text
• So we started giving the LLMs a schema and a description of what will happen when it generates tokens matching that schema
• Then we implement code that takes XML/JSON/etc. as input and does some task:
  • Run a command in the terminal
  • Run the compiler, the debugger, or the profiler
  • Search the internet
  • Search the code in a repository
  • Edit a file

• Most LLMs (including Claude) use XML-based syntax for tool invocation (for now)
• Here's what an Edit tool call looks like in Claude Code:

• If the old_string is wrong, the tool call fails!
• If there are multiple old_strings in the file, the tool call fails!
• We are in the ed era of agentic tooling—we haven't even invented vi yet.

• Claude Code wrote the code block in the tool call in the last slide. Here's what the edit tool call looked like for that...

• GPT-1 (2018): 512 tokens
• GPT-4 (2023): 8K / 32K tokens
• GPT-4 Turbo (2024): 128K tokens
• Claude 3 (2024): 200K tokens
• Gemini 1.5 (2024): 1M+ tokens
• Claude 4 Sonnet (2025): 200K tokens

• We need a way to put more relevant information in the context window in order to make the output better
  • 2023: Retrieval Augmented Generation (RAG)
  • 2024: Tool use
• Wild idea: what if we just...ask the LLM to put more relevant tokens in its own context?

• Early LLMs could only do relatively short time-horizon tasks
  • Chatbots with short answers worked fine (kind of)
  • "Fancy" in-line code completion was another early application
  • With longer time-horizon tasks, early LLMs would quickly go "off the rails"
• As LLMs got larger and reinforcement learning got better, longer running tasks became more feasible
  • Key insight: Let the model see the results of its actions and iterate on that feedback
  • For instance, what if we:
    • Ask the model to generate code
    • Give the model a tool to run the compiler on the code it generated
    • Add the results of the compilation in the context window
    • Ask it to fix its compilation errors
• This feedback loop is what transforms a chatbot into an "agent"

• How do agents understand a 1M+ line codebase with only a few hundred thousand tokens of context?
• Maybe a better question: how do humans do this?
  • We search through the code for key entry points (e.g., main()),
  • …then we read code called by those entry points...
  • …and types and key data structures.
  • When we want to understand a specific piece of functionality, we search for key strings or patterns related to that functionality
  • In other words, we only "load" part of the code into our "context window"
  • And maybe we "load" as summary of the rest of the code (and how it works) into our "context window" if we've been working on the project for a while
• Agents can do this too!

• Anthropic monorepo: ~4M lines of code at the time
  • Mostly in languages I haven't used professionally in the past decade (Python, Rust, and TypeScript)
• My third day at Anthropic:
  • "Make <feature I've never heard of> faster using <tool I've never heard of>, or maybe <other tool I've never heard of>"
  • …oh, and this change will impact every production image build we do.
  • Colleague: "I'll give you a tour of the codebase tomorrow"
  • Me: "I wonder if Claude knows how to do this"
  • …three hours later: pull request is ready.
  • Colleague, next morning: "So I see you sent me a pull request before I even gave you a tour of the codebase..."

• They struggle with large scope tasks
  • Abstraction design
  • Code that's used in a lot of different scenarios
  • Libraries with a diverse set of stakeholders
• They tend to overperform on highly arcane or obscure tasks that are smaller in scope
  • Build systems
  • Template metaprorgramming
  • Compiler intrinsics

• Rapid prototyping
• "Side-quests"
  • Handwrite mission-critical code, dispatch agents for auxiliary code
• Planning and brainstorming
  • Helping with "writer's block"
• Learning and exploration
• Refactoring, boilerplate generation, modernization, cross-language translation
• Test generation

• If the LLM keeps "guessing" your library interface incorrectly, maybe it's too surprising (too "cute")
• If the LLM is "guessing" the effects of your function incorrectly, maybe it needs a better name
• Overthink the "principle of least astonishment"
  • When you write code that an agent might read, actively think through all of the ways your code could be misinterpreted
  • Be creative: what is the most "bland" way you can say the same thing?

• Avoid "clever" operator overloading
• Don't mix owning and non-owning semantics in the same type
• Avoid marcos
• Avoid argument-dependent lookup (ADL)
• Avoid implicit conversions
• Use regular types wherever possible

• Create, maintain, and document rigorous invariants at encapsulation boundaries
• The agent should be able to reason about the code in isolation as much as possible
• Avoid code coupling!
  • Err on the side of repeating yourself rather than breaking encapsulation by reusing code in vastly different scenarios
• See my CppCon 2023 talk "Expressing Sameness and Similarity in Modern C++":
  • Video: dsh.fyi/cppcon-2023-video
  • Slides: dsh.fyi/cppcon-2023

• Comments are more important for agents than they are for humans!
• Frequent, verbose comments in code can act like extended thinking
• Unlike previous advice: redundancy is useful!
• Think about the things that you can't say with your code and put them in comments
  • "For all" contracts, for instance
• Agents are very good at generating and maintaining comments
  • Add a CI step that asks an agent to verify all of the comments related to changes in your pull request!

• Basic idea: programming language features that force developers to put as much information as possible at both the call site and the definition. Examples:
  • Keyword arguments in Python (and Swift, OCaml, Kotlin, and countless others):

  • Objective-C (and Smalltalk, which inspired it) actually require this:

• More examples:
  • Explicit reference binding for parameters in Rust:

  • inout in Swift:

• It's all about efficient context window usage!
• The more information we can put at the call site, the less likely we need to load the declaration (or even the definition) into context.
• But also, even if we had an large enough context window, explicit information at the call site reduces the probability that the LLM will make incorrect assumptions.
  • i.e., how does it even know that it should check the declaration/definition for counterintuitive behavior?
  • How do humans know when to do this?
• The importance of this could change a bit once we figure out how to train LLMs to use language servers efficiently.

• Both contracts and effects systems are ways of encapsulating information and reducing code coupling.
• Encapsulation is key to effectively working with LLMs because of the context window size constraints.
• But also, it's a lot easier to train LLMs on small, well-contained problems.
• Contracts promote Liskov Substitutability, allowing LLMs to infer behavior of a broader category of types.
• Effects systems further promote local reasoning by formalizing the boundaries around the behavior of a function.

* As long as the learning curve for these things isn't too steep...

• LLMs are shockingly similar to humans in the way they reason about code.
• But I suspect LLMs will have a different balance between the downsides of conceptual complexity in programming languages and the benefits of increased information locality.
  • An AI coding assistant is currently "like a junior engineer who's read the whole internet."
  • Knowing obscure information is not as much of a challenge for LLMs as it is for humans.
  • Code in formal languages in LLM training data is more likely to be correct (even if it's less plentiful)
  • Locality of information is still critical to LLMs, however, because of the limited context window size.

• Coding agents are tools that take somem time to learn to use
  • They generate output based on input, and the quality of their output depends on the quality of the input
  • The context window is all of the space you have to give input to the agent—use it efficiently!
  • "LLMs can't do this" is much less likely to be accurate than "I can't do this with an LLM"
• Coding agents are like junior engineers who have read the whole internet
  • It's worth taking the time to learn what they're good at and what they're bad at.
• Careful, intentional design can accelerate your development process more than ever before
  • Encapsulation and careful abstraction design matters now more than ever
  • Code coupling is more harmful than ever
  • Good documentation will pay off now more than ever
• The future of programming languages and software engineering is going to be anything but boring!

• Trained on millions of code files
• Has seen your favorite pattern thousands of times:
  • Every way to implement a singleton
  • Every variant of the visitor pattern
  • Every possible iterator implementation
  • Good code, bad code, and everything in between
• The model is essentially a compressed database of "what usually comes next"

The model is a pattern completion engine

• It works best when:
  • Your code follows patterns it's seen frequently
  • You establish clear context early
  • You use conventional naming
• It struggles when:
  • Your code is highly unusual or domain-specific
  • Context is ambiguous
  • You're doing something genuinely novel