• 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 chatbot 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" a 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 metaprogramming
  • 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 macros
• 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!

/review-pr command, specified in commands/review-pr.md

silent-failure-hunter agent, specified in agents/silent-failure-hunter.md

• Building for ASI ("Artificial Super Intelligence") implies a mindset where anything we add to the agentic harness will be obsolete because the model will be so smart that it doesn't need our tools
  • Realistically, this has not been the trend in agentic coding
  • Giving agents more ability to get deterministic information (through tool calls, RAG, and hooks) has led to more autonomy and more reliability
• Building for AGI ("Artificial General Intelligence") assumes that future agents will have intelligence like the best humans
  • This means that the baseline assumption should be that tools that improve efficiency and reliability for humans should also improve efficiency and reliability for agents.
  • Generally, the most efficient humans make more use of coding tools, not less. Why should we think agents are any different?
  • Build tools that work with what we have now, and they will be even more useful as the model improves

• The vision: write a spec before bed, wake up with a usable implementation of that spec
• Problem: agents often stop working before a long-horizon task is done
  • This is partially because of how reinforcement learning works (to make any progress, you often need to give partial credit to partial solutions)
  • Also partially because we haven't fully evolved training away from the "chatbot" model (short turns, direct interaction, human-in-the-loop)
• Problem: agents often do things they know won't work if asked to examine their work
  • A lot of problems in software engineering are easier to assess for correctness than they are to solve.
• "Overnight" autonomy is often limited by the model deciding to stop working, not by it actually reaching the end of its ability to do productive work.

"I'm helping!"

Original post by Geoffrey Huntley: ghuntley.com/ralph

• Our version of this: feed the same prompt back into the agent until it is willing to "promise" (verbatim) that all parts of the task are done
  • We tell it that there are "special" <promise> tags that carry extra weight, and it must use those to exit the loop.

• Poor instruction following is a really hard problem to solve with reinforcement learning
  • Given a prompt with specific instructions, it's basically impossible to distinguish between changes that reinforce instruction following and changes that reinforce the specific behavior in those instructions
• Result: agent often "forgets" to follow instructions in the system prompt
  • e.g., "always use camelCase function names"
• This gets better if we remind the model of these instructions every turn
  • This uses a lot of context and doesn't scale well
• But what if we only remind it when the instructions are relevant?

• Basic idea:
  • Scan tool uses for unwanted patterns
  • Remind the model of your instructions when the pattern matches
  • Make it easy to add to the list of things you want to remind the model of
• Install the plugin (released last weekend just for this workshop!)

• Tell the model when there's something you don't like

• The model launches a subagent that creates the hook

• Launch multiple instances of Claude Code and give them a way to talk to each other
  • e.g., put each one in a separate tmux window and tell them to communicate with each other with tmux send-keys
• Assign one of them to be the technical lead
  • Tell it to not write any code itself
• Set up stop hooks that tell the technical lead when its workers are awaiting feedback
• Set up a Ralph Wiggum loop on the technical lead

• Your engineering skills are still valuable, even if you don't write much of the actual code yourself
  • (this is what it's always been like to be a technical lead on a large project)
• Prompts, hooks, and agent configurations are your new "source code"
• The skills that make you a good programmer transfer directly to this domain

• 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 a 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 some 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 matter 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