Seven ideas, six quotes, and one book recommendation from sixty design leaders in a SoMa space under the Chatham House Rule. The most useful frame: AI does not automate design, it exposes what design was actually responsible for in the first place.
There was a moment around three in the afternoon when I looked around the room and realized I was sitting in what would have qualified, ten years ago, as a wedding reception for the entire design discipline. About sixty people in a converted SoMa space, most of whom had built or were currently building something the rest of us use every day. The companies represented in the registration list read like a menu of the platforms you have open in tabs as you read this. The major AI labs (Anthropic, OpenAI, and a few smaller ones I cannot in good conscience name). The large consumer and enterprise platforms (Microsoft AI, Google Search, Adobe, Figma, Expedia, Pinterest, Meta, Instagram, Atlassian, Zoom, Netflix, Cloudflare, Airbnb, JP Morgan Chase). The design tool makers and AI-native startups. The venture firms that fund the next batch (Designer Fund, True Ventures, Khosla, Sutter Hill). The schools and institutions training the next generation (Stanford, CCA, Harvard Business School, Rosenfeld Media, Big Medium). A long tail of stealth and seed-stage builders whose names I am not at liberty to spell out, plus the kind of independent practitioners whose names you would recognize from the bylines on the books on your shelf.
The event ran under what is called the Chatham House Rule, which is a polite British way of saying that you can take the ideas home with you and leave the speakers anonymous. So this is a piece about what was said. The names go unattributed. Wherever I refer to a panelist below, please mentally insert the appropriate vague gesture.
I will try to organize what I came home with, in roughly the order it landed. Fair warning that I came home with a lot.
The first useful idea, which arrived early and refused to leave, is that design is increasingly about how the thing works. The lineage of that sentence runs back about forty years of writing on the subject, so it is not a new claim. It landed differently in 2026 because the new generative tools have made the visual layer cheap to produce in ways that felt impossible eighteen months ago, and the leverage has obviously moved. If a model can produce a plausible interface in thirty seconds, the designer who composed the screen is no longer the rate-limiting step. The designer who decided what the system should do, how it should behave when it is uncertain, what it should refuse, how it should explain itself, when it should ask for help, when it should stay out of the way, that designer is the rate-limiting step. Visual craft remains valuable in the same way that handwriting remains valuable now that we type, which is to say it survives as a tributary rather than as the river. Behavioral craft is becoming the river.
The second useful idea showed up in a session about the tools emerging for builders. Tinkering is no longer a leisure activity for designers. It is the work itself. The people growing fastest right now are the ones who are constantly poking at small experiments, building internal hacks, trying the new model on the day it ships, getting a prototype running by lunch and discarding it by dinner. (One of our own designers flagged this six months ago, and I treated it as a personal observation rather than an industry signal. I am revising that assessment in real time.) The implication for design organizations is significant. Tinkering needs to be on the calendar, in the operating model, in the performance review. Treating it as something the most junior people do in their spare time was the right call in 2018 and is the wrong call in 2026. Leaders who lose touch with the craft will lose authority faster than they have ever lost it before, because the gap between “people who actually build” and “people who only review” is becoming visible inside thirty seconds of any working session.
The third useful idea, and the one that is going to require the most adjustment from established design organizations, is what one panelist named the cosplaying designer problem. Non-designers are doing design work now. PMs are doing it. Engineers are doing it. Marketers are doing it. Finance people who got curious are doing it. The instinct of every design organization I have ever sat in is to gatekeep, and the panel’s clear position was that the gatekeeping reflex is the wrong move. The right move is to teach the bar. Hold the cosplaying designer to the same process and the same critique as the designer. Some will self-select out. Others will learn what design actually involves. The few who stay will graduate from cosplay to practice, and the discipline will be stronger for it.
The teaching framework that came out of this thread, and which I will be importing into our own organization as soon as I have caught my breath, goes function, then form, then scale. You teach what the thing should do first. You teach how the thing should look second. You teach how the thing should live and grow third. The cosplaying designer’s most common failure mode is to skip step one and produce a beautifully rendered solution to a problem nobody had. The first job of any teaching designer is to slow that move down.
The fourth useful idea came from a head of design at a major creative software company, who articulated a position I want to import directly into my own product strategy. Their wager (which felt right to me in the moment and feels more right now that I have slept on it) is that users in serious creative or operational work do not actually want a slot machine. They do not want to roll the dice on a generation and hope for the best. They want exact control. They want to fill a specific selection, expand a specific area, rotate a specific object in three dimensions, eye-drop a visual property and re-prompt against it. The slot-machine model of generative AI, where you hit a button and pray, is the wrong default for any high-stakes work, and probably for most low-stakes work too. The implication for those of us building in regulated or high-trust domains, which in the work I do means clinicians making decisions about patient care, is direct. Our users want predictable, governable, precise AI affordances inside specific tasks. They do not want a magic wand. They want, if I can mix the metaphors slightly, a scalpel that listens, which is a much harder thing to design.
The fifth useful idea is connected to the fourth and is, I think, the hardest to operationalize. When generation gets cheap, the discipline shifts from “what should we make” to “what is worth making.” Saying no becomes the most important skill in the practice. The room was unusually candid about how bad most leaders are at this, including the leaders in the room (a hand-raise that took some courage, which is part of why the event was worth attending). The reframe I want to carry forward is that killing decisions need to feel productive rather than punitive, which means they need a process, a vocabulary, and a regular forum. Most organizations do not have those things yet, because we built our review structures for a world where shipping was the bottleneck. Shipping is no longer the bottleneck. Selecting is.
The sixth useful idea was offered as a confession, which I appreciated, by a head of design at another major company in the room. Their product has more than a dozen surfaces (canvases, prototyping environments, code-generation flows, sketching tools, an AI assistant, several diffusion-based image features). Most users only ever try one or two. The internal name for this is the front door problem, and the strategic direction is toward fluid movement between surfaces. I sat in my chair while this was being described and recognized our own product. We have practice management, telehealth, billing, claims, AI features, mobile, and increasing agentic capabilities, and as we add more AI affordances across pillars, the front door question is going to become bigger and harder. I do not have the answer yet. I am going to spend the next six weeks of leadership time on it, and I would encourage any product leader reading this to put the same question on their own list.
The seventh useful idea is the one I am most unsure about, which is probably why it deserves the most work. The question of where the canonical design source lives, in an era of AI-generated UI and code, is meaningfully unclear. Sometimes the canonical source is the codebase. Sometimes it is the design tool’s library. Sometimes it is a wiki layer that an agent maintains across both. The honest panel answer was “it depends,” which is not the answer anyone wanted, and which is probably the right one for this particular eighteen-month window. The companies that will pull ahead are the ones that develop a clear position on the question and communicate it across engineering, product, and any function that is using AI tools to generate within the system. The companies that drift will accumulate an increasingly incoherent set of artifacts that nobody fully trusts. I do not yet have a position. I will publish ours in this space when I do.
There was a book that surfaced in the corners of conversation throughout the day, and which I have ordered enough copies of to embarrass anyone in my immediate professional vicinity. It is called Sentient Design, by Josh Clark, and the framing it offers (treating AI as a design material rather than as a feature or a tool) is the most useful conceptual move I have seen for this moment. I will not summarize it here, because I would rather you read it. I will say that the design leaders in the room who had already read it carried themselves slightly differently from the design leaders who had not, in a way that was hard to put my finger on at the time and that I think I now understand. They had a vocabulary. The rest of us were borrowing one as we went.
I left the event around six-thirty in the evening, walked across SoMa toward the train, and had the strange feeling I sometimes get after a good night out, which is that I had taken in slightly too much and would need a couple of days to digest it. I have had those days now. The seven ideas above are the ones that survived. There are probably twice as many that did not survive, and which I will be embarrassed in six months not to have remembered, and which someone in the room is right now writing up better than I am writing this.
The most useful frame I came home with, the one underneath all the others, is that AI does not automate design. It exposes what design was actually responsible for in the first place. In healthy organizations, AI amplifies the underlying judgment, taste, and craft. In unhealthy ones, it amplifies the confusion, the inconsistency, and the lack of trust. The room was, as they say in some quarters of the internet, sober about this. Nobody was selling a magic future. Most people were trying to build, in real time, the practice that would let them deserve the future they were building. That feels like the only useful posture available to any of us. I left lucky to have been in the room and slightly more focused than I went in, which is about the best you can ask of any conference.
Finally, here are some quotes that stuck with me.
Quote 1: On hiring and role fluidity
“Hire people who can suspend disbelief, and let the quality of the person and the quality of the idea supersede role and title.”
Source framing for attribution: a senior design leader at a major global tech company, speaking during the day’s scaled-organization conversation.
Best use cases: HR partner conversations with HRBPs and recruiting calibration ahead of key hires. Pairs well with the Designer Fund data showing 50% of design leaders now placing more emphasis on AI fluency and 48% looking for stronger systems thinking.
Quote 2: On the design of AI affordances
“Users want exact control. The slot-machine randomness of broad generation is the wrong default for serious creative work.”
Source framing: a senior design executive at one of the leading creative software companies.
Best use cases: AIUX patterns conversations, complex narrative work. This is the strongest external validation I heard all day for the precision-over-randomness posture we want with our clinician-facing AI features. Clinicians do not want a slot machine. They want predictable, governable, precise affordances inside specific clinical and operational tasks.
Quote 3: On leadership restraint in an era of cheap generation
“Knowing what to say no to is the hardest and most important skill to build right now.”
Source framing: a VP-level design leader at a major design and prototyping platform.
Best use cases: product leadership conversations with CPOs and the PM peers, especially as we work through complex scope and the AIUX pattern unification question. The reframe is that when AI makes generation cheap, the discipline shifts from deciding what to make to deciding what is worth making. This quote opens that door without sounding scoldy.
Quote 4: On organizational health as a precondition for AI
“AI is primarily an amplifier of existing organizational health.”
Source framing: a finding from a widely cited 2025 industry research report on engineering and software development practices, surfaced during the day’s scaled-organization conversation.
Best use cases: cross-functional conversations with engineering and product leadership peers, especially around modernization and platform health. This is the empirical version of the “AI exposes what we were responsible for” frame, with the added benefit of being citable rather than anecdotal. Pairs well with arguments for investing in core coherence ahead of new AI surfaces, and gives senior leaders a reason to fund modernization work that does not look like net-new feature shipping. Also useful as a Warmup theme when the org needs a reminder that the operating system of the team matters more than the tool stack.
Quote 5: On the manager-IC distinction collapsing
“Managers are moving away from focusing on doing work versus leading. They’re doing work alongside ICs at equal rate. Tinkering equals satisfaction.”
Source framing: an investor and longtime design community figure, speaking from a survey of design leaders across company stages.
Best use cases: Design LT conversations about how managers and directors are spending their time, performance review calibration, and 1:1s with leaders who are wrestling with whether tinkering counts as real work. This is the empirical companion to the long-running tinkering thread, and validates a posture that has been articulated internally for some time. Especially useful as cover for managers who feel guilty about hands-on time, and as a reframe for ICs who think their managers are stepping on their work. The era of the pure strategist manager is closing, and the operators who keep building alongside their teams will pull ahead.
Quote 6: On welcoming non-designers into the practice
“Hold them to the same process and the same critique standards as your designers. Some will self-select out. Others will learn what design actually involves.”
Source framing: senior design leadership at two major design platform companies, speaking during the day’s tools and builder conversation.
Best use cases: cross-functional conversations about who owns design work, especially as PMs and engineers increasingly produce design artifacts using AI tools. This is the reframe for the “cosplaying designer” dynamic, and the operating principle that lets a design org be welcoming and exacting at the same time. Useful for design leadership conversations about review standards, for product peer conversations about what good looks like, and for ICs who feel territorial when their PMs ship Figma files. The principle that anchors it: outcome matters more than protecting the domain.