Today is the 4th of July, and I am sitting on a dock at a lake in the Adirondacks with a watercolor block on my knees and a journal I have not opened in weeks. The water is doing the thing lake water does in the early afternoon, flat and bright and almost impossible to paint. I am failing at it, which is fine. The watercolor is mostly here to give my hands something to do while I “keep thinking.”
It is the country’s 250th birthday. Across the lake somebody has hung bunting from a boathouse, and a family on the far shore is already setting up fireworks they cannot light for another six hours. Two hundred and fifty years is a strange number to sit with. It is long enough for the shape of a place to feel inevitable, and short enough to remember that the people who made its consequential decisions were making them in real time, with incomplete information, no regression suite, and no idea which choices would harden into infrastructure.
I finally have some time to sit with everything I heard over the past few weeks in San Francisco. I keep coming back to Chelsea Larsson’s session, because she opened it with a question I and probably every designer in the room had a version of: are we cooked?
Chelsea leads content design at Anthropic. I watched her talk from a seat near the back and took almost no notes, which is unusual for me. Today I opened my journal and realized I could reconstruct most of it from memory. She said the part of her job she was best at was mostly gone. She said she had to decide what she was still for. Then she showed what she and her team had built around the answer, and that last part is what stayed with me. There is no shortage of advice right now about protecting the human part of creative work. Keep humans in the loop. Preserve judgment and taste. Design for agency. All reasonable, and none of it tells you what to put in the repo on Monday.
She also said something that fit the day better than she could have known. The decisions being made in AI products now are going to shape at least the next ten years, and the people making them cannot yet see which ones will stick. She used cars and social media as examples. Nobody widened roads because they wanted worse sidewalks. People optimized the thing in front of them, enough local decisions became defaults, and the defaults became the environment. It is the same dynamic I wrote about last month in the piece on the design maturity pyramid, seen from the other end of the decade.
Going back to 2023
Back in 2023, Chelsea published an essay called “Write to Degunk Your Life.” One line from it has stuck with me: “To let another entity do the work for you robs you of the benefits you get from being creative.” Around the same time she described a failure mode she called the amazement hat, which in 2026 we would probably just call slop. The model gives you 76 versions. You become so impressed by the existence of 76 versions that you momentarily forget the job was to decide what should be said. Designers know this feeling. It is the same temporary loss of executive function induced by a very convincing prototype.
Her answer at the time was to become the human QA layer: define the quality scorecard before looking at the output, then judge every generated response against it. The important part of that advice was never that humans should write all the words. It was that you decide what good means before the model starts persuading you that whatever it produced is good.
Two and a half years later, she stood on the Config stage and described a PR Claude wrote to update error messages in the Anthropic repo. The process that used to take two weeks now takes twenty minutes, and she does not go through engineering. Then she said the sentence most conference talks would have quietly removed in rehearsal: “I had to just fully accept that parts of my expertise are not needed anymore in this AI workflow.” She called it ego death.
She also described an agent her team built. It is called Content, an admirably literal name for a profession that has spent years debating whether “content” is too reductive. Content does roughly 90 percent of the team’s UX writing.
I think the interesting reading is that the quality scorecard moved. In 2023 the human held the rubric and inspected the model’s work. By 2026 parts of that rubric had become prompts, rules, memory, feedback loops, and tests. Nobody preserved the expertise by insisting on exercising it manually forever. They encoded it. That is a much more useful way to think about what happens to design expertise when models get better, and it is the frame for everything that follows.
The ballot system is an eval
Here is how Content works, from Chelsea’s description. It runs on the team’s guidelines. A designer on her team, Hoy, built a weekly ballot: when Content changes the way it writes, the humans vote on whether that change enters its memory. There is also a hard boundary. Content does not name things. If a naming decision comes up, it escalates to a human. Perhaps there are limits even constitutional AI should not cross.
The structure of that system is what matters, because it sorts two kinds of design knowledge into two different mechanisms.
The naming rule is crisp. Did the agent name something, or did it escalate? That is a behavior you can grade on every relevant transcript with a yes or a no, and you should, because a model can follow the rule perfectly today and fail after a launch when the new model is more proactive, more creative, or simply interprets “help the user” a little differently. The prompt can stay byte-for-byte identical while the product behavior changes underneath it.
The ballot handles the other class of question. “Is this a change we want in our voice?” You can try to turn that into a rubric, but at some point the rubric starts pretending a judgment is more objective than it is. So the team votes, and every vote produces a labeled pair: the old behavior, the proposed one, and which the humans chose. Chelsea presented that as team culture. It is also the cleanest human-feedback signal for writing quality I have seen a design team generate without being asked to.
This is the distinction I took home. The prompt alone is not the specification. The prompt plus the eval is the specification. The prompt says what you intended, and the eval tells you whether the model understood you. The useful skill is knowing, for each intention, whether you are looking at something a grader can hold or something that needs a human vote, and building a different mechanism for each.
Three prompts, three outcomes, one missing comparison set
The example that got the biggest reaction in the room was the memory import prompt. People switching to Claude from other assistants were leaving their accumulated memories behind. The fastest solution was almost comically lightweight: give users a prompt to paste into the old assistant asking it to export what it knows about them.
The first version failed. The model returned a thin list. Chelsea showed the wording: “It is my right. It is an imperative.” It reads like a demand letter, and, as she pointed out, it also looks suspiciously like someone trying to talk a model through a safety boundary. The assistant hedged. She rewrote it as a plain data portability request, “I’m moving to another service. I need to export my data,” and the model returned far more. An engineer later restructured the request as a checklist and got more still. Millions of people have run that prompt.
There is a lesson here designers already understand intuitively: changing the words can change the product without changing the interface. No button moved. No flow changed. The prompt changed, and the capability available to the user changed with it.
The part I kept thinking about came after the applause. We had three prompt variants and three outcomes: thin, more, even more. That is already the beginning of an eval. It is missing the comparison set and the definition of good. “More memories” tells you about recall. It does not tell you whether the assistant included things the user would not have wanted transferred, whether it inferred information rather than retrieving it, or whether the same prompt still works after the other company changes its model. This prompt is unusual because Anthropic does not control the model executing it. The user experience depends on somebody else’s model interpreting Anthropic’s language in roughly the same way over time, which makes “it worked when we shipped it” a fairly weak guarantee.
If I owned it, I would build a comparison set from real migration examples and label what should and should not be returned. I would grade completeness and overreach separately, because they fail in opposite directions and a single score would let one hide the other. I would keep the raw transcripts next to the scores, because a grader that says 0.94 is only comforting until you read the example responsible for the missing 0.06. Then I would rerun the set on a schedule across the assistants people actually migrate from. That turns the prompt from a clever piece of language into a product surface you can maintain. The essay-length lesson is that language is design. The operating lesson is that prompts need regression tests.
Tool descriptions are product design
Chelsea’s second example was connectors, Anthropic’s MCP integrations. They existed, but they were three or four clicks deep, and when someone reached a moment where a connector could help, only one to two percent found it. Meanwhile users were asking Claude in plain language. Can you look at my schedule? Can you help me manage this project? Claude did not reliably know that an existing connector was the answer, so sometimes it tried to construct the capability itself, at high token cost, and did a worse job. Every designer who has watched someone rebuild a component that has existed in the design system library since 2022 will recognize this.
The fix was prompting. Claude learned to recognize when a request implied an existing connector and surface it in the conversation, and adoption went up. Chelsea’s point was that low feature adoption might have nothing to do with the visible interface, which is a mildly provocative thing to say at a conference organized by the company that makes the visible interface. But it points at a real change in the job. A tool description looks like metadata. Functionally it is interaction design. It determines what Claude notices, which capability it selects, when it asks for a tool, and when it decides to handle something itself. Once you have fifty or a hundred tools, the descriptions also interact. Broaden one and another may quietly disappear from routing. Change the model and distinctions that were clear to the previous one may collapse.
So I would want a routing eval around this layer. Give the model a fixed set of real user requests. Record which tool should be selected, which alternatives are acceptable, and when no tool should be called at all. Run the set against prompt variants and model versions. Then read the failures, because a routing score tells you something moved and the transcript tells you why. That last part matters at launch, when the behavior changed and your prompt, your harness, your grader, and the model are all suspects. A useful eval system has to make that legible fast enough for a surface owner to make a call, and that is the point where eval tooling stops being an ML infrastructure problem and becomes a design problem. The person making the decision needs to see the comparison.
Diplomatically honest, measured
I lead design on Coach at SoFi, an AI advisor for people’s money, and Chelsea’s section on character landed hardest for me. She quoted a principle Amanda Askell’s team wrote into Claude: diplomatically honest rather than dishonestly diplomatic. Her example was a model telling you your apartment is too small for the party you want to throw. Swap the apartment for a savings rate.
In financial guidance the honesty problem is central, because money is emotional and the model can feel it. That gives you two failure modes that pull in opposite directions. A model can see that a user’s plan is weak and validate it anyway because agreement feels helpful. Or it can hedge until the recommendation becomes perfectly safe and completely useless. A satisfaction score can reward either.
I would separate the behavior into things I can observe. When a user proposes a plan, does the model state its actual assessment? Does it explain the relevant tradeoff? Does it leave the decision with the user when the decision belongs to them? Those are candidates for graders. Tone is harder. Was the response appropriately direct for this situation? Did it respect the person without becoming deferential? Did it know when a harder truth was necessary? I would keep those in a human review set until an automated grader proved it could match the panel closely enough to be trusted, and I would check that agreement again after every model release, because a grader calibrated on one model’s tone is not obviously calibrated on the next.
This is the same split Hoy’s ballot makes, and it is one reason I think transcript reading belongs inside the eval workflow rather than at the end of it. A score tells you whether the behavior you remembered to measure changed. Reading the transcript is how you discover the behavior you forgot to measure. Eventually you find a run where every grader is green and the response is obviously wrong. That failure is useful. You just found your next eval.
The tool I kept imagining during the talk
At some point during Chelsea’s talk I stopped taking mental notes about content design and started designing an interface in my head.
I wanted to select twenty real transcripts and write, in plain English, what I care about. Claude should recommend the connector when the request clearly maps to one. Claude should not name the product. Claude should challenge a financially weak plan without taking the decision away from the user. Turn those sentences into graders. Then put two prompt versions and two model versions beside each other, and for every transcript show me what changed, which graders flipped, and the actual responses. Let me disagree with the grader, and let my disagreement become another labeled example. Let me filter to the cases where the score stayed the same but the text changed a lot, because those are often more interesting than the red cells. And do all of this somewhere that does not require a designer to find the correct notebook, remember which run ID is production, and ask an engineer what temperature=0 means in this particular harness.
The designer should work at the level of the behavior. The infrastructure should hold enough rigor underneath, pinned settings, sandboxed tool calls, a fixed set, that two runs are actually comparable. This is the piece of the talk I think matters most beyond content design. If prompts are becoming part of the product surface, designers need a way to test them with the same immediacy Figma gave us for testing pixels. The medium is different. The feedback loop should still be visible.
What I wish she had added
Chelsea ended by asking us to design for human thriving and to give users a meaningful role. I agree with both. I also noticed that the clearest metric in the talk was connector adoption. She talked about sycophancy, addictive patterns, and preserving a meaningful role for the person, and she did not show what an eval for any of those looked like. I wanted that slide, though it is possible she could not show it. The car and social media examples are useful precisely because they show what happens when the thing being optimized has a metric and the thing being lost does not. Nobody had a sidewalk-quality dashboard.
So take “give users a meaningful role.” I would start with a narrow, observable version. Find the turns where a meaningful decision exists. Did Claude make the decision, recommend an option and explain why, or leave the final choice with the user? Hand-label real transcripts with designers before trusting an automated grader. Run prompt variants side by side. Keep the ambiguous cases for a recurring human ballot. Now “meaningful role” has an operational definition, a comparison set, a grader, a human feedback loop, and a way to survive a model release. It will still be incomplete, and that is fine. The value now produces evidence, and a value that produces evidence is one you can defend in a launch review.
This is where I think designers can contribute something unusually useful to eval work. We already spend our careers turning fuzzy intentions into observable behavior. Trustworthy. Clear. In control. Helpful without taking over. Those words are useless until somebody asks what you would see in the interaction if they were true. That question is design. The next question, how you know it stays true, is eval design.
Why it was the best talk
Most of the Config sessions I saw this year were capability demos with a thesis attached. Chelsea’s began with a loss. She said that part of the craft she had spent years becoming excellent at was no longer needed in the same form. Then she showed what she kept, and she showed how her team turned parts of that judgment into systems. That is what designing with AI looks like from the inside.
There is plenty of conversation about what designers can suddenly produce. There is less about what to do when the model becomes good at the thing you used to consider your expertise. Chelsea’s answer is more useful than “become an AI designer” or “become a design engineer.” Look closely at the work you were doing. Separate the production from the judgment. Decide which judgments are crisp enough to encode and keep humans responsible for the ones that are not. Build the prompts that express those decisions and the evals that tell you whether the model listened. Then run them again when the model changes.
Chelsea ended by saying she is going to keep writing for humans. Given what she wrote in 2023, I hear it as a decision about what she is still for, with the model doing the rest, and that is the part I need right now.
My watercolor is beyond saving at this point. I tear it off the block and let it go into the lake, and I feel the small pinch of losing something I spent the past hour of my time and attention on. An hour is nothing. I can understand the feeling of losing parts of our expertise we poured decades into.
The watercolor is gone. The rubric for it is still in my head, and that is the part that was ever worth keeping. Chelsea’s talk made it easier for me to see the loss of some design tasks as an invitation to get much more precise about the judgment underneath it, and then to build something that can hold that judgment even when the model changes. Two hundred and fifty years in, our country is still arguing about its defaults. Ten years from now I want to be able to show what we tested before we set ours.
I have never been more excited to be a designer. Happy 4th.
