Don't Trust the Process: How Design Work Is Being Rebuilt Around Engineers and Agents

Jenny Wen, who now leads design for Claude Cowork at Anthropic, says the standard design process of research, discovery and repeated diverging and converging was treated as gospel and fiercely defended. She gave a conference talk in Berlin last September called "don't trust the process," and argues that process was already wobbling before AI and is now effectively dead. Engineers can launch several Claude Code sessions at once, so designers have to let it go.

Wen admits the talk already feels outdated three or four months later, especially after the arrival of Opus 4.6 and many people discovering Claude Code over the holiday break. Engineering has changed far more than design so far, she says, and design is changing as a consequence. She expects design tooling to catch up within the next year or so.

Designers also benefit from the shift, because they now have access to the same coding tools. Wen describes doing a lot of last-mile work herself: implementing polish, working closely with engineers to get a feature across the line, and prototyping in real code rather than waiting for someone else to do it. Host Lenny Rachitsky sums it up as letting engineers cook while the designer helps connect and guide what ships.

Not everyone agrees. Wen says her talk is the most resonant one she has given, but it also drew backlash from people who have invested whole careers in a stable process and insist you cannot skip discovery. She thinks shipping and learning from real users wins with non-deterministic models, because you cannot mock up every state and have to discover use cases by watching people use the real thing.

Wen sees design work stratifying into two types. The first is supporting implementation: anyone can voice an idea, an engineer will usually make a scrappy version because they still implement better than designers do, and the designer no longer has time to produce beautiful mocks first.

The second type is creating vision or direction, which she calls the hardest to make time for. Designers used to produce two, five or even ten year visions, but with technology moving this fast nobody knows what happens in two years. The vision now typically looks 3 to 6 months ahead and is sometimes a prototype that points people in the right direction, not a carefully storytold deck.

That direction-setting still matters because when everyone can spin up their own agents and features, you need a shared target to keep the pieces coherent and efficient. Wen adds that she holds these opinions loosely and that they might change again in three months.

A good chunk of Wen's time at Anthropic goes to catching up on what is happening inside the company: research developments, many teams prototyping with code names, and internal debates about where the industry is going. She says Slack is a gold mine and that the best AI news is probably found inside a lab. She treats this as spotting what is coming up ahead.

She still reserves time for traditional design thinking, for example setting aside a week to consider what the next three months of Cowork could look like. The rest of the day is jamming with engineers through conversation and whiteboarding, giving feedback, and going into code to polish features an engineer has first implemented. A user researcher on her team still runs studies and surveys.

The proportions have shifted. Wen says a few years ago roughly 60 to 70% of her time was mocking and prototyping, about 20% was working with engineers and about 10% was coordination. Now mocking is 30 to 40%, pairing with engineers another 30 to 40%, and there is a new slice of actual implementation.

Her tool stack is "a fully Claude house": Claude chat, increasingly Claude Cowork for longer-running tasks, and Claude Code in VS Code because she tweaks front-end details and likes to see the code. She also uses Claude Code remotely from mobile and Slack, for instance mentioning Claude to fix a misaligned icon and then picking up the finished PR. She still uses Figma, which she says is better for exploring eight to ten directions at once, since coding tools are too linear.

When Wen consults on engineering projects, she explains why she thinks a certain way so engineers can extract principles instead of just receiving a verdict. She also points them to the design system and code, since Claude does not always pick up design-system components on its own. The aim is to equip people to make good calls without her in the room.

She acknowledges that keeping up is hard for everyone: now that people can do so much, they want to do more, and even engineers are asking how to keep up with themselves. On quality, she says the problem is not a lack of designers but too much for one designer to handle.

Her answer is to be deliberate about where a product sits in its adoption cycle. Claude Cowork was labelled a research preview, shipped knowing it was imperfect because the team believed the benefits outweighed the flaws. The promise to users is that feedback will be heard and the product will keep improving; trust is lost when something is released early and then nothing happens. Rachitsky calls this building trust through speed, and Wen agrees.

Asked where human brains stay valuable as AI takes over more of coding and product work, Wen says AI will get better at taste, judgment and design, and that people may be holding on to the idea of human taste too tightly. Still, someone has to decide what actually gets built and what matters.

She notes that many hard parts of building software are not building at all; they are disagreements between people about what belongs in a feature. AI can weigh in but cannot simply resolve a dispute. Rachitsky counters that he has been surprised how fast AI took over coding and suspects it could eventually present the data and recommend a decision to press a button on. Wen agrees people may undervalue how good it will get, but says someone still needs to be accountable, just as engineers remain accountable for whether code works.

On interfaces, Wen expects a mix of tactile UI and chat. Anthropic recently released widgets that let Claude ask questions and show things like weather or stocks interactively, and people like clicking and touching. But the chatbot paradigm opened up infinite flexibility, so she does not think it is going away, and she expects more UIs to be generated by models rather than hand-coded. Rachitsky adds that chatting over WhatsApp or Telegram was itself a big unlock, and relays a guest's point that talking scales across every level of intelligence.

Wen joined Anthropic as an individual contributor, managed a team for a few months, and is now back to full-time IC work. She was drawn by the work, wanted to stay close to it before ascending the ranks, and had doubts about whether middle management has a future. She says she loves both sides, but IC work gave her hard skills she would not have picked up while managing, because the design process changed so much in a year.

At Figma her team peaked at roughly 12 to 15 designers plus a few managers. She believes managers still matter, but pure people management such as career support and one-on-ones is less useful now; the manager of the future combines giving the team direction with creating the environment for good work. She expects to manage again, with a motto of "whatever it takes."

Her advice to design managers is to rotate back into hands-on work to understand how the job has changed, as engineering orgs sometimes do with new engineering managers. The thing she felt rustiest at was critiques: receiving critical feedback regularly is a vulnerable exercise.

Wen says Cowork came from many internal prototypes on top of different agent harnesses, and nobody was sure when it would be ready or what form it would take. The widely quoted 10 days was the time to go from what existed internally to something ready to ship externally, not the whole journey. The team had already tried different forms for to-do lists, multiple-choice questions and ways of teaching people use cases.

Forcing a release inside that window meant putting out what was already working and iterating afterward. Wen says she is mostly proud that they shipped, since designers mainly see flaws in their own work. She is excited about a homepage that feels like a shared to-do list between the user and Claude, and about asking whether Cowork should be stuck in the screen at all.

She describes Cowork as "Claude with hands," a phrase Rachitsky offers, and adds her own take: Claude is good at taking your garbage and turning it into something nice. She says the idea kept coming back until suddenly it was the right moment and felt obvious.

Beyond a general resilience and willingness to adapt, Wen names three archetypes she looks for. The first is the strong generalist, someone block-shaped rather than T-shaped, with several core skills at around the 80th percentile. Because the design role is stretching toward product management and engineering, such a person can flex easily, though she admits they are rare and hard to hire.

The second is the deep specialist: a T-shape whose stem goes deeper than most, perhaps top 10% in the industry. Examples she gives are a designer who is nearly a software engineer, which helps when working directly with models, or someone exceptional at visual design or icons, which differentiates products when anyone can make anything.

The third, which she thinks everyone overlooks, is the "craft new grad": early-career, wise beyond their years, humble and eager to learn, without baked-in processes and rituals. Her advice to young designers is to build lots of real things and share them with a community, citing the school-born Socratica movement. For senior designers, she says you need not learn React, but should know how to use the coding tools.

Asked whether she would hire Claude as a designer, Wen says it is not there yet. It is good at a first pass and at offering several ideas, but is not yet a strong generalist, deep specialist or standout new grad, though it has improved a lot in the past year.

Wen pushes back on the manager advice to drop "low leverage" work. The leaders she respects most take on such tasks themselves: testing the product relentlessly, dogfooding, reproducing bugs, sharing logs with engineers, or even putting in pull requests. This builds product familiarity and shows that nothing is beneath them.

She includes cultural examples too, such as vibe-coding a special anniversary card for a colleague, which shows a leader cares enough to put in effort an assistant could have handled. Rachitsky summarizes that the low-leverage stuff often has the most impact because reports don't expect it.

On her teams, people sometimes tease each other and her, for instance imitating her catchphrase of asking about next steps in crits. She doesn't force it, but treats it as a sign of psychological safety. The balance is to pair that safety with high standards, like a tough parent who is always there but expects great work, and she notes that safety makes applying high standards easier.

Wen is a fan of the legibility 2x2 from VC Evan Tana, which crosses legible and illegible founders with legible and illegible ideas. If both are legible, the idea is probably not novel. The interesting zone is the illegible idea: on the frontier, or told in a way people don't yet understand.

She thinks part of a designer's role at a frontier lab is to spot such ideas and transform them through storytelling or UX and form factor. Her example is an internal prototype called Claude Studio, a dense interface on an agentic harness showing knowledge, skills and previews of Claude's output. It confused her at first, but the energy around it among researchers was clear, and the skills framework came out of it. When she designed Cowork she pulled in elements such as Claude's plan, to-dos and context.

Rachitsky relates this to his research with VC Terrence Rohan on people who joined companies early, where crazy-sounding ideas, excited people and top-tier founders were recurring patterns. Wen's takeaway is to dig deeper when there is energy around something you don't yet understand, since early adopters often cannot articulate why they care.