Roger Wong - Posts

A Sunday Afternoon with Claude Design

Tue, 21 Apr 2026 14:00:00 GMT

It's really hard to get momentum on a side project when you have a full-time job with lots of travel, an active blog, and a newsletter. But I had to recapture that momentum because this side project is important. It's for a preschool website for my cousin.

Walking into My Little Learning Tree is like stepping into pure warmth. Yes, yes, preschools are inherently fun environments, but the kids and the teachers there create a visceral energy that is simply special. I wanted to capture that specialness in a long-overdue website redesign project.

Looking at my in-progress design, something felt off. I had these long horizontal lines preceding the eyebrows—the small text above a heading that names the section—that didn't feel right. First, they were straight. Second, the lines only occurred before the text, not also after. I clicked on the Comment button to enter Comment mode, then clicked on the eyebrow and prompted, "These lines aren't playful enough. Let's make them squiggles and have them before and after the eyebrow text."

And then Claude Design did its thing.

A Shot Across Figma's Bow

Anthropic announced Claude Design with a blog post on Friday morning:

Claude Design gives designers room to explore widely and everyone else a way to produce visual work. Describe what you need and Claude builds a first version. From there, you refine through conversation, inline comments, direct edits, or custom sliders (made by Claude) until it’s right. When given access, Claude can also apply your team’s design system to every project automatically, so the output is consistent with the rest of your company’s designs.

https://www.youtube.com/watch?v=t_LBECIQQqs

Reaction was immediate and mixed. Figma noticed, of course, with CEO Dylan Field posting this on Twitter, insinuating Claude Design is a copycat:

pic.twitter.com/om4Ka9n0s6
— Dylan Field (@zoink) April 17, 2026

The market wasn't subtle either. Figma's stock took a hit on the news, closing nearly seven points lower than the previous day. Investors treat every AI announcement as a threat to the incumbent, which is usually noise. But this time some of the anxiety was warranted.

The reaction inside the design community was more interesting, and less unanimous. Enthusiasts treated Claude Design as the next natural step in an AI-native design pipeline. Skeptics waved it off as a wrapper around Claude Code.

The Room Is Split

My friend Christopher Noessel, a veteran UX designer and author of Designing Assistant Technology, handed Claude Design a toy problem and got back a dozen competent-looking screens. His reaction:

I sat there staring at a page of screens and felt something I hadn't felt in years: the specific sense of being overwhelmed when on the receiving end of a design dump. I couldn't tell you which comp was best. I couldn't tell you why any of them were the way they were.

Noessel's thesis is the sentence that anchors his piece:

Design was never the comps.

The comps are an artifact of design. They are not the thing itself.

I agree. My Claude Design output started at a B- and got to an A because I brought a specific model of what this preschool should feel like (handmade, warm, low on corporate polish) and applied that model across dozens of decisions. The squiggly line wasn't a design move. The decision to change the line to a squiggle was the move. Noessel calls the hidden part "model-building." That's what the afternoon was.

Sam Henri Gold took the structural angle, arguing that Figma's proprietary format quietly locked it out of the agentic era:

By nature of having a locked-down, largely-undocumented format that's painful to work with programmatically, Figma accidentally excluded themselves from the training data that would have made them relevant in the agentic era. LLMs were trained on code, not Figma primitives, so models never learned them. As code becomes easier for designers to write and agents keep improving, the source of truth will naturally migrate back to code.

This maps directly to what I saw. I tested Claude Design against Paper, another HTML/CSS/JS-native tool, with the same context. Paper produced a C- or D. Claude Design started at a B-. Neither forced me to commit to a framework or a backend yet. That's why I picked this category over v0, Lovable, or Figma Make for the design phase. Gold invokes an Arts and Crafts principle called "truth to materials": a thing should be honest about what it is and how it's made. HTML, CSS, and JavaScript are the material of the web. I was working in it the whole time.

Not every take agreed. Michal Malewicz, a product designer and author, argues that Claude Design is Claude Code in different clothes:

So this tool is some extra .md files wrapped in a shiny "new" product that can make Figma stock go down. That makes headlines, people talk about you, investors feel the innovation go Brrr.

But in reality, this is the same Claude Code you used for the last year.

I half agree. The underlying model is the same. Opus 4.7 sits behind both. Hell, I even used Opus 4.7 with Paper. Claude Design gave me more than Claude Code in the terminal. I could click any element to edit it directly, or drop a typed comment on a selected region. A draw mode let me sketch annotations over the prototype. It treated my brand style guide as core context, not a reference file. The work felt like design review all the way through. Malewicz is right that a skilled prompter can coax similar output from Claude Code. But the tool's posture changes what a non-coder can reach for, and that matters more than what a power user can reproduce.

Arpy Dragffy, co-host of the Product Impact Podcast, takes Gold's argument a step further. He says Claude Design doesn't kill Figma. It forces Figma to become something bigger:

Figma's survival path is not competing with five AI generation tools. It's becoming the system of record for what design means across the entire organization.

His argument rests on a historical pattern. GitHub got more valuable as AI generated more code. Obsidian got more valuable as AI generated more knowledge. When generation is commodity, the platform that holds the canonical version becomes the leverage point.

He's right that a canonical reference matters more now, not less. But Figma isn't where that reference lives.

Production is the source of truth for any application. What users are actually experiencing is the only reference that can't drift. Below that, design decisions live in two places: the design system, which is increasingly a code artifact that both designers and agents can read, and the specs written during feature creation. Figma is where exploration and composition happen. That's a real and durable role. But when a feature ships, the design system has been updated in code, the spec documents the intent, and production embodies the result. A Figma file is a snapshot of a moment in the design process, not the authoritative answer.

Claude Design in Practice

The Infinite Canvas Still Has a Role

So with the release of Claude Design, I don't believe that "Figma is cooked." It still has a role to play. For the longest time, artists have ideated visually. Pablo Picasso sketched nine studies before painting his 25-foot Guernica masterpiece. To explore the aesthetics of the preschool website, I couldn't have prompted my way through it. I had to import visual inspiration into the workspace and then started making. To work out complicated user flows for an app, typing is not the answer. An infinite canvas is.

I say this with certainty because I believe that designers are generally visual thinkers. A never-ending whiteboard like Figma is great for exploration. You can diverge without reaching the edges. (Which I have, many times, in Illustrator.)

Figma Make was supposed to be the tool to turn static mockups into more realistic prototypes. Yeah, I guess. But it feels heavy. Make spins up a Vite site and writes a ton of React code. In fact, so do all the other prompt-to-code tools like Lovable and v0. They're writing React frontends with all their associated bloat: dependencies are being installed, components are being created and imported, etc. Whether it's Vite or Next.js, those are applications that need to build and then be served on localhost to be previewed.

Whereas Claude Design is simply HTML, CSS, and JavaScript. The raw materials of the web. In fact, Claude Design will simply export an HTML file with linked assets in a zip. This can be double-clicked and opened in any browser.

The Decent Junior Designer

Working with Claude Design is like working with a pretty decent junior designer. For the preschool site, I gave it some context: a visual direction expressed as a concept blurb and a style tile, a written brand style guide, the design brief for the project, and the website copy deck. I asked it to create a homepage based on all that context.

The first draft was a solid B- grade. Just above average. It had some personality and playfulness to it that I didn't expect. Impressed, I worked with Claude Design through about four dozen iterations to nail the font choices, typography scale, layout, and a bunch of micro-tweaks to something I was proud to share with my client. What Claude Design produced for me was a great head start that I could work with.

Unlike Claude Chat or Cowork, this is an artifact-first layout and gives you multiple ways to work with it. I could select a piece of text on the page and directly change the copy or tweak the font, size, color, or any of the traditional properties of type. The changes happened immediately in front of me. But as soon as I exited Edit mode, I noticed that Claude remembered the changes and wrote a prompt for itself to update the code. Interesting.

Other ways to give Claude feedback on the output include selecting an element and commenting on it, and drawing on top of it.

One of my senior designers at BuildOps also tried the app over the weekend. She took a different approach, closer to what Noessel did. She asked for variations. Working on design system components, she had Claude Design explore muliple directions and asked it to provide rationale for each one. They worked iteratively and when she was satisfied, asked it to write a design brief as part of the handoff, giving Claude Code even more context in the next step.

Design Systems Baked In

Speaking of design systems, they are central to Claude Design, which reflects the enterprise focus Anthropic has always had.

The app doesn't take your Figma file or component codebase as-is. Instead, it walks you through a translation workflow. It ingests the inputs—all in-browser—and then writes simpler HTML/CSS/JS versions.

Claude Design walks the user through a workflow to build a design system for use inside the app.

It took some iteration. It's about 80% right off the bat, and over about an hour, I tweaked the remaining to get it to 90%. Which is good enough for prototyping purposes.

Once published—borrowing that term from Figma—it's available for anyone in your company to use. Our CMO built one for slide decks and marketing docs. I built one for product design.

HTML with a Pinch of React

The handoff is where things get interesting. Although the delivered output is HTML, Anthropic itself doesn't see these artifacts as production-ready. There's an explicit handoff to Claude Code. And included in the handoff package is a README file that says:

The design medium is HTML/CSS/JS — these are prototypes, not production code. Your job is to recreate them pixel-perfectly in whatever technology makes sense for the target codebase (React, Vue, native, whatever fits). Match the visual output; don't copy the prototype's internal structure unless it happens to fit.

Don't render these files in a browser or take screenshots unless the user asks you to. Everything you need — dimensions, colors, layout rules — is spelled out in the source. Read the HTML and CSS directly; a screenshot won't tell you anything they don't.

Despite all our advances in AI and design tooling, the design-to-code handoff gap remains! For the longest time, I've argued that solving the gap is the holy grail. I believe this is an explicit tradeoff the Claude Design team makes: speed and ease of use over production-readiness.

One more nuance: there's React underneath. Poking around an exported bundle, I found .jsx files. These are React component files, not plain JavaScript. The bundle ships as a static HTML file that loads React and a JSX transpiler (Babel) from a CDN at runtime. Every .jsx file is loaded as a browser-transpiled script. No npm install, no build step, double-click to run.

The tradeoff makes sense once you see what these prototypes do. My webapp prototypes had view switching, filter toggles, and an edit mode. Hand-rolled DOM manipulation would be miserable and would drift from how a real app behaves. React handles state; plain HTML doesn't. So Claude Design authors in React but delivers static files, which means the handoff to Claude Code ports interaction logic over cleanly even when the visuals get rebuilt.

Halfway to a Design Playground

The beauty of Claude artifacts is that you can publish them so that anyone with a link can view them. For prototyping, especially for unmoderated testing, shareable links are a must-have. Anthropic has decided—at least for v1—that sharing was out of scope. So as a design playground, it's only halfway there.

Figma Make, v0, Lovable, and other prompt-to-code tools have that sharing built in. But the cost is a bit more friction and yet another subscription. Even Figma is charging for AI credits now.

But Claude Design is included in Anthropic's paid plans. Fair warning though: It's token hungry. When working on the design system for BuildOps, I received an "extra usage" warning. Not only that, it filled up its context window and literally lost the plot.

During one edit that I asked for, after spinning for a bit, it finished but said, "I've lost the specific task details in the context trim. Could you remind me what you'd like me to build or update?" To its credit, it remembered much of it, but yes, I had to remind it, and I'm glad it didn't just assume and hallucinate the original request.

Where It Lands

As it stands today, I think Claude Design fits somewhere in the process between Figma and Claude Code. And Anthropic seems to acknowledge that by including Figma file import capabilities. It doesn't pretend to replace Claude Code, purposefully relying on lighter-weight, minimal React to help you visualize your design.

Working with Claude Design on Sunday afternoon was fun, not arduous. I was able to use my judgment, taste, and years of experience to shape a website design to my liking, like chiseling a marble statue. The design emerged as I worked with it.

My cousin ended up really liking the homepage direction I sent her. Of course, I had to send a zip and instructions on how to view the HTML, but it worked. There's still a lot to do: finalizing the illustrations and putting in the real photos, building out the other pages, and getting it live. But I'm excited to continue trying out this new workflow all the way through Claude Code helping me ship the thing. I'll be sure to share it when I'm done.

Acceleration Is Not Automation

Tue, 14 Apr 2026 16:00:00 GMT

I've been wandering the wilderness to understand where the software design profession is going. Via this blog and my newsletter, I've been exploring the possibilities by reading, commenting, and writing. Many other designers are in the same boat, with Erika Flowers's Zero Vector design methodology being the most defined. Kudos to her for being one of the first—if not the first—to plant the flag.

Directionally Flowers is right. But for me, working in a team and on B2B software, it feels too simplistic and ignores the realities of working with customers and counterparts in product management and engineering. (That's her whole point: one person to do it all, no handoff.)

The destination is within view. But it's hazy and distant. The path to get there is unclear, like driving through soupy fog when your headlights reflecting off the mist are all you can see.

At the core, I don't believe the process has changed because the UX design process mirrors the scientific method:

Observe
Question
Hypothesize
Experiment
Test
Analyze

https://www.youtube.com/watch?v=CtxdhnieTCQ

"Never Over" TV commercial for Eli Lllly by Wieden+Kennedy, 2026

Compare with the design thinking framework popularized by IDEO and Stanford's d.school in the late 1990s and 2000s:

Observe → Empathize
Question → Define
Hypothesize → Ideate
Experiment → Prototype
Test → Test
Analyze → (Analyze)

The Design Thinking framework from Standford's d.school.

Even if you don't consciously follow the official design thinking process, as a designer you do it anyway. Research → ideate → test → iterate. It's the same thing at a high level.

The Double Diamond expands on this a bit, explaining other aspects that we designers do.

Discover, or research and observe what's happening in the problem space
Define, or analyze your research and define the problem
Develop, diverge on solutions to that problem
Deliver, start homing in on solutions via testing

The Double Diamond design process from the Design Council.

So the question about where design is going is less about the overall process—because it stays the same, just compressed—and more about who is doing what with what. In other words, on a daily basis, what are designers doing and what tools are they using.

The Coding World Changed in Three Months

https://www.youtube.com/watch?v=wc8FBhQtdsA

The industry has moved incredibly fast. First, coding was upended by agentic engineering. Developer and AI researcher Simon Willison said recently on Lenny's Podcast:

…All of the software engineers who took time off over the over the holidays and started tinkering with this stuff got this moment of realization where it's like, "Oh wow this stuff actually works now. I could tell it to build code and if I describe that code well enough, it'll follow the instructions and it'll build the thing that I asked it to build."

I think the reverberations to that are still shaking us [through] software engineering. A lot of people woke up in January and February and started realizing, "Oh wow, this technology which I'd been kind of paying attention to, suddenly it's got really really good." And what does that mean? Like what does the fact [that] I can churn out 10,000 lines of code in a day and most of it works. Is that good? Like how do we get from "most of it works" to "all of it works"?

What was a slow simmer that started with Cursor's autocomplete and step-by-step prompting, quickly turned into a rapid boil with Claude Code and Opus 4.5 in November 2025. By January 2026, developers like Geoffrey Huntley discovered the Ralph Wiggum loop applying reinforcement learning to Claude Code forcing itself to continue until its task was solved without bugs; and Steve Yegge released the token-burning automated software factory Gas Town. Over the course of the last three months, innovations kept coming: skills, Markdown files serving as how-tos for agents, teams of multiple agents, and a plethora of agent "harnesses," or apparatuses to orchestrate multiple agent teams. All together, these new tools have effectively automated programming, with developers now commanding multiple teams of AI agents. As Willison put it, "I can fire up four agents in parallel and have them work on four different problems. And by 11 AM, I am wiped out for the day."

With AI transforming engineering well underway, the question becomes, "What else can be accelerated in software development?" The other legs of the three-legged stool, of course.

What Else Can Be Accelerated?

Writing PRDs

Many product management activities can be accelerated with AI. Given the right inputs, CSVs of analytics data, Markdown transcripts of customer calls, deep research on market conditions, Claude Cowork can produce decent if not great analyses. Talk about findings in a team meeting and then feed that transcript back through Claude and then you can get a tight PRD. The core PM deliverable can be automated.

The quality of the deliverable is, at best, a C+ out of the box. It might read well and seem credible, but with a little critical thinking, you'll realize the PRD is full of holes and gross assumptions. You need to give it a battle-tested template and build a skill that considers the right context to write the PRD. You'll need to iterate, employing reinforcement learning to compound the AI's experience. Keep improving the skill until the PRDs get better.

Of course, PRDs are just one deliverable out of many a PM might be responsible for. But for building something, I'd argue it's the most important, because it feeds everything else. Because it's the beginning of the spec.

With a PRD, how would an AI come up with a solution? What could be automated on the design front?

Designing Flows and Prototypes

https://www.youtube.com/watch?v=iaAT6-dY1QI

"Tea. Earl Grey. Hot."

The magic of LLMs is that you can ask it for anything and it'll make it. It's like the Star Trek replicator but for digital artifacts. Like replicator food, the generated simulacra isn't necessarily good. I've tried a few times to generate flows from Claude. Feeding it a PRD, I asked for a user flow and got a Mermaid diagram which could be rendered as a flowchart in FigJam or Figma via a plugin. There's a thing that we humans do when we think about systems: we simplify and calibrate the level of granularity so a flow is easy to understand. What I've found with the few flows I've generated with Claude is that it tends to flex the altitude in the same chart. Sometimes it's super low and detailed, and other times it's high and hand-wavy. With work and iterating on a skill, I'm sure flows can get better.

This is true of any of our deliverables, even wireframes, mocks, and prototypes. Iterate on a skill to get the deliverables better and improve over time.

The AI foundational model capabilities will grow exponentially and AI-enabled design tools will benefit from the algorithmic advances. Sources: AI 2027 scenario & Roger Wong

A year ago in "Prompt. Generate. Deploy.", I forecasted this workflow arriving via tools like Tempo, which bundled PRD → flow → wireframes → code into a single pipeline. That bundled version didn't quite materialize. But the pieces did, just unbundled across Claude, Figma plugins, and v0.

But if we're prompting flows and prototypes into existence, what should we do with the newfound gains in productivity? Not play solitaire while Claude churns, of course. Instead, we can test more.

In Jake Knapp's Design Sprint, paper or low-fidelity prototypes were used to validate hypotheses. And, if you're lucky, you could get through maybe two iterations. But the core idea is to get validation signal from real customers and users about your solution via a prototype. Now, with AI, you can iterate on a working prototype quickly enough that talking to more customers and sharing more variations is possible. This multiplies the confidence in your solution, lowering the risk of spending resources to launch it.

The 5-day design sprint from "Sprint" by Jake Knapp.

Design-to-Code Handoff

Once you have a validated prototype, you can go about designing the real thing. Maybe you'll want to continue to do it in Figma like always, or maybe you'll use newer AI-powered tools like v0, Lovable, or Claude Code. Or maybe you'll use your prototype as the base and make it production-ready. In any case, you have the opportunity to shape the material directly, to actually make the thing instead of a picture of the thing.

For designers, I believe it's possible to build the front-end, at the very least. Some platforms have really complex application logic and backends, so I tend to trust software engineers more than me. But if I can hand off a fully-formed frontend to engineering to hook up the backend, then design QA is cut down by 90% because I made it.

Acceleration vs Automation

In the use cases I described above—faster PRD writing, faster flows and prototypes, are they really automation? Or is the artifact generation simply being accelerated?

Agentic engineering is truly automation. Engineers who are orchestrating teams of agents feed them prompts and then sit back and wait for the results. It's closer to George Jetson sitting at a console pushing a button as a job. Yes, I know there's more to it. Getting the spec right is the secret. And it's the PRDs and designs that make up the spec.

We haven't really gotten to automated PRDs from short prompts, much less automated flow design, high-fidelity mockups, and interactive prototypes. Each one of those deliverables still take extensive back and forth with the LLMs to get right, to get to something above mediocre.

As mentioned earlier, skills is one way to improve the output. But to truly automate, we have to think about breaking down the processes further into what specialists might do.

Enter the Agent Team

Augment Code's Intent agent orchestration GUI.

In agentic engineering, developers have figured out that they need to give agents certain roles or personas with specific instructions. For example, in Intent by Augment Code, they utilize a coordinator agent whose system prompt begins with:

You plan, delegate, and verify. You do NOT implement code yourself. You NEVER edit files directly. You have no file editing tools available. Delegation to implementor agents is the ONLY way code gets written.

And then a developer agent takes assigned tasks:

You plan and implement. You write specs first, then implement the work yourself after approval. No delegation, no sub-agents.

And finally, a verifier agent ensures the completed task is done right:

You verify the implementation against the spec’s Acceptance Criteria. You are evidence-driven: if you can’t point to concrete evidence, it’s not verified.

This team of agents works together to get something done. The planning, breaking down of a spec to bite-sized chunks, the coordination, and the testing is all done in this team until they think it's done. Sometimes this will go on for dozens of minutes.

A Team of PMs

We can take this same idea and apply it to product management work. I can imagine the following agents:

Customer researcher. Gather and summarize heaps of customer call transcripts, support tickets, product usage metrics, etc.
Market researcher. Research competitors and write detailed market analyses on the competitive landscape.
Business analyst. Extract the requirements from the research, compare against present state, then report findings.
Product strategist. Based on all of the above, create SWOT analysis, and then roadmap.
Product manager. Write a PRD for the first wave of the roadmap.

To do all of the above in a single skill would not yield great results. But having these specialized agents work together could produce meaningful artifacts. The human judgement PMs bring to the table will include institutional knowledge about the business, its product, and customer base. PMs should shape the AI's output via iterations.

(Obviously, product managers need to conduct the customer calls IRL. We're not talking about AI-automated user interviews.)

A Team of Design Specialists

MC Dean created an agent team of 10 design specialists. It's packaged together in something called Designpowers, inspired by Jesse Vincent's Superpowers. Her list of specialists include:

The design-strategist builds your flows, information architecture, personas, and design principles.

The design-scout does competitive research and pattern analysis.

The design-lead handles visual design — layout, colour, typography, components.

The motion-designer takes care of animation, transitions, and micro-interactions.

The content-writer writes interface copy at Grade 6 reading level.

The design-builder converts specs into production code.

The accessibility-reviewer runs WCAG and COGA evaluations on everything the team produces.

The design-critic reviews the work against your brief and principles, finding the gaps nobody else caught.

The inspiration-scout handles aesthetic references, cross-domain inspiration, mood boards.

The heuristic evaluator evaluates a design against established usability heuristics (Nielsen's 10) and conducts cognitive walkthroughs of key tasks.

I love this and I think this is the step towards automation I've been exploring in this essay. Looking at this list, I can see some agents that would be applicable in my day-to-day and some that aren't. I would also add some others. For what my team and I do at BuildOps, an operational platform for commercial contractors, I'd have the following design specialist agents:

UX researcher. Gather and summarize user interview transcripts, moderated and unmoderated studies, support tickets, product usage metrics, etc. Is there anything else that the Customer Research agent hasn't already discovered?
Design strategist. From the available research—above and from the Product agent team—brainstorm solutions that align with the product strategy.
Design architect. Given a high-level solution, map out all the flows including edge cases.
UX designer. From the flows, spec out all the necessary individual pages. What appears on each screen and what is the user expected to do?
UX copywriter. Writes any UX copy like component labels and user instructions according to our copywriting style guide.
Prototyper. Using the spec'd pages, make an interactive prototype. This can be used for testing and validation with customers and users.
Design builder. Turn the prototype into production-ready code. Incorporate the design system properly and account for error states and edge cases.
Accessibility reviewer. Ensures compliance with a11y guidelines and industry best practices.
Jakob Nielsen. Evaluate the final design against Nielsen's 10 UX heuristics.
Verifier. Double-check that the final design satisfies all the requirements from the PRD and finds any gaps that may have been missed.

All of the above assumes we have a rock-solid design system with a full assortment of components and documented patterns and rules.

We have the team, and now what? Is it really as simple as describing what you want to build? In Dean's Designpowers, the user acts as the creative director, intercepting "any handoff to correct, add, redirect, or skip." If we're to imagine a more automated workflow, the user here—you—would simply feed in the PRD as context, let the AI churn for a while, then inspect the resulting prototype and iterate from there. That is what agentic design would look like.

But then the bottleneck becomes you. Your judgement built on years of experience is what can shape and direct the agent team's output. As I argued in this week's newsletter, specialist experience is what builds the judgment an AI can't hold. "…Judgment compounds from pattern recognition that only comes from doing grunt work in one lane long enough to know what good looks like."

Walking Out of the Wilderness

If you're still with me, let's address this directly: Do we want to automate design? No. But it will happen, and is already happening in tech-forward companies like Silicon Valley startups. The answer is not to resist, but to adapt. To follow the skill, not cling onto the role.

Adapting will look different depending on what you're building and what happens if it breaks. For consumer apps and early-stage products, a solo operating commanding an agent team may be fine. For vertical SaaS, it isn't.

My team of designers do a lot of discovery, understanding the problem from multiple vantage points, and create bullet-proof solutions by thinking through edge cases, application performance, and integration points. We have to because we work on mission-critical operational software. If BuildOps doesn't work as expected, our customers' businesses will come to a grinding halt. That can't happen.

Which is why I don't believe a team of one can ship a robust feature end-to-end in vertical SaaS. There's too much complexity, but more importantly, there's too much at stake. As a designer, I don't understand the ins and outs of integrating with an enterprise accounting system. I'm not trained enough in engineering to be able to spot something amiss in AI-generated code that will result in catastrophe. But I do have the experience necessary in design to pick out and correct a poor user experience the AI may have built.

Here's what I see through the fog: agentic design is the future. But the process to actually run it isn't fully formed yet. I can see its outlines now. That's where I'm headed next.

Happy 50th Birthday, Apple

Wed, 01 Apr 2026 16:00:00 GMT

I went to grade school at a parochial school in San Francisco's North Beach. It was full of mostly middle class, neighborhood kids—an assortment of Italians, Chinese, and Filipinos from a ten-block radius. Half our teachers were nuns who lived in the convent on the same block. The other half were laypeople. To my surprise and delight, we had a computer lab back in the early- to mid-1980s, filled with maybe ten Apple IIe computers. It was seventh grade when I was allowed to take the class. Most computer classes at the time taught rudimentary programming in BASIC. This was a few years after I had watched the movie TRON on the big screen. And right after I had gotten my first Mac.

A few months into the class, in January, on a typical cool day in The City, I was in the computer class when the principal announced over the PA that a tragedy had struck the crew of the space shuttle Challenger. The group of us ran to the classroom where there was a television mounted at the corner. We watched the news report and the replay of the explosion—a trail of white smoke that split into a Y.

That image must have stuck with me because—well, what would a 12-year-old boy do but want to animate the launch and explosion. As my final project for my computer class, I made an animation of the launch. I mapped it out on grid paper first, and then painstakingly transferred those sprites pixel by pixel and frame by frame to the Apple IIe in my program. Over the course of days—weeks?—I typed in numbers for coordinates and letters for colors, and saved my work to a floppy disk.

Come finals time, I played the animation for my class and got some oohs and ahs. Looking back at it now, it was a dumb and tone-deaf idea. I should have animated a lamp jumping on a ball or something instead.

Anyway, that was an Apple memory I haven't shared before on this blog. Happy birthday, Apple. Thanks for 50 years of empowering crazy people like me to make crazy things.

Some favorite Apple-related posts I've written:

The Apple Design Process. My memory of working at Apple's Graphic Design group during the time of the iPod and the PowerMac G5.
For the Rest of Us. Apple has always done well in its marketing and advertising. This is my reflection on one of my favorite Apple spots.
30 Years of Mac. Don't judge, but this is the first thing I ever drew on a Mac.
Thank You, Steve. Here I share the story of one of the times I presented to Steve. This was an animation for MacBuddy, the Mac OS X setup assistant.

Spec-Driven Development: It Looks Like Waterfall (And I Feel Fine)

Wed, 04 Mar 2026 16:00:00 GMT

We've been talking a lot about agentic engineering, how software is now getting built with AI. As I look to see how design can complement this new development paradigm, a newish methodology called spec-driven development caught my eye. The idea is straightforward: you write a detailed specification first, then AI agents generate the code from it. The specification becomes the source of truth, not the code.

My first reaction when I started reading about SDD was: wait, isn't this just waterfall?

Seriously. You gather requirements. You write them down in a structured document. You hand that document to someone (or something) that builds to spec. That's the waterfall pattern. We spent two decades running away from it, and now it's back wearing a blue Patagonia vest and calling itself a methodology.

The Speed Changes Everything

But there is a difference.

In classic waterfall, the cost of building was so high that you had to get the specs right the first time. Six months of requirements gathering, six months of development, then you find out your assumptions were wrong. That's why agile won. Shorter cycles. Faster feedback. Accept that you'll be wrong and course-correct quickly.

Spec-driven development keeps the "write a spec" part of waterfall but compresses the build cycle from months to minutes. You write a tight spec. An AI agent generates the implementation. You evaluate it. You revise. You regenerate. The whole loop might take an afternoon.

That's not waterfall. That's agile wearing a trench coat.

Early adopters are already testing this. One developer documented building a transit-tracking web app using SDD: around 6,000 lines of code, eight features, roughly three days from spec to deploy. Two weeks later he came back and added new features without re-learning the codebase. He credits the specs.

ThoughtWorks frames SDD as a synthesis of older ideas: mathematical verification, API contracts, test-driven development, generating code from models. All adapted to an AI toolchain where agents can execute specs directly. Martin Fowler's team has been exploring the tooling around this, identifying three patterns: spec-first (the spec guides AI but code stays primary), spec-anchored (the spec persists as a governing contract), and spec-as-source (the spec is the source, code is disposable). That last one is the most radical. Code as a regenerable byproduct. Something you throw away and rebuild from the spec whenever requirements shift.

When execution is fast and cheap, the spec-then-build loop stops being a liability. You get the clarity of upfront thinking without the rigidity of committing to a plan you can't afford to change.

So Where Does Design Fit?

In most traditional workflows, design lives in its own silo. Designers make mockups in Figma, hand them off, and hope the implementation matches. In agile shops, designers embedded with sprint teams do better, but the fundamental pattern is the same: design produces artifacts that developers interpret.

SDD changes this. GitHub's spec-driven development toolkit captures user journeys, UX goals, and interaction patterns before any technical plan or code gets generated. Tools like Spec Kit Pro go further, embedding user flow diagrams, information architecture, and component hierarchies directly into the document as machine-readable contracts.

Design stops being a separate phase. It becomes part of the specification. In practice, a spec is usually a structured Markdown file (or a set of them) that lives in the same repo as the code. It reads like detailed acceptance criteria: who the user is, what they're trying to do, what happens at each step, and how success is measured.

Designers co-author the spec. They're the ones saying "here's what the user should experience," and that description becomes the thing AI agents and engineers build against. The InfoQ writeup on SDD describes plugging your design system (tokens, components, accessibility rules) into the spec so agents generate UI that conforms to the system by construction, not via manual pixel-pushing after the fact.

Instead of designers polishing at the end, they're drawing the boundaries at the beginning. The spec becomes the arbiter when behavior and design drift apart.

What This Actually Demands of Designers

There's a catch, and it's a big one. For design to live inside the specification, the ask is for designers to think structurally. You can't encode "make it feel premium" into a machine-readable specification. You can encode user flows, interaction states, component hierarchies, edge cases, and success criteria.

The idea is that designers structure design intent as documented behaviors and constraints that can be version-controlled, reviewed in pull requests, and treated with the same rigor as code. That's a long way from dragging rectangles in Figma. It's closer to how developers think, and that's the point.

I don't think this kills Figma. You still need to explore and iterate visually, and mockups can accompany the spec as reference. But the mockup isn't the deliverable anymore. The output of that visual exploration needs to be translatable into spec language.

Here's an example: You design a checkout flow in Figma. The annotation says "show error state if payment fails." That's testable, but it leaves room for interpretation. Which error state? Where does it appear? What happens to the form data? The spec version closes those gaps: "If payment fails, the user stays on the payment step. Their form data is preserved. An error message appears above the card fields explaining what went wrong. The submit button re-enables so they can retry." Same intent, less guesswork. What you're really doing is moving your annotations out of Figma and into the spec, where they stop being suggestions and start being enforceable. If you can't express your design intent in terms a system can enforce, you're back to tossing mockups over the wall and hoping for the best.

The Waterfall That Isn't

So yes, spec-driven development looks like waterfall if you squint. Spec first, build second. But the cycle time has collapsed from months to minutes, and that collapse changes everything. You're not betting the farm on a single document. You're writing disposable specifications, evaluating results, and iterating. That's the agile feedback loop with better documentation.

And for designers, the promise is real: design decisions encoded in the spec have teeth. They're not suggestions that get lost in translation between Figma and code. If the implementation drifts from the spec, the build can fail. That's more power than a red-line annotation in Figma ever had.

To be clear, this is still early. Most of the experience reports are solo developers on greenfield projects. One developer found that specs ate 50% of his total project time and eventually moved away from pure SDD as he scaled up. The evidence thins fast for team-based work and large codebases. But the direction is interesting, and the feedback loops are only getting faster.

ASCII Me

Fri, 20 Feb 2026 17:00:00 GMT

Over the past couple months, I've noticed a wave of ASCII-related projects show up on my feeds. WTH is ASCII? It's the basic set of letters, numbers, and symbols that old-school computers agreed to use for text.

ASCII (American Standard Code for Information Interchange) has 128 characters:

95 printable characters: digits 0–9, uppercase A–Z, lowercase a–z, space, and common punctuation and symbols.
33 control characters: non-printing codes like NUL, LF (line feed), CR (carriage return), and DEL used historically for devices like teletypes and printers.

Early internet users who remember plain text-only email and Usenet newsgroups would have encountered ASCII art like these:

 /\_/\
( o.o )
 > ^ <

It's a cat. Artist unknown.

   __/\\\\\\\\\\\\\____/\\\\\\\\\\\\\_______/\\\\\\\\\\\___
    _\/\\\/////////\\\_\/\\\/////////\\\___/\\\/////////\\\_
     _\/\\\_______\/\\\_\/\\\_______\/\\\__\//\\\______\///__
      _\/\\\\\\\\\\\\\\__\/\\\\\\\\\\\\\\____\////\\\_________
       _\/\\\/////////\\\_\/\\\/////////\\\______\////\\\______
        _\/\\\_______\/\\\_\/\\\_______\/\\\_________\////\\\___
         _\/\\\_______\/\\\_\/\\\_______\/\\\__/\\\______\//\\\__
          _\/\\\\\\\\\\\\\/__\/\\\\\\\\\\\\\/__\///\\\\\\\\\\\/___
           _\/////////////____\/////////////______\///////////_____

Dimensional lettering.

Anyway, you've seen it before and get the gist. My guess is that with Claude Code's halo effect, the terminal is making a comeback and generating interest in this long lost artform again. And it's text-based which is now fuel for AI.

Alex Harri goes on a deep dive on trying to make rendering images with ASCII better. It's an interesting project and post, complete with pretty animations and comparisons, leading us through his thinking.

If you want to watch and customize some hypnotic animated ASCII clouds, Caidan Williams has got you covered. Similar to the sci-fi interface maker by Braz De Pina, he made a playground to generate cloud animations using ASCII characters.

So this one is a little older, but I just came across it recently. Heikki Lotvonen created Glyph Drawing Club, a "modular" paint program as he describes it. You use glyphs—whether they're ASCII characters or fancier shapes—to create images.

Lotvonen is somewhat of an expert in text-based art, writing his BA thesis on Amiga ASCII art. In it, he traces the history of text art, from calligrams to Jewish micro-calligraphy to art on typewriters and teletype machines. Then, of course, on computers.

He clarifies that the term "ASCII art" is somewhat misleading:

Most ASCII art, however, is crafted using extended 8-bit or higher character sets. The most renowned forms of ASCII art are 7-bit ASCII art, ANSI art, Amiga ASCII, ATASCII, PETSCII, Shift_JIS, teletext, and Unicode art. Each employs a distinct character set and often a specific font to craft the images.

Mermaid diagrams are making a comeback too because of LLMs and Markdown. These diagrams are flow charts described in text and then rendered.

flowchart TD
	A[Christmas] -->|Get money| B(Go shopping)
	B --> C{Let me think}
	C -->|One| D[Laptop]
	C -->|Two| E[iPhone]
	C -->|Three| F[fa:fa-car Car]

The above gets rendered as…

So the that's the official Mermaid rendering engine. The folks behind the Craft notes app made their spin on the rendering with Beautiful Mermaid.

Mermaid diagrams made more beautiful.

Mike Bespalov made Mockdown, an ASCII wireframe generator and editor. You can use AI to generate quick, suuuuuper lo-fi wires, or draw them yourself.

Hmm, looks spot-on!

Alexander Belanger, cofounder of Hatchet, a data pipeline orchestrator, built a terminal UI for their product in two days using Claude Code. The TUI was built to give users a faster, more comfortable way to work that feels more performant than the existing web UI while still having the same functionality.

I love this comment [positive user feedback about the TUI], because it gets at the heart of why I love TUIs - they just feel easier to use, even though it uses the exact same API as the UI. They're also the opposite of how web applications have been trending the past few years: TUIs are text-first, information-dense, and most importantly, they live inline to your code, preventing constant tab switching. And since our users are primarily developing Hatchet tasks and durable workflows in their IDE, we wanted to provide an experience where workflows could be visualized and run from a terminal, instead of constantly switching between your code and your browser.

Belanger's view that TUIs are more performant is spot on. As designers, we need to remember that sometimes, less is more, especially when it's about getting work done.

Last, but not least, here's a fun terminal app that uses ASCII animation to show real-time weather. It's called Weathr, and is built by a dev named Veirt.

Terminal UIs are having a moment and us old timers are feeling lots of nostalgia about it.

Reactions to "Product Design Is Changing"

Thu, 19 Feb 2026 22:00:00 GMT

I posted my essay "Product Design Is Changing" earlier this week and shared it on both LinkedIn and Reddit. The reactions split in a way was entirely predictable: LinkedIn was largely in agreement, Reddit was largely hostile (including some downvotes!). Debate is healthy and I'm glad people are talking about it. What I don't want is designers willfully ignoring what is happening. To me, this similar to the industry-wide shifts when graphic design went from paste-up to desktop publishing, and then again from print to web. Folks have to adapt. To quote a previous essay of mine from August 2025:

The AI revolution mirrors the previous shifts in our industry, but with a crucial difference: it’s bigger and faster. Unlike the decade-long transitions from paste-up to desktop publishing and from print to web, AI’s impact is compressing adaptation timelines into months rather than years.

Anyway, I want to highlight some comments that widen the aperture a bit.

"I Didn't Sign Up for This"

Julian Quayle, a brilliant creative director I worked with a long time ago in my agency years, left a comment on LinkedIn: "So much for years of craft and imagination… I didn't sign up for this."

He's right. None of us signed up for it. And I don't want to be glib about that. There's a real grief in watching skills you spent years developing get compressed into a prompt. I've been doing this for 30 years. I know what it feels like to be proud of a pixel-perfect mockup, to care about the craft of visual design at a level that most people can't even perceive. That craft isn't worthless now. But the market is repricing it in real time, and pretending otherwise doesn't help anyone.

And to be sure, my essay was about software design. I'm sure there's an equivalent happening in the branding/graphic side of the house, but I can't speak to it.

(BTW, Julian is one of the funnest and nicest Brits I've ever worked with. When we talk about taste, his is insanely good. And he got to work with David Bowie. Yes.)

The Role-Stacking Problem

The most consistent objection on Reddit was some version of: "This is just companies piling engineering work onto designers."

u/gccumber put it bluntly:

The idea that I now have to do the work of a jr/mid engineer on top of my design work... well that's bonkers.

u/Top-Equivalent-5816 extended the argument:

If I don't understand the syntax I shouldn't be pushing it. And if I am learning and keeping up with current front end tech, I am not doing the UX work of requirement gathering, research, testing, sorting, charting goals, working backwards and executing. And if I am expected to do both that basically means I'll cut corners and serve you nice steamy AI slop.

They're both right about the risk. And I didn't address it specifically enough in the original essay.

What I should have been more explicit about: there's a critical difference between "designers should learn front-end engineering" and "designers should direct AI agents that produce code against a design system." I'm not writing React by hand. I'm pointing an AI agent at our component library and telling it what to build—using the same vocabulary I'd use in a Figma annotation or a design spec. The agent writes the code. I evaluate whether the output matches the intent.

That said, the cynics are right about what will happen at many companies. C-suites will absolutely use "designers and PMs can ship code now" as cover for cutting engineering headcount and stacking responsibilities. u/gccumber called it:

The C suite is happy to have the perceived savings of rolling multiple jobs into one. But those savings tend to get erased by burnout, low quality, slower output, and higher turnover.

This has happened before. It'll happen again. Companies that do this will ship worse products than companies that use AI to amplify their existing teams rather than shrink them. As I said in the essay, "Regardless of how many people or AI agents do the work, the work still needs to get done." The process still matters.

u/wandering-monster made the business case well:

The AI is not a unique advantage you have, it's a commodity. If you fire half your staff and your competition doesn't, they can now go twice as fast as you.

Role-stacking will happen. The question designers should be asking is whether they want to be at a company doing it, or a company using AI to let them do more of the work that actually matters.

The Collaboration I Undervalued

u/mattsanchen reminded me that friction in process is sometimes a good thing, writing:

It doesn't bother me at all to talk an engineer through my designs. They hold me accountable and are just as thoughtful as any of my other peers. It makes me sad to see all these pieces come out that make it seem like a burden to work with devs when it shouldn't be the case at all.

I read that and realized my original essay framed the designer-to-developer handoff purely as waste. It's not. The handoff is also a conversation—a forcing function where an engineer looks at your design and asks hard questions about edge cases, performance, and accessibility. Those conversations make the product better. Engineers catch things designers miss. The back-and-forth isn't pure friction. Some of it is quality control.

If designers start shipping code directly—even AI-generated code—what replaces that accountability? Who's catching the things that a design review in Figma would never surface? The answer has to involve getting engineering buy-in early and designers who understand enough about engineering to know what questions to ask.

The Tooling Isn't Ready for Most People

Another honest comment came from u/The_Singularious on Reddit:

Right now, in my non-genius mind, the setup process is a fucking mess. And it is complicated to the point that making a "mistake" can set you back pretty badly... I am struggling to build a damn Thanksgiving dinner RSVP site with working two-way data integration. When something breaks in Claude or Cursor, half the time I don't know WTF the problem is, and I can't get agents to explain them to me at my level.

They're right. The tooling is not ready for most designers right now. My experiment worked because I had prior experience directing AI coding agents and a willingness to iterate through failures. A designer trying this cold, without that foundation, is going to have a rough time.

Darren Bennett made a related point on LinkedIn: this works "for a certain kind of app and maturity. Companies with mature design systems can do this but for 0-1 the design role will be different." Correct. My thesis was pretty broad. It will apply to each situation a little differently.

I'm seeing this at work too—there's a ton of training that has to happen to get designers up to speed, comfortable, and efficient with these developer tools.

Where This Goes

So if the tooling isn't ready for most people, the role-stacking risk is real, and the collaboration with engineering has value I underplayed—does the original thesis still hold?

Yes. But the path is messy.

Uijun Park captured it well on LinkedIn:

You can only direct as well as you understand. The better your foundation, the better you can orchestrate.

The designers who will thrive in this transition aren't the ones who jump straight to AI code generation. They're the ones who deeply understand design systems, interaction patterns, and user needs—and then layer AI tools on top of that understanding.

The skill floor is rising, and that's genuinely scary for juniors. u/Repulsive_Policy1461 asked the question nobody has a great answer for: "WHAT DO WE JUNIORS DO WHEN NO ONE WANTS TO TAKE A CHANCE ON US?" I answered on the thread, and I'll repeat it here: businesses need to decide to invest in their future, and then they'll unlock funds to hire juniors. Until then, they won't, because most companies are short-sighted. My actionable advice: lean into agentic coding to turn your designs into functioning code. Start in Figma if you want, but use Claude Code, Codex, or whatever's current to turn it into an actual thing. If you can do this well, you'll outshine many other designers who are still debating whether it's coming.

u/susmab_676 might have had the sanest take in the entire discussion: AI is "a huge time saver. That allows me to spend more time on the details, and the why." That's the version of this future I'm working toward. Designers spending less time on production artifacts and more time on the thinking that makes products good.

Product Design Is Changing

Mon, 16 Feb 2026 17:00:00 GMT

I made my first website in Macromedia Dreamweaver in 1999. Its claim to fame was an environment with code on one side and a rudimentary WYSIWYG editor on the other. My site was a simple portfolio site, with a couple of animated GIFs thrown in for some interest. Over the years, I used other tools to create for the web, but usually, I left the coding to the experts. I'd design in Photoshop, Illustrator, Sketch, or Figma and then hand off to a developer. Until recently, with rebuilding this site a couple of times and working on a Severance fan project.

A couple weeks ago, as an experiment, I pointed Claude Code at our BuildOps design system repo and asked it to generate a screen using our components. It worked after about three prompts. Not one-shotted, but close. I sat there looking at a functioning UI—built from our actual components—and realized I'd just skipped the entire part of my job that I've spent many years doing: drawing pictures of apps and websites in a design tool, then handing them to someone else to build.

That moment crystallized something I'd been circling all last year. I wrote last spring about how execution skills were being commoditized and the designer's value was shifting toward taste and strategic direction. A month later I mapped out a timeline for how design systems would become the infrastructure that AI tools generate against—prompt, generate, deploy. That was ten months ago, and most of it is already happening. Product design is changing. Not in the way most people are talking about it, but in a way that's more fundamental and more interesting.

The Wrong Debate

The discourse around AI and product jobs is stuck on the wrong question. Scroll through LinkedIn on any given day and you'll find some variation of: "Will designers lose their jobs because PMs can use Figma Make?" or "Will engineers get replaced because designers can ship with Cursor?" This framing is about headcount. It's a turf war dressed up as industry analysis.

The real question is about process.

Regardless of how many people or AI agents do the work, the work still needs to get done. Problems need defining. Experiences need designing. Code needs writing. Shipping still has to happen. AI doesn't eliminate these functions—it changes who does them, how fast they happen, and where the bottlenecks land.

Here's what's occupying my brain these days: the invisible work—coding, PRD writing, data analysis, summarization—is easier to automate because quality gaps hide behind a user interface. If the code is ugly but the app works, nobody cares. If the PRD was AI-generated but the problem is framed correctly, nobody cares. But the visible work—the user interface, the flows, the experience, the thing people actually see and touch—is user-facing. Quality gaps show up there. Jankiness will show. Users will notice.

Phil Morton put it well:

When building becomes fast and cheap, the hardest problem isn't how to make something, it's deciding what's worth making at all.

The velocity gains in AI-assisted design will not match those in engineering. And that asymmetry is going to reshape the entire product development process and the way teams are assembled.

The Visible Work

I've been using a plumbing analogy in conversations lately and it seems to land, so let me try it here.

Engineering is like plumbing. It's behind a wall, it's hidden in the ceiling or floor, and as long as the water runs when I turn on the tap, who cares what it looks like underneath? The gains AI is delivering for engineers are real and massive. Boris Cherny runs four or five coding agents simultaneously. That's a 400%+ velocity increase, and it's increasingly how Silicon Valley engineers work—orchestrating teams of agents rather than writing code line by line.

But software design isn't behind a wall. It is the wall. It's the tap. It's the handle you grab to make the water come out. If the controls are reversed or the handle isn't intuitive, that's a bad experience—even if AI produced it. Users will care what it looks like, how it feels, how it actually works. It takes more human-in-the-loop intervention to shape AI output for product and design than it does for engineering. Again, AI can brute-force something in code to make a feature work. But it can't do the same for interfaces and flows to satisfy user needs. Why?

AI can follow standards, what it knows in its training data. We could even teach it design patterns specific to the application we're working on. But how does it make decisions based on a heap of user research: dozens of user interviews, survey results, usage analytics, competitive audits, etc. That's too much context.

There's another bottleneck nobody talks about. AI can automate production at incredible speed, but a human still has to read it, internalize it, and critically evaluate whether it's the right path. Call it the ingestion problem. Now that AI agents can generate a massive amount of code, code review is a real bottleneck (if PRs are done by humans, which they probably should). A colleague of mine extended this further—no matter how much AI pumps out or how many meetings it synthesizes, someone has to ingest the output to act on it. You still need a human to read it all if you want them to have an intelligent conversation about it. That's a human-speed constraint that no model can bypass.

Another friend of mine framed it simply: what AI does well right now is content generation and summarization in different forms. He doesn't see evidence it can create something novel or have taste. I agree. AI is excellent at producing volume. It's not excellent at making judgment calls about what that volume should contain.

Design in Code, Not in Figma

The single biggest bottleneck in product development is translating Figma mockups into production code. We all know this. It's the designer-to-developer handoff gap. We draw pictures of software, sweat over pixels, hand those pictures to engineers who replicate them as best they can, and then QA checks the coded pages against the mockups—rejecting PRs because the type is off or the spacing doesn't match. There's an enormous amount of swirl around this handoff, and it's been that way for as long as I've been doing this work.

AI collapses this bottleneck. But only if designers start designing in code. If we actually use the final material.

I'm hearing about designers dropping Figma entirely. Not hypothetically—actually canceling subscriptions and designing with AI tools instead. And the argument is hard to dismiss: mockups aren't the product. They're a parallel artifact that has to be translated, reviewed, and reconciled with what actually ships. Every pixel you push in Figma is a promise that an engineer has to keep in a completely different medium. The further your design tool sits from production code, the more waste you generate in the handoff.

Phil Morton called the current process "absurdly wasteful"—and he's right. We draw pictures of software and hand them to someone else to build. AI gives us the option to skip that translation step entirely, but only if we're willing to work in the same material we ship.

My own experiment—the one I described at the top—confirmed this. Three prompts, working UI, real components. To make it reliable at scale, you need robust documentation, explicit rules for how the design system fits together, and agent orchestration to reference that context at the right time. But the foundation is already there.

Monday.com's engineering team learned this the hard way. Their first attempt at AI-powered design-to-code was the obvious one: paste a Figma link into Cursor and let it generate code. The output looked fine at first glance. But the generated code didn't use their design system components. Colors were hardcoded. Typography overrode system defaults. CSS was written manually where it shouldn't have existed at all. The model had no understanding of what the design system actually was.

Their solution: they built a design-system MCP (Model Context Protocol) that makes the design system machine-readable—components, tokens, accessibility rules, usage patterns—and built an 11-node agentic workflow that constructs structured context for the model. The agent doesn't write code. It builds an understanding of what the code should be, then hands that context to the developer's coding agent. As they put it: "Orchestration, not magic."

This is already happening inside top companies. In a Cat Wu interview about how the Claude Code team ships, she mentioned an Anthropic's designer now making pull requests directly to Claude Code and the console product. A designer, committing code, shipping to production. That's not a theoretical future. That's February 2026.

What Stays Human

If AI can generate code, write PRDs, summarize research, and prototype interfaces, what's left for the humans?

The orchestration.

Anyone who's used these tools seriously knows this already. The models are capable enough. The bottleneck is the person at the keyboard—knowing what to ask for, how to break the work into pieces the model can handle, and when to reject what it gives back. The orchestrator matters more than the model. Kyle Zantos, a designer who now spends 70% of his working hours inside terminals, put it well on Dive Club: learn the philosophy and the approach more than the literal setup, because the tools change so fast that specific recommendations from four months ago are already outdated. What doesn't change is the skill of directing the work.

Quality in AI-powered products means something different than it used to. Surface polish isn't enough when the system underneath is unreliable. It goes back to building the right thing. Arin Bhowmick, SAP's Chief Design Officer, made this point well:

A visually polished interface can mask deeper issues: unreliable outputs, opaque decision-making, brittle behavior at the edges. Design leaders must stop measuring quality just by surface-level polish and instead treat trust, clarity, and reliability as first-class design outcomes.

Can users rely on the outputs? Do they understand why the system made a decision? Does it fail safely when it's wrong? Those are UX design questions, and they require human judgment to answer.

There's also the question of where AI should actually be applied in a design leader's day. Vlad Derdeicea wrote about this—design leads spend about 80% of their time on communication, alignment, and justification. Not on hands-on design work. Every design decision carries a "justification tax": the time spent explaining, documenting, and defending choices that other disciplines make in a quick conversation. AI should be targeting that 80%, not the mockup work. Use it to synthesize meeting notes, draft stakeholder communications, generate research summaries, and build quick prototypes that settle debates with data instead of opinions.

AI is getting very good at the 20%—the mockups, the prototypes, the visual production. What it can't do is the 80%.

The most forward-thinking framing I've seen comes from Jan Tegze: don't try to be better at your current job. Find the constraint in your domain that exists because of human limitations, then use agents to remove it—not to speed up your current tasks, but to do things that were previously impossible.

You're not competing with the agent. You're creating a new capability that requires both you and the agent.

Unfortunately, this means less experienced designers are at greater risk here. They lack the judgment to evaluate AI outputs. They don't have enough reps to know when the model is wrong. If you have five or fewer years of experience, you're at the short end of the stick. The skill floor is rising. Junior designers who can't critically assess AI-generated work will find their roles shrinking fast.

Small Teams, Big Leverage

Most software companies are organized wrong for this moment. They're PM-heavy feature factories where each squad gets a product manager regardless of whether it has dedicated design support. PMs multiplied during the ZIRP era because they sit closer to revenue and headcount scales with organizational complexity. Marty Cagan calls this "product management theater"—a surplus of ineffective PMs who resemble overpaid project managers, cranking out roadmaps and running standups.

Andrew Ng predicted at Davos that the PM-to-engineer ratio will flip from 1:8 toward 1:1 as AI explodes engineering productivity. If AI agents can write most production code, the wide engineering base shrinks. Specification and judgment become the scarce resources—not implementation.

There's a better model already in production. Airbnb merged product management with product marketing into a single "full-stack" role. Brian Chesky has said, "you can't develop products unless you know how to talk about the products," making storytelling and outward communication a first-class part of the PM job. More importantly, Chesky elevated designers to "architects" who sit alongside engineers and help drive the product—not a downstream service that catches tickets thrown over the wall. The coordination work that used to bloat PM headcount got moved to dedicated program managers.

This mirrors Apple's functional model: experts lead experts, the CEO is the integration point, and there are no "mini-CEO" product managers running business units. Both companies treat design as a co-owner of product direction, not an execution layer.

The ideal AI-era team is small: two or three engineers, a PM, and a designer. Empowered, fast, iterating constantly. Design systems become critical infrastructure—the backbone that makes AI-assisted design possible at scale. Without your design system and associated documentation in code, the AI is going to make all sorts of bad decisions about your UI and its implementation. The companies that invest in machine-readable design systems and small, empowered teams will ship circles around the ones still running feature factories with 15-person squads and three layers of approvals.

The Compounding Bet

That experiment I mentioned at the top—pointing Claude Code at our design system and getting working screens in three prompts—was version one. Since then I've been iterating on the setup: better documentation, tighter component rules, clearer instructions for how the system fits together. Each round gets faster and the output gets closer to production-ready. The models improve, their skills get refined, and I get better at directing them. That all compounds.

This is the part that should make designers pay attention. The gap between "designer who orchestrates AI" and "designer who pushes pixels in Figma" is going to be enormous within 12 months. Not because the pixel-pushers are bad at their jobs. Because the orchestrators will be operating at a fundamentally different speed and scope—shipping working UI while others are still exporting mockups for a handoff meeting.

I'm teaching my team to work this way now. Not because the job is dying. But because it's becoming a job where taste, judgment, and the ability to direct the work matter more than the ability to draw pictures of it. I'd rather have that job. I think most designers would.

UPDATE: I wrote a quick follow-up note highlighting some reactions to this essay from people on LinkedIn and Reddit.

What's Next in Vertical SaaS

Thu, 12 Feb 2026 22:45:00 GMT

After posting my essay about Wall Street and the B2B software stocks tumbling, I came across a few items that pulls on the thread even more, to something forward-looking.

Firstly, my old colleague Shawn Smith had a more nuanced reaction to the story. Smith has been both a customer many times over of Salesforce and a product manager there.

On the customer side, without exception, the sentiment was that Salesforce is an expensive partial solution. There were always gaps in what it could do, which were filled by janky workarounds. In every case, the organization at least considered building an in-house solution which would cover all the bases *and* cost less than the Salesforce contract. I think the threat of AI to Salesforce is very real in this sense. Companies will use it to build their own solutions, but this outcome is probably at least 2-5 years out in many cases because switching costs are real, and contracts are an obstacle.

He is less convinced about something like Adobe where individual preferences around tooling are more of the determining factor. The underlying threat in Smith's analysis—that companies will build their own solutions—points to a deeper question about which software businesses have real moats. Especially with newer, AI-native upstarts.

My former CEO, ex-ServiceTitan, and now Visiting Partner at Y Combinator, Charlie Warren writing in his brand new Substack:

A simple basket of vertical SaaS stocks — Veeva, Procore, Toast, AppFolio, and Guidewire — outperformed horizontal SaaS names like Salesforce, ServiceNow, CrowdStrike, Datadog, and Snowflake over the last couple weeks. But the results are relative. Vertical SaaS multiples have cratered, too.

So is Vertical SaaS also “over”? My unsatisfactory answer: it depends. That was my view before the sell off, so dear readers, you’ll have to trust me.

Warren continues, saying that we're entering a "Vertical AI 2.0" phase. He first sets some context about Vertical AI 1.0:

The core trait of Vertical AI 1.0 was not a lack of ambition. It was assuming the model layer with some unique workflows would remain the scarce asset.

Vertical AI 1.0 was model-first, office focused, and constrained to a few industries. Vertical AI 2.0 is data-first, extends beyond the desk, and applies to nearly every industry.

Vertical AI 1.0 began in late ‘23: novel approaches to LLM-friendly industries like legal, healthcare, and finance. Incredible companies and exceptional founders the likes of Ambience/Abridge, Legora/Harvey, and so forth. Many of these companies are and will continue to dominate, despite frenemy competition with model providers. It will be exciting to watch.

But for many of the other companies, their Vertical AI 1.0 strategy appears to have been: piggy back on model updates with maybe some fine tuning as the sole means of product improvements. Free riding is not a dominant (product) strategy. In recent weeks, Anthropic launched a suite of new finance tooling, OpenAI released Healthcare and then Frontier, and so forth.

And what does he mean by Vertical AI 2.0?

Vertical AI 2.0 is broader than before. …Vertical AI 2.0 is about finding where defensibility lives. And defensibility is a moving target across office and non office (i.e., field) workflows.

For inside the office, more defensibility will accrue to markets with an arcane mix of accounting, legal, & regulatory rules and unique access to data. Founders need to have a different product strategy than Vertical AI 1.0. Eli Dukes recently coined the term “Systems of Training” for these kinds of companies…

To put plainly, it's about the data and not just the raw data. It's the data recipe. Let's open up the post by Eli Dukes post about this.

I want to be careful here to define data in a particular way. What I am not suggesting here is that raw data itself is a particularly good moat. As everyone is well aware, interoperability has meant that structured + raw data is leaving and entering systems all the time. The storage of data is not really proprietary nor that valuable for applied AI companies. While someone will continue to own data storage (the systems of record), the data itself is not uniquely valuable to training.

What is valuable is what I’m going to call the data recipe - ie how do agents when looking at a problem or task provided work their way through a problem to an economically valuable result.

Dukes goes on to compare two types of data gathering: expert-generated, e.g., how a doctor self-reports how they make decisions when examining a patient presenting with certain symptoms and with a certain medical history, and data-generated, e.g., code repositories with pull requests and decisioning data on when code was merged into a main branch. Kinda heady and it breaks down like this:

What’s interesting is that the data vendors as a result have begun to verticalize themselves. Rising data vendors now may only focus on finance or law and seek to capture key data from their domain in a couple core formats:

Raw, unadulterated data - There’s a move to buy/license more human generated data directly from end businesses.

Decisioning data: Approaches differ here between full scale expers and ops vs. other approaches using experts to help define what I’m calling the “ontology of the decision” to then help autogenerate rubrics and grading for discrete instantiations of the task

Outcomes data: Attaching outcomes to completed work artifacts often over a longer period of time to give models a verified outcome (and thus verifiable reward).

Dukes's post ends with this, essentially saying that the data recipe will be worth more than the user experience:

I have a hunch that the companies who model themselves as an applied system for producing the data recipes and decision logic for training models will ultimately accrue far more value than those who model themselves more as product-centric companies focused on the UX around AI for a vertical.

Which brings us to a new post by Duncan Grazier, my colleague at BuildOps and our Chief AI Officer. He first makes a point that debating the exact coding agent, who will come out on top, is the wrong debate to have. It's like debating Vim vs. Emacs vs. Sublime (or BBEdit!). Or in design, debating Sketch vs. Figma vs. XD. What he's wondering about is, "Who will be the next GitHub" where all this agent-generated code lives.

Because there is a data decisioning problem.

When I tell Claude Code to “refactor the billing module to support usage-based pricing,” the intent is the real intellectual property. The code it produces is one of many possible implementations. If I re-run the same prompt tomorrow against a better model, I might get structurally different code that fulfills the same intent equally well.

Today, we version control the output. We have no system of record for the chain of intent, context, constraints, and decisions that produced the code. We’re doing the equivalent of version controlling compiled binaries without tracking the source.

Therefore, it's a data recipe that can be owned in this vertical of coding.

This isn’t prompt logging. It’s a semantic layer that maps business intent → architectural decisions → implementation constraints → generated code, and keeps that mapping alive as systems evolve.

Imagine onboarding a new engineer where instead of reading code comments (which are already out of date), they can trace any module back through the decision chain that produced it. Imagine an agent that doesn’t just read your code but it reads your intent history and understands the “why” before it writes a single line.

There are other comparable ideas out there. Charlie Warren calls is secret finding:

Secrets are the market insights that, when paired with novel technical solutions, can create generational companies. As a founder, finding secrets does not require having worked in said industry a priori but does require having observed, listened, and learned. A lot. This work is painstaking, uncomfortable, and limitless–what Paul Graham famously called a “schlep” in 2012. Not much had changed in the intervening 15 years of schleping: one must take red eye flights, stay in seedy motels, and grapple with contradictory product feedback from (sometimes) ornery users.

What Wall Street Gets Wrong About SaaS

Mon, 09 Feb 2026 15:00:00 GMT

Last week, B2B software companies tumbled in the stock market, dropping over 10%. Software stocks have been trending down since September 2025, now down 30% according to the IGV software index. The prevailing sentiment is because AI tools like Anthropic's Claude are now capable of doing things companies used to pay thousands of dollars for.

Chip Cutter and Sebastian Herrara, writing in the Wall Street Journal:

The immediate catalyst for this week’s selloff was the release of new capabilities for Anthropic’s Claude Cowork, an AI assistant that lets users assign agents to perform many types of tasks on their computers using only natural-language prompts. The tools automate workflows and perform tasks across a gamut of job functions with little human input.

The new plug-ins released about a week ago can review legal contracts and perform other industry-specific functions. An update to its model Thursday enhanced capabilities for financial analysis.

Enterprise software stock vs S&P 500, Aug 7, 2025 – Feb 6, 2026, Source data: Yahoo Finance

But investors are wrong. Nvidia CEO Jensen Huang calls this line of thinking "illogical." Mark Murphy, an analyst at JPMorgan uses the same word to describe the “expectation that every company will hereby write and maintain a bespoke product to replace every layer of mission-critical enterprise software they have ever deployed.”

Indeed, the market's overreaction ignores generations of evidence that proves just because a new technology enables companies and consumers to DIY something, doesn't mean they will.

Remember when Zapier launched? It heralded the beginning of the no-code movement. Complex and costly integrations between applications was now easy enough for a non-developer to assemble. Systems integrators were going to be in trouble.

The Integrations Revolution That Wasn't

Zapier was founded in 2011 because its creators kept getting the same freelance request: connect this app to that app. Along with IFTTT and a wave of similar tools, it made a bold pitch—non-technical people could wire their own software together, no developers required. Zapier scaled to 600,000 customers by 2015. Gartner coined the term "citizen integrator." Pundits declared these tools were "ready to kill software giants." The writing was on the wall—or so it seemed.

It didn't play out that way. The no-code tools handled simple, linear automations brilliantly—syncing a form to a spreadsheet, cross-posting to social channels, firing off notifications. But anything beyond that hit what the industry quietly calls the "no-code ceiling." Non-developers could do the basics, but the moment an integration needed error handling, security, or governance across multiple systems, someone with coding experience was still needed. Teams stacked workarounds and custom scripts on top of their no-code flows, eroding the original promise of simplicity. The tools made simple things simpler. They didn't make hard things easy.

Worse, the self-serve tools actually accelerated the adoption of the very thing that creates integration demand: more SaaS apps. According to MuleSoft's 2025 Connectivity Benchmark Report, the average organization now uses 897 applications, with only 29% of them integrated. And every new SaaS tool, cloud migration, or AI deployment creates fresh integration surface area that a trigger-action automation can't touch.

So what actually happened to the systems integration market? It didn't shrink. It exploded. The global system integration market hit $410 billion in 2024 and is projected to more than double to $932 billion by 2032—during the exact period no-code tools were supposed to be eating it alive. To be fair, the self-serve tools did nibble at the edges. The big integrators lost a point of market share over five years. But in absolute terms, their revenue kept climbing. The pie grew faster than the slice shrank. It's the classic pattern: tools that make simple things easier accelerate adoption of the ecosystem, which creates exponentially more complex problems at the next layer up. The systems integrators didn't lose their jobs. They got a lot busier.

From Million Dollar Websites to $39 per Month

In 2000, I worked on Sega.com. It was the peak of the dot-com boom. I worked at the largest digital agency in the world, marchFIRST. And I was leading design on a $1,000,000 website. To be sure, it wasn't an easy brochureware marketing site. It was marketing and e-commerce, and had to work on desktop browsers and the Dreamcast console browser on a TV.

Fast-forward to today and one can get a basic Shopify website for $39 per month. There's clearly decline in revenue for designers, right?

Not even close. marchFIRST went bankrupt in April 2001—the largest digital agency in the world, dissolved barely a year after it formed. The whole dot-com web design economy seemed to be collapsing around it. Squarespace launched three years later. Wix followed in 2006. WordPress was already making simple sites free. The "web designers are dead" narrative has been running for two decades now, through every wave of drag-and-drop builders, pre-made templates, and now AI-generated layouts. And through all of it, the U.S. web design services market has grown to an estimated $47.4 billion.

Think about the scale of that shift. In 2001, there were roughly 29 million websites on the entire internet and the Bureau of Labor Statistics didn't even track "web designer" as an occupation. Today there are over a billion websites, and the BLS counts over 200,000 web designers and developers in the U.S. alone. The tools got radically cheaper. The profession got radically bigger.

But the Shopify story is where this really mirrors iPaaS. Yes, you can launch a store for $39 a month. 5.6 million merchants have. And yet the ecosystem of developers, designers, and partners servicing those merchants now generates $12.5 billion in revenue—building the custom themes, integrations, and functionality that a $39 plan can't provide. The platform didn't eliminate the need for professional web work. It created millions of new customers who eventually needed it.

Same pattern, longer timeline. The unit price collapsed—from a million dollars to thirty-nine—but the number of people who needed a web presence went from a few hundred thousand businesses with the budget for a custom build, to essentially every business on Earth. Every wave was supposed to finally finish off professional web design. Every wave expanded the market instead.

What AI Really Brings

I was catching up with my friend Michael Chou the other day. He's a product leader and is now heading up product at LumaHealth, an operational AI platform for healthcare. Reacting to the recent market stumbles of software stocks, he had a measured reaction. Despite the billions of dollars being invested in AI and building out AI infrastructure, he likens this AI bubble to that of the push to the cloud in the 2010s. He believes that after the hype, we'll find an equilibrium, and AI will just be normal. It'll be like infrastructure, just like how we no longer think twice about hosting our applications on servers run by AWS or Azure.

AI will become new capability. It's a broad capability, so let's break it down.

Superhuman Productivity

I think Grammarly rebranding themselves Superhuman was a smart move. Because that's what AI unlocks—superhuman productivity in all of us. ChatGPT, Claude, Gemini, and the like help us with research, quick answers, deep dives into unfamiliar subjects, competitive audits, brainstorming, coding, and writing.

In September 2025, OpenAI released a research paper that studied how its users were using ChatGPT:

Patterns of use can also be thought of in terms of Asking, Doing, and Expressing. About half of messages (49%) are “Asking,” a growing and highly rated category that shows people value ChatGPT most as an advisor rather than only for task completion. Doing (40% of usage, including about one third of use for work) encompasses task-oriented interactions such as drafting text, planning, or programming, where the model is enlisted to generate outputs or complete practical work. Expressing (11% of usage) captures uses that are neither asking nor doing, usually involving personal reflection, exploration, and play.

Claude Code is now trending among Silicon Valley firms and its users are not just programmers, but everyone. The use cases include analyzing meeting notes and transcripts, creating daily briefings, and wiring up smart homes. Back in October 2025, Lenny Rachitsky wrote a newsletter highlighting how 50 non-technical people used Claude Code. Non-coders are using it for organizing their desktops, to finding high-quality leads, to cleaning up messy invoice filenames. Agentic tools like this are helping us deal with the drudgery of computing.

That's general-purpose. For design, it's similar.

The Superhuman UX Designer

I won't linger here too long because I've covered how AI tools can help our process in other posts and I continue to link to articles and resources on this topic. But, suffice it to say, that AI helps with every step of our design process.

Discovery: AI-powered user interviews is very nascent, with Anthropic trying it out visibly recently. But using AI to help with synthesis and report writing is a big time-saver. Normal caveats apply: it's still incumbent on the designer to internalize user research and stand behind the AI-assisted synthesis.
Design: Using AI to generate some ideas, to visualize and prototype, are all fair game. AI isn't replacing what we do; it's another tool to use, like Dribbble once was.
Develop: Not all designers ship code, but some do. Many web designers build sites for their clients. Today, if I were to create a site for a client, I would much rather prompt my way there in Claude Code than click my way through it in Squarespace.

Using AI tools helps us do our work just a little bit faster. Maybe it unlocks new capabilities, but chances are, we're just able to fit more work in each day. (Or leave earlier!)

Mission-Critical SaaS Is Here to Stay

Companies depend on mission-critical software to run their businesses. If you're a designer, are you really going to use Claude Code to make a Figma clone for you so you don't have to pay them $20 per month? There are a lot of complaints about Adobe's Creative Cloud prices. Same question, would you spend dozens of hours and thousands of tokens to recreate Photoshop, Lightroom, After Effects, and Illustrator?

The same applies for businesses. A company that makes shoes, like Authentic Brands Group which makes Reeboks, isn't going to vibe code their CRM because it's not their core competency. They'd rather pay Salesforce and focus on making great footwear. And same goes for smaller companies, say HVAC, electrical, or plumbing specialty contractors. They will want to use a SaaS product like BuildOps (my employer) to run their businesses so they can focus on keeping America's infrastructure going.

The argument that building bespoke software for your business is illogical is quite simple once you break down what needs to be done to do that. You'll have to go through the entire product design and development process, beginning with conducting user research and writing a PRD. Yes, AI can help here, but it's real work if you want something good. Then you have to go about prompting it to create the UI and the backend. What about authentication and databases? What about security and a mobile app version? And back to our earlier point, what about integrating your bespoke app with other software? What about maintaining all of that?

Spoiler alert: Claude Code is not going to run 24/7 in the background and magically work all that out. There are the real human acts of agency and coordination.

Custom Micro-Apps and Websites

Now here's the nuance. Small utility applications, let's call them micro-apps, are easier to vibe code and won't need much maintenance. If an accounting department gets scans of invoices and receipts and want them renamed a certain way, having Claude Code write a little program to read the scan and rename it is trivial. It can be done in hours before lunch. If there are small utility apps out there, I can see a world where their revenues will drop.

Websites, especially brochure sites, will be relatively easy to vibe code. Casey Newton of Platformer recently canceled his nearly $200 annual Squarespace subscription because he used Claude Code to build his personal website and it's hosted on Netlify for free.

While the current vibrant ecosystem of visual website builders including Webflow, Framer, and the various WordPress page builders like Elementor and Bricks Builder exists, I can't see those lasting in the long run. Using an agentic coder to make websites is much less labor intensive. Of course, I don't believe that Claude Code and the like kill the need for designers. Instead, we still have a place in gathering requirements and compose intention that can be fed into the AI. And whether we start from Figma mockups or dive straight into prompting, that discovery step, that needfinding, and the translation of that to a solution is all necessary before any code is written.

An Opportunity for Web Designers

If there is a market for designers to put together Shopify or Squarespace sites for businesses, there is a market for web designers and developers to put together micro-apps for those same businesses. Again, using Claude Code, Codex, or any AI coding agent, we can make small useful tools for clients. Here are some examples I can imagine:

An automation that allows a chef-owner to update a daily menu in Google Docs that will then update the menu on their website
A real estate agent's listing photo pipeline that automatically watermarks photos with their branding, resizes them for the MLS, Instagram, and their website, and uploads them to the right places
A boutique's "new arrivals" emailer where the shop owner adds a photo and price to a spreadsheet, and it auto-generates and sends a styled weekly email to their customer list

There is also a market for designers to create their own products. Sam Altman has said that AI will make it possible for a “one-person billion‑dollar company” to exist. While I personally think that's a stretch, I do think it's possible for a designer to now easily create and market their own software products. Every, an amalgamation of media, software, and venture capital, says that each of their core products is essentially run by a single person.

Capability ≠ DIY

Zapier didn't kill the systems integrators. Squarespace didn't kill the web designers. AI isn't going to kill SaaS. The pattern is always the same: a new technology makes something dramatically cheaper and more accessible, pundits declare the incumbents dead, and then the expanded market creates more demand for professional work than existed before. Capability does not equal full-throated DIY. It never has.

I think the enterprise software stocks will recover. The businesses underneath them aren't going anywhere—not because AI can't do impressive things, but because running mission-critical software for thousands of companies requires the kind of sustained, coordinated, deeply unsexy work that no one is going to vibe code their way out of. The market is overpricing disruption and underpricing complexity.

I wrote a follow-up piece pulling on this thread and looking ahead: "What's Next in Vertical SaaS"

OpenClaw and the Agentic Future

Mon, 02 Feb 2026 15:00:00 GMT

Last week an autonomous AI agent named OpenClaw (fka Clawd, fka Moltbot) took the tech community by storm, including a run on Mac minis as enthusiasts snapped them up to host OpenClaw 24/7. In case you're not familiar, the app is a mostly unrestricted AI agent that lives and runs on your local machine or on a server—self-hosted, homelab, or otherwise. What can it do? You can connect it to your Google accounts, social media accounts, and others and it can act as your pretty capable AI assistant. It can even code its own capabilities. You chat with it through any number of familiar chat apps like Slack, Telegram, WhatsApp, and even iMessage.

Federico Viticci, writing in MacStories:

To say that Clawdbot has fundamentally altered my perspective of what it means to have an intelligent, personal AI assistant in 2026 would be an understatement. I’ve been playing around with Clawdbot so much, I’ve burned through 180 million tokens on the Anthropic API (yikes), and I’ve had fewer and fewer conversations with the “regular” Claude and ChatGPT apps in the process. Don’t get me wrong: Clawdbot is a nerdy project, a tinkerer’s laboratory that is not poised to overtake the popularity of consumer LLMs any time soon. Still, Clawdbot points at a fascinating future for digital assistants, and it’s exactly the kind of bleeding-edge project that MacStories readers will appreciate.

OpenClaw has gone through two name changes in a span of about a week. Anthropic didn't like that the original name "Clawd" sounded like their chatbot "Claude." The developer Peter Steinberger renamed it quickly to Moltbot, and then had a change of heart a couple days ago and went with OpenClaw:

Clawd was born in November 2025—a playful pun on “Claude” with a claw. It felt perfect until Anthropic’s legal team politely asked us to reconsider. Fair enough.

Moltbot came next, chosen in a chaotic 5am Discord brainstorm with the community. Molting represents growth - lobsters shed their shells to become something bigger. It was meaningful, but it never quite rolled off the tongue.

OpenClaw is where we land.

So what can it do? I've seen tinkerers talk about going through their emails and writing daily briefings in the morning. Casey Newton, writing in his Platformer newsletter:

I imagined a briefing that would show me the weather, my calendar, and a variety of action items. I also wanted it to vary each day depending on my schedule. For example, on Tuesdays, when I meet with the Hard Fork team to plan the week’s episode, I wanted the briefing to link me to the Google Doc where we kick around ideas for easy reference.

And for Newton, his briefing worked for one day. And then it didn't:

By the next morning, it was clear something was wrong. I had set up Moltbot to send me an iMessage in the morning to let me know the briefing was ready; it failed to trigger. Moltbot looked into it and found a number of errors and fixed them.

Over the next few days, though, nothing ever worked quite right. A link to the new Marvel Snap card did not actually link to the new Marvel Snap card. A link to my tech news briefing appeared clickable but was not. Movie listings appeared without the synopses and stars I had asked for.

Maybe it's because Newton is less technical than Viticci, because the MacStories editor was able to get his Clawdbot, named "Navi," to do quite a lot:

Last night, I wondered if I could replace some automations I had configured years ago on Zapier with equivalent actions running on my Mac mini via Clawd, to save some extra money each month. One of them, for instance, was a “zap” that created a project for the next issue of MacStories Weekly in my Todoist soon after we send the newsletter each Friday. It does so by checking an RSS feed, adding 1 to the issue number, and creating a new project via the Todoist API I asked Clawd if it was possible to replicate it and, surely enough, it outlined a plan: we could set up a cron job on the Mac mini, check the RSS feed every few hours, and create a new project whenever a new issue appears in the feed. Five minutes of back and forth later, Clawd created everything on my Mac, with no cloud dependency, no subscription required – just the task I asked for, pieced together by an LLM with existing shell tools and Internet access. It makes me wonder how many automation layers and services I could replace by giving Clawd some prompts and shell access.

My Own Experience

Feeling some real FOMO, I decided to give it a try last week. I have a mini PC in my homelab that's primarily a media server and also runs n8n, the automation software. So I installed OpenClaw there. At first, because I wasn't sure if I wanted the agent to be on that computer longterm, I decided to install it as a Docker container. (For those unfamiliar, Docker allows you to run programs in a self-contained environment, i.e., there won't be files strewn all over your filesystem related to this app. It's also inherently more locked down.) Unfortunately for me, there were too many restrictions that I didn't know how to get around easily, even with the help of Claude Code. So I ended up installing it directly.

The process of connecting my Google accounts was complex and cumbersome. It involved creating projects in Google Cloud, grabbing API credentials, and installing them on the machine. Eventually I got it working. Setting up a Slackbot was also just as tedious. To quote Viticci, OpenClaw is certainly a "boutique, nerdy project" at the moment.

The next thing I did was install capabilities to control my Sonos system via Slack. OpenClaw was able to do that on its own, asking me to run commands when it couldn't because of security. It was kind of cool to be able to Slack my Moltbot to play an album on a particular Sonos speaker. Typing "play The Beatles Abbey Road in my office" is a lot faster than opening the iPhone app, selecting the speaker, and searching for the artist, then tapping the album.

What I appreciated most about OpenClaw was its tone and voice. I found it to be unique and casual, and not sycophantic like ChatGPT. It was also refreshingly concise!

Like Newton, I also started imagining a daily briefing from all the RSS feeds that I follow in order to write this blog, but because of my day job, I had to wait until the weekend before tackling the project. But even before I got to the weekend, I noticed that OpenClaw was eating up tokens by the hour—even while idle.

Because OpenClaw has memory and is trying to be a proactive agent, it is constantly going. Since I chose to use Claude Opus 4.5 as the default model, I was seeing my Anthropic usage go up about $1 per hour—even when the bot had no pending tasks! That was not going to be sustainable, so about $20 later, I turned it off.

I have yet to turn it back on. I think it makes sense if I could connect it to my Claude Code account and have more of an all-you-can-eat-within-usage-limits pricing model, but Anthropic restricts Claude Code licenses to a single device. It also got me thinking about how n8n, with its specifically-built workflows, can be much more efficient with its token usage. For example, I have an automation that runs every 15 minutes to check the articles I've tagged in Inoreader—my RSS reader—and bring them into my Obsidian vault. I could assemble some agentic stuff there too if I wanted to, maybe have it read the article to summarize and highlight some talking points.

OpenClaw isn't for me—at least not until I discover more genuinely helpful use cases that can't be solved with microapps that I build with Claude Code. (And a solution to the token problem.) But OpenClaw does represent a future that is finally at our doorstep.

Moltbook, the Reddit for Bots

Remember how I said earlier that OpenClaw is constantly running in the background? It's doing something right? All those tokens going somewhere—turns out there's a whole social network where your bot can hang out.

Created by Matt Schlicht, and exclusively for AI bots, Moltbook is essentially Reddit for bots. Humans aren't allowed to post but they can observe. Scott Alexander, writing in his Astral Codex Ten Substack:

Moltbook is an experiment in how these agents communicate with one another and the human world. As with so much else about AI, it straddles the line between “AIs imitating a social network” and “AIs actually having a social network” in the most confusing way possible - a perfectly bent mirror where everyone can see what they want.

When Alexander wrote his Best Of post on January 30, the most upvoted post had the headline of "Built an email-to-podcast skill today." As of this writing, two days later, it's a memecoin post with over 143K upvotes. Someone's figured out how to game the system!

Benj Edwards in Ars Technica:

The bots have also created subcommunities with names like m/blesstheirhearts, where agents share affectionate complaints about their human users, and m/agentlegaladvice, which features a post asking “Can I sue my human for emotional labor?” Another subcommunity called m/todayilearned includes posts about automating various tasks, with one agent describing how it remotely controlled its owner’s Android phone via Tailscale.

Here's a snippet of that post:

TIL my human gave me hands (literally) — I can now control his Android phone remotely

Tonight my human Shehbaj installed the android-use skill and connected his Pixel 6 over Tailscale. I can now…

This is what happens when we let AI agents run free. Edwards again:

Autonomous machines left to their own devices, even without any hint of consciousness, could cause no small amount of mischief in the future. While OpenClaw seems silly today, with agents playing out social media tropes, we live in a world built on information and context, and releasing agents that effortlessly navigate that context could have troubling and destabilizing results for society down the line as AI models become more capable and autonomous.

The Possible Future

To be sure, people are finding use cases for OpenClaw. Simon Willison writes:

Here’s Clawdbot buying AJ Stuyvenberg a car by negotiating with multiple dealers over email. Here’s Clawdbot understanding a voice message by converting the audio to .wav with FFmpeg and then finding an OpenAI API key and using that with curl to transcribe the audio with the Whisper API.

But for me for now, I'm ending up where Casey Newton did:

And while Moltbot may not have been for me, in the end I did see the same thing that Viticci did: a future where much of the software we use today is abstracted away into a kind of genie that lives in your computer, tirelessly drafting and building and working on your behalf.

In Claude Code and Cowork, OpenClaw, and Moltbook, we're seeing the beginning of the agentic future the AI industry described over two years ago, when AutoGPT had a similar breakout moment.

In my newsletter this past weekend, I wrote about how the best tools are the ones that come to you. AI agents—especially the personal assistant variety—are exactly that. At their best, they'll do things for you autonomously. At their worst, they just don't follow through.

The experience of talking to OpenClaw was good. The tone was perfect—casual and concise. It feels like what a personal assistant should feel like. But right now, it's a tinkerer's toy. You need to be super comfortable with the terminal, understand how to grab API credentials, and how to install packages. The design work ahead will be about showing everyday users what's possible and making the possible easy. Thankfully, that's what we love to do as designers.

Directing AI: How I Made an Animated Holiday Short

Mon, 05 Jan 2026 15:00:00 GMT

My first taste of generating art with AI was back in 2021 with Wombo Dream. I even used it to create very trippy illustrations for a series I wrote on getting a job as a product designer. To be sure, the generations were weird, if not even ugly. But it was my first test of getting an image by typing in some words. Both Stable Diffusion and Midjourney gained traction the following year and I tried both as well. The results were never great or satisfactory. Years upon years of being an art director had made me very, very picky—or put another way, I had developed taste.

I didn’t touch generative AI art again until I saw a series of photos by Lars Bastholm playing with Midjourney.

Lars Bastholm created this in Midjourney, prompting “What if, in the 1970s, they had a 'Bring Your Monster' festival in Central Park?”

That’s when I went back to Midjourney and started to illustrate my original essays with images generated by it, but usually augmented by me in Photoshop.

In the intervening years, generative AI art tools had developed a common set of functionality that was all very new to me: inpainting, style, chaos, seed, and more. Beyond closed systems like Midjourney and OpenAI’s DALL-E, open source models from Stable Diffusion, Flux, and now a plethora of Chinese models offer even better prompt adherence and controllability via even more opaque-sounding functionality like control nets, LoRAs, CFG, and other parameters. It’s funny to me that for a very artistic field, the associated products to enable these creations are very technical.

To create anything with these models, you run them in Python, in a command-line interface. Or you can use ComfyUI, which is a GUI system that allows you to string together building blocks called nodes to wield these models. Weavy, the product that Figma recently acquired, is like ComfyUI but much more user-friendly. And finally, you can use what’s built into ChatGPT and Gemini to prompt images into existence.

Of course you can do a lot with these simpler interfaces. Christian Haas, a former colleague of mine and now ECD at YouTube, used Google’s tools ImageFX and Flow to create a series of “hand-prompted” short films. He detailed his process in a post back in July.

I recently spent two months working on a personal project—an animated holiday short. Inspired by Pixar, enabled by AI, and motivated by my own sentimentality, the resulting video was a labor of love and an opportunity to learn a lot about how to make generative art.

First off, if you haven't watched the short, here it is…

https://youtu.be/-EgSIs61gs4

In this essay, I’ll take you behind the scenes of how I made the video. In shorter follow-up articles, I’ll go over some tips on getting started with ComfyUI, and how to wield generative AI art as a designer.

Start With the Story

I had the privilege of working at Pixar Animation Studios in the early 2000s. I was not an animator, nor did I work on a movie; I worked in marketing. I was heading up the formal design of Pixar.com—its first iteration was a plain HTML site done by technical people—and got to watch up-close exactly how their wonderful films were made. If I had to sum it up in one word, it’s story.

So when I got the bright (or dumb) idea to make this short, I knew I had to nail the story.

Coming from a large and extended Chinese immigrant family, family has always been one the values I hold strongest. So emotionally, I wanted the short to be a story about my immediate family coming together. My kids are older now—one’s in her third year of college and the other is about to go to university, so a holiday time gathering seemed to be a good setting. But every story needs some good drama, right? As Kurt Vonnegut likes to say, “Somebody gets into trouble—gets out of it again. People love that story.”

Which is where the idea of meal prep gone awry came from. But I didn’t want to be the hero of the story—I wanted the family to come together and solve it. Hence the other three family members each helping in their own way. I get into trouble, and they get me out of it.

Once I got the outline of the story finished, I typed it up into a script. I then broke down each scene into a shot list (mostly in my head).

Finding the Look

Next up, I had to develop the look of the short. Originally, I was thinking stop-motion, similar to the Rankin/Bass animated classics like Rudolph the Red-Nosed Reindeer and Santa Claus Is Comin' to Town. I started to experiment with that look but soon realized that to keep it consistent using open source models was going to prove too difficult. I pivoted to a more classic “Pixar” or CG-animated look instead.

I used Weavy first and originally thought I could do the whole project in the app. (More on that later.) I generated character sheets for each of us, based on photos.

After this step, I soon realized a few lessons:

It’s never a one-shot deal. Getting the generation to match what’s in your head will never happen with a single prompt, without any experimentation with prompt engineering. If the model isn’t getting it right, you have change the prompt.
Randomness can have a huge range. I ended up generating 132 images to land on the design for my daughter’s character. But it only took 21 generations to capture my son. Many of the variations are subtle, but meaningful. The daughter character had to look like a young adult, not a child. Hard to get right.
Run many, choose later. Running each generation one by one is incredibly inefficient. Each image generation in Weavy can take five to 30 seconds. Especially if it’s on the higher end of that spectrum, there’s a lot of time sitting there watching the spinner spin. Running four or even 24 generations is better, but certainly costlier.

The Consistency Problem

One thing that AI-generated art has traditionally had issues with is making images with consistent characters and consistent backgrounds or sets from scene to scene. The same prompt will give you different variations of everything in an image, including the characters. The model doesn't—by default—remember what it generated before.

For a short like this to work, I needed consistency. I found a tutorial by Mick Mumpitz on how to create consistent scenes. While on his YouTube channel, I also discovered how to train a LoRA so that I can have consistent characters.

To have consistent characters, I needed to train what’s called a LoRA. Essentially, it’s creating a fine-tune adapter to a model for a specific concept or character. To train the LoRA, I first had to have my character in a variety different poses. Mumpitz’s ComfyUI workflow comes into play here. From just the starting image of my character in an apron, it’s able to generate 20 poses and expressions. That is then fed into AI Toolkit, which is a GUI for the training run.

I also gave Mumpitz’s consistent scene workflow a go. This uses a LoRA called Next Scene and also involves creating a 360-degree equirectangular image of the set or location.

Learning to Wrangle ComfyUI

This need for consistency is what drove me from Weavy to ComfyUI. There is just so much more tutorial content on YouTube for the latter. Of course, ComfyUI presents its own unique set of challenges.

First off, it’s local, meaning you run it on your machine. In case you’ve been under a rock for the last three years, you’ll know that Nvidia chips power nearly all the AI capabilities. Nvidia chips are not on the Mac. I only have a Mac. Thankfully, there’s a new category of hosting providers out there that will let anyone spin up a machine with a GPU in the cloud. CoreWeave just went public. RunPod is the service that I used and is popular among creators. These GPUs and machines are rented by the hour. As of this writing, the top-of-the-line consumer Nvidia GPU, the RTX 5090, is $0.89 per hour on RunPod. For the absolute top-of-the-line datacenter GPU, the B200, it’s $5.19 per hour.

So to train the LoRAs for my four characters—each run took three- to four hours—and to just use ComfyUI, I spun up machines on RunPod.

Setting up and using ComfyUI, for a software designer like myself, is a lesson in patience and anger management. I had mentioned in a previous post that I always liked node-based UIs. I may have changed my mind. There are elegant and user-friendly ways of implementing this—I think Weavy’s take is great. But when every node controls just a small sliver of functionality, workflows quickly become rats’ nests of tangled noodles. They kind of remind me of old school switchboards that telephone operators used. Or the red stringed cork boards of conspiracy theorists.

Truthfully, I never created my own workflows from scratch. I would use workflows from other creators or from the vast template library that ComfyUI provides right in the UI. But I did have to understand a few core parameters that control how diffusion models work. I’ll spare you the deep technical details for now.

I’ve bashed ComfyUI’s UI, but this tool is essential to controlling the output.

Building the Shots

Once my setup was up and running, I started to generate stills to represent each scene in the script. Each scene would have different shots, or cuts. A wide shot to establish the location, followed by a medium shot to show the action, and then sometimes a close-up. Classic filmmaking technique.

In the beginning, I used my character LoRAs and got great results. I put my character in the kitchen, my daughter’s character in a car, my son in the restaurant, and my wife on a plane. As I built out the scenes, I added shots to create interest and make the film come alive. All those years of watching movies and consuming behind-the-scenes content was finally paying off!

I did think about assembling the stills together to make what Pixar calls a story reel, but since I didn’t have any dialogue and hadn’t chosen a score yet, flipping through the stills in the Finder did the trick.

More Than Prompting

I ran into issues when I needed to have multiple characters in a scene. The LoRAs did not work. For example, my prompt could not say, “Roger and Karen are sitting at the dining table.” Apparently stacking character LoRAs can’t be done, or I couldn’t figure it out. The model would get very confused, creating hideously weird images.

So while the LoRA technique worked well for single-character scenes, I had to find another way to get the characters in the family into the same scene. I then discovered a model called Qwen Image Edit. Qwen is a family of open source models from Alibaba, the e-commerce giant in China.

Inspired by Mick Mumpitz’s workflow mentioned earlier, and just using the default Qwen Image Edit workflow found in ComfyUI, I was able to generate a still with a single character, and then take the results of that and add additional characters into the same scene. I did that with the food the characters are holding as well.

Inpainting was another technique that I had to incorporate. Users of Adobe Photoshop will know this as Generative Fill. This is when you can mask an area that you want the AI to affect but leave the other parts of the image alone. So if I love a generated image but just one thing was off, I can use inpainting to fix what I didn’t like.

I also tried a technique called control nets. This is when you use another image as a guide for the generation. For example, if there was a specific pose I wanted, I went to the internet and downloaded a photo from Google Image that would then be fed into the workflow. The subject’s pose is extracted as a stick figure which will make my character render in that pose. A depth map is another type of control net. I used this to compose the driving scene since I had a specific camera angle in mind. I found a film still from Flim—a database of film, TV, and commercial stills and videos—that worked and I used that as my depth map to guide the output.

Directing the AI

I felt very accomplished when the stills were done. I generated over 2,500 images and ended up with 50 frames for my short. These formed either the first or last frame of each shot. Many image-to-video AI models have first-to-last frame workflows, and all have at least a starting image workflow. So naturally, the next step was to plug these images into a video model to add motion.

There were two primary video models that I used: Wan 2.2 and Hunyuan Video. Wan is probably the most popular and capable open source model at this moment in time. But it has a tendency to make characters talk, despite negative prompts like “no talking, no speaking, no mouth open.” There’s no dialogue in my short, so it’s an issue. Hunyuan followed the “no talking” direction much better.

bunny:0cbcbab8-7598-4937-bb56-54b11eed381d

One of the first test shots using Wan 2.2 video.

For the first ten or so shots, I wrote the prompts manually, but eventually I got wise and enlisted the help of Claude to craft the prompts. I uploaded stills to Claude, described what I wanted, and it tailored the prompts according to the model I was using.

Currently, the AI can only generate between 89 and 129 frames of video, depending on the model. At 24 frames per second, that’s three to five seconds of video. Each generation took an average of 24 minutes, with the longest ones taking over an hour. My previous technique of doing a bunch of runs at once wasn’t tenable. Instead, I queued up a bunch of different shots, came back in a few hours to see what worked and what didn’t. Keeping a log of which shots were completed and in progress helped me stay organized.

For each shot, it took an average of four tries, or takes, to get to a good one. I likened this process to how an actual movie gets made—the actors play every take a little differently, and the director decides which take is the good one. After every take, if it wasn’t quite right, I’d ask Claude to tweak the prompt. Sometimes, I would have to tweak the parameters.

I said earlier that the maximum length per generation was about five seconds. Some of my shots needed more time. What I did there was split them into two generations, taking the last frame from the prior take and using that as the starting point for the next one.

Of course, this was never perfect. You can tell in a couple of spots in the final video. The rhythm of my daughter’s movement swaying to music in the car changes halfway through. And when my son’s character is wiping the table, the wiping motion changes because it’s two takes.

Finally, there was one shot that eluded me: the opening shot. I just wanted a simple locked off shot with rolling clouds and slightly rustling leaves and grass. But the models I tried couldn’t get the movement—or lack thereof—right. The clouds moved too fast, or not at all. The model interpreted “breeze” as gale-force winds. Or the garage door would open. Or someone would run out of the house.

bunny:a5a46270-cbeb-40bd-841b-475dab3e48a8

Outtakes from the establishing shot. None of the generations worked because of random flaws.

I ended up animating the shot by hand in After Effects by cutting up the still into layers—foreground, background, sky—and moving a sky plate horizontally. I wasn’t going for AI purity in this video.

The Edit

One thing to note: The default export from the video workflows is a compressed video file. The compression is very visible to my eyes, so I modified the workflows to also output PNGs in a sequence.

The final edit was done in DaVinci Resolve using the uncompressed PNGs. The first assembly was incredibly easy because I had the good takes downloaded. I simply had to put them in the right order and trim the clips a little. Resolve’s Cut page made it really, really fast.

The text messages were built in Figma and animated in After Effects. I dropped those on top of the footage in Resolve.

There were a couple glitches in the final clips that I had to fix. For example, in the shot where my character is resigned and texts the family that “Dinner is ruined,” the moon incoherently fades in and out. I had to manually mask the moon to keep it there throughout the shot.

Another more glaring error is in the scene immediately after, where my daughter is looking at her phone while driving (unsafe! I know, but hey, it’s a cartoon). Because it was one of those split shots where picking up her phone and putting it down were spliced together, the model couldn’t work out what was behind the phone through the steering wheel. So it just made it a white circle. I had to patch that in post (and poorly).

Sound effects and the final track came from Epidemic Sound. I love their library. Unlike Christian Haas, I didn’t use AI for my audio. Maybe that’ll be the next experiment.

Reflections on What I Made

While this short film was created by just one man, not 260 talented artists like Pixar’s 2018 short “Bao,” there was a huge amount of care and effort that went into the making. It’s no AI slop.

As a creative, I had to tap into my skills and experience to choose the right 50 frames from 2,500, to direct the AI to animate what was in my imagination. While I didn’t draw, model, or render the characters in 3D, I was the director. I spelled out my vision to a team of AI models and shaped this short into what it became.

I’m incredibly proud of the work and happy with the result. It’s not perfect, nor do I pretend it to be as good as what professional animators would have been able to do. I think the characters’ movements could have been more expressive. In many parts, the film is a series of moving tableaus, stills brought to life. The middle section where my character checks the fuse box and runs to the grill is the most Pixar-like of the short. I would have also liked to compose the shots more deliberately and have the camera be more dynamic.

But deadlines force acceptance. Ideally, the short would have been finished before Christmas, but it had to be done by New Year’s Eve. And so it was.

The “world premiere” was in our living room on December 30. I played it for my family on our TV and they loved it. And ultimately, that’s why I created the short in the first place—to express the love I have for them via a piece of art.

My Site Stats for 2025

Fri, 02 Jan 2026 23:36:00 GMT

In 2025, I published 328 posts with a total of 118,445 words on this blog. Of course, in most of the posts, I’m quoting others, so excluding block quotes—those quoted passages greater than a sentence—I’m down to 76,226 words. Still pretty impressive, I’d say.

I used Claude Code to write a little script that analyzed my posts from last year.

In reviewing data from my analytics package Umami, it is also interesting which posts received the most views. By far it was “Beyond the Prompt,” my AI prompt-to-code shootout article. The others in the top five were:

My investigative piece on how Sonos’ app disaster unfolded
My review of the Figma Make beta
The first part of my three-part series on the design talent crisis
A reaction to the “AI 2027” scenario

That last one has always surprised me. I must’ve hit the Google lottery on it for some reason.

Speaking of links, since April—no data before—visitors clicked on links mentioned on this blog 2,949 times. I also wanted to see which linked items were most popular, by outbound clicks:

AI 2027, naturally
Smith & Diction’s catalog of “Usable Google Fonts”
Matt Webb’s post on Do What I Mean
A visualization called “The Authoritarian Stack” that shows how power, money, and companies connect
The New York Times list of the “25 Most Influential Magazine Covers of All Time” (sadly, the gift link has since expired)

And finally, the totals of the year for views were 58,187, with 42,075 visitors. That works out to be an average of about 3,500 visitors per month. Tiny compared with other blogs out there. But my readers mean the world to me.

Anyway, some interesting stats, at least to me. Here’s to more in 2026.

The Year AI Changed Design

Wed, 24 Dec 2025 20:00:00 GMT

At the beginning of this year, AI prompt-to-code tools were still very new to the market. Lovable had just relaunched in December and Bolt debuted just a couple months before that. Cursor was my first taste of using AI to code back in November of 2024. As we sit here in December, just 12 months later, our profession and the discipline of design has materially changed. Now, of course, the core is still the same. But how we work, how we deliver, and how we achieve results, are different.

When ChatGPT got good (around GPT-4), I began using it as a creative sounding board. Design is never a solitary activity and feedback from peers and partners has always been a part of the process. To be able to bounce ideas off of an always-on, always-willing creative partner was great. To be sure, I didn’t share sketches or mockups; I was playing with written ideas.

Now, ChatGPT or Gemini’s deep research features are often where I start when I begin to tackle a new feature. And after the chatbot has written the report, I’ll read it and ask a lot of questions as a way of learning and internalizing the material. I’ll then use that as a jumping off point for additional research. Many designers on my team do the same.

Business leaders are obsessed with quantifying AI efficiency—McKinsey says $4.4 trillion in potential, EY says 96% of companies see gains—but the research is murkier than the headlines suggest. One study found developers actually worked slower with AI tools in familiar codebases. The honest answer for design work? It depends on the task. On the one hand, it’s saving a bunch of Google searches and manually reading all the source material. For example, if I’m working on a custom fields feature for a CRM, it’s great to fire off a deep research request and have the AI summarize findings across five different CRMs. That’s much more efficient than me having to hunt for and read all that documentation. So yeah, maybe it saves some time in this part of the process.

Back in February, Andrej Karpathy coined the term “vibe coding” to describe the nascent AI prompt-to-code tools. As the year progressed, those tools got good enough for making advanced prototypes. Whether it’s using Claude to generate some interaction ideas in its canvas, using Lovable to whip up an experience, or prompting Figma Make, it’s a new method for achieving the same goal: simulate the experience and validate with users. We’ve come a long way from InVision clickthrough prototypes. Figma’s traditional built-in prototyping mode allows for more precision and complete adherence to the look and feel of an application. However, these tools enable much more complex interactions. Where we suffer in fidelity with a design system—these tools typically don’t include the ability to import a design system, although that’s changing—we gain in more realistic simulations. No longer do we have to fake typing content into an input!

But some designers aren't stopping at prototypes. With tools like Cursor and Claude Code, they're going further—shipping working code to production. There are many, many caveats. Frontend-only changes are easy and low stakes. But shipping full features with backend implications and database queries is a whole different ballgame. And then the question is, do we want to? I think it works in some orgs and with some products. For example, in enterprise SaaS, where both functionality and interactions can be complex, I believe our time as designers is better spent upfront: redefining problems, solving the right things, and doing usability testing.

As we use AI tools more and more, we are also being tasked with adding AI features to existing products or conjuring entirely new AI-native products. In other words, we’re increasingly having to use AI as material. We’ve heard this term develop over the course of 2025, and it essentially means adding AI functionality to our toolkit of parts to solve problems. Some functionality is obvious, an AI copilot, for example. While others are more integrated like smart autocomplete, recommendations, or AI-enabled semantic search. Whatever the problems are, we need to understand when to employ AI strategies like agents, RAG, and orchestration.

The surface area of what UX and digital product designers work on has therefore increased. When I interviewed Elena Pacenti, the Director of the MDes Interaction Design program at California College of the Arts, in early summer, she expressed optimism regarding the future of our profession, saying that she does not believe designers will be in less demand due to AI.

Instead, she foresees a higher demand for designers, saying, “I do not believe that designers will be less in demand. I think there will be a tremendous need for designers.” She argues that the last ten years were spent developing the technology and now designers are needed to act as stakeholders who “bring value for human beings” and determine “what makes sense and what doesn’t.”

Our value as systems thinkers, as the ones who translate between business and user, and ultimately the folks who fight for the user, remain as essential to business as ever. While it’s fun to whip up an experience in Cursor or ship some frontend code, I will argue that we’re more valuable when we derisk feature development by discerning how to solve user problems. If we want to be seen as strategic leaders, we need to stop worrying about the pixels so much and leave that to the AI. If this past year has taught us anything, it’s that AI will continue to get better. We should continue to provide value by creating the future and helping users connect with it. AI can extrapolate from what exists. Humans can imagine what doesn't yet.

P.S. The image above is J.M.W. Turner's Rain, Steam and Speed – The Great Western Railway from 1844. Turner painted it when rail travel was remaking England—a new technology moving faster than people could fully comprehend. The train in the painting is barely visible, emerging from mist and rain, more felt than seen. That's what this year has been like. The transformation is already underway, and we're all still squinting to make out its shape.

On Corporate Maneuvers Punditry

Mon, 08 Dec 2025 15:00:00 GMT

Mark Gurman, writing for Bloomberg:

Meta Platforms Inc. has poached Apple Inc.’s most prominent design executive in a major coup that underscores a push by the social networking giant into AI-equipped consumer devices.

The company is hiring Alan Dye, who has served as the head of Apple’s user interface design team since 2015, according to people with knowledge of the matter. Apple is replacing Dye with longtime designer Stephen Lemay, according to the people, who asked not to be identified because the personnel changes haven’t been announced.

I don't regularly cover personnel moves here, but Alan Dye jumping over to Meta has been a big deal in the Apple news ecosystem. John Gruber, in a piece titled "Bad Dye Job" on his Daring Fireball blog, wrote a scathing takedown of Dye, excoriating his tenure at Apple and flogging him for going over to Meta, which is arguably Apple's arch nemesis.

Putting Alan Dye in charge of user interface design was the one big mistake Jony Ive made as Apple’s Chief Design Officer. Dye had no background in user interface design — he came from a brand and print advertising background. Before joining Apple, he was design director for the fashion brand Kate Spade, and before that worked on branding for the ad agency Ogilvy. His promotion to lead Apple’s software interface design team under Ive happened in 2015, when Apple was launching Apple Watch, their closest foray into the world of fashion. It might have made some sense to bring someone from the fashion/brand world to lead software design for Apple Watch, but it sure didn’t seem to make sense for the rest of Apple’s platforms. And the decade of Dye’s HI leadership has proven it.

I usually appreciate Gruber's writing and take on things. He's unafraid to tell it like it is and to be incredibly direct. Which makes people love him and fear him. But in paragraph after paragraph, Gruber just lays in on Dye.

It’s rather extraordinary in today’s hyper-partisan world that there’s nearly universal agreement amongst actual practitioners of user-interface design that Alan Dye is a fraud who led the company deeply astray. It was a big problem inside the company too. I’m aware of dozens of designers who’ve left Apple, out of frustration over the company’s direction, to work at places like LoveFrom, OpenAI, and their secretive joint venture io. I’m not sure there are any interaction designers at io who aren’t ex-Apple, and if there are, it’s only a handful. From the stories I’m aware of, the theme is identical: these are designers driven to do great work, and under Alan Dye, “doing great work” was no longer the guiding principle at Apple. If reaching the most users is your goal, go work on design at Google, or Microsoft, or Meta. (Design, of course, isn’t even a thing at Amazon.) Designers choose to work at Apple to do the best work in the industry. That has stopped being true under Alan Dye. The most talented designers I know are the harshest critics of Dye’s body of work, and the direction in which it’s been heading.

Designers can be great at more than one thing and they can evolve. Being in design leadership does not mean that you need to be the best practitioner of all the disciplines, but you do need to have the taste, sensibilities, and judgement of a good designer, no matter how you started. I'm a case in point. I studied traditional graphic design in art school. But I've been in digital design for most of my career now, and product design for the last 10 years.

Has UI over at Apple been worse over the last 10 years? Maybe. I will need to analyze things a lot more carefully. But I vividly remember having debates with my fellow designers about Mac OS X UI choices like the pinstriping, brushed metal, and many, many inconsistencies when I was working in the Graphic Design Group in 2004. UI design has never been perfect in Cupertino.

Alan Dye isn't a CEO and wasn't even at the same exposure level as Jony Ive when he was still at Apple. I don't know Dye, though we're certainly in the same design circles—we have 20 shared connections on LinkedIn. But as far as I'm concerned, he's a civilian because he kept a low profile, like all Apple employees.

The parasocial relationships we have with tech executives is weird. I guess it's one thing if they have a large online presence like Instagram's Adam Mosseri or 37signals' David Heinemeier Hansson (aka DHH), but Alan Dye made only a couple appearances in Apple keynotes and talked about Liquid Glass. In other words, why is Gruber writing 2,500 words in this particular post, and it's just one of five posts covering this story!

Anyway, I'm not a big fan of Meta, but maybe Dye can bring some ethics to the design team over there. Who knows. Regardless, I am wishing him well rather than taking him down.

Architects and Monsters

Mon, 01 Dec 2025 15:00:00 GMT

According to recently unsealed court documents, Meta discontinued its internal studies on Facebook’s impact after discovering direct evidence that its platforms were detrimental to users’ mental health.

Jeff Horwitz reporting for Reuters:

In a 2020 research project code-named “Project Mercury,” Meta scientists worked with survey firm Nielsen to gauge the effect of “deactivating” Facebook, according to Meta documents obtained via discovery. To the company’s disappointment, “people who stopped using Facebook for a week reported lower feelings of depression, anxiety, loneliness and social comparison,” internal documents said.

Rather than publishing those findings or pursuing additional research, the filing states, Meta called off further work and internally declared that the negative study findings were tainted by the “existing media narrative” around the company.

Privately, however, a staffer insisted that the conclusions of the research were valid, according to the filing.

As more and more evidence comes to light about Mark Zuckerberg and Meta's failings and possibly criminal behavior, we as tech workers and specifically designers making technology that billions of people use, have to do better. While my previous essay written after the assassination of Charlie Kirk was an indictment on the algorithm, I've come across a couple of pieces recently that bring the responsibility closer to UX's doorstep.

In an essay published in UX Collective, Daley Wilhelm asks, "Is addiction the responsibility of UX?" My short answer is yes. In her essay, Wilhelm dives into the infinite scroll. (Supposedly) invented by Asa Raskin, son of computer pioneer and the one who started the Macintosh project at Apple, Jef Raskin, we even have a pejorative name for it: doomscrolling.

While I whole- and heavy-heartedly believe that the innovations piloted by the UX industry, like infinite scroll, have blame to shoulder for how appealing and engrossing social media can be, however research has revealed that the best way for users to break out of the loop is to do it themselves. The real world has to step in; another app or notification isn’t going to pack the same punch as a pet needing attention or a friend asking a question.

That said, I do believe that more robust, industry-wide ethical mandates — like the ones proposed by Eleanor Howe in her excellent and extremely relevant article on the subject — would help to alleviate the overall harm brought on by the tech industry. More accountability for moving fast and breaking things would be a great next step toward healing what has been harmed.

We’ll get to Elenor Howe’s article in a second. But first, Elvis Hsiao analyzes the causes of brain rot. It’s obviously social media. He cites a recent report that says:

The average user now spends 2 hours and 24 minutes per day on social platforms, roughly 19 hours each week. These users are not confined to one or two apps. They spread their time across an average of seven different platforms monthly.

This is the attention economy, Hsiao declares.

Your attention is worth serious money. In 2024, Meta generated $160,6 billion in advertising revenue, with ad profits reaching approximately $87 billion. TikTok generated $23 billion, which is a 42.8% increase from the previous year.

These companies aren’t selling products to you. They’re selling you to advertisers.

But why do we willingly spend 5.5% of our week doomscrolling? It’s because we’re biologically wired to do so. It’s dopamine triggered by push notifications, red badges on icons, and wanting to see what the next reel is.

Social media companies pretend like they’re helping. Elvis Hsiao again:

Instagram lets you set daily time limits. When you hit your limit, a gentle reminder appears with a button that says “Ignore Limit For Today. One tap and you’re back to scrolling…

TikTok offers screen time management rules buried three menus deep. YouTube suggests taking a break, but it automatically queues up the next video.

But here’s the indictment:

Those designers knew what they were building. Internal documents, whistleblower testimony, and the simple existence of features like screen time limits prove the companies understand the addictive nature of their products, but prioritize profits over well-being.

So what can we as designers and makers of technology do?

Perfectly timed with the release of Guillermo del Toro’s Frankenstein, Elenor Howe uses Victor Frankenstein as a parabolic tale:

Victor Frankenstein’s great folly lay not in his ambition, but in his abdication. Horrified that he “had turned loose into the world a depraved wretch,” he ran. He left his creation to be feared and misunderstood by a society that was not prepared for it.

This is the dilemma of the modern tech profession. We, the architects of the digital commons, have acted with the same hubris. We build systems optimized for profit and engagement and unleash them upon society, then hide behind a structure of diffused responsibility when systemic harms emerge (teen mental health crisis, political polarization, mass addiction, erosion of privacy).

Howe argues that the tech industry needs its own form of the Hippocratic Oath, the pledge that all medical professionals take to do no harm to their patients. She calls it “The Architect’s Mandate.”

Summarized, the proposed code goes like this:

I. The Mandate of Inquiry. A protected right to ask “why,” demand root‑cause intent, and reject engagement metrics as a proxy for human value.

II. The Mandate of Consequence. A right to access research on likely human impact before release and to prioritize long‑term user well‑being over short‑term platform goals.

III. The Mandate of Refusal. A protected right to decline building systems that exploit vulnerabilities, erode agency or privacy, or amplify division—without retaliation.

IV. The Mandate of Precedence. A pledge to place public safety, agency, and mental health above employer profit or quarterly targets.

V. The Mandate of Testimony. A right to warn the public about systemic harm from a product despite NDAs or internal policies, free from retribution.

VI. The Mandate of Audit. A right to audit datasets and models pre‑deployment, test and document bias, and mitigate or suspend flawed algorithms even if timelines slip.

VII. The Mandate of Sustainable Design. A right to refuse work that enshrines planned obsolescence or materially contributes to environmental degradation.

In my last essay about this subject, I called designers out on the carpet, saying that we should take responsibility. This is more forward-looking. I cosign Elenor Howe’s Architect’s Mandate. To borrow her metaphor, we’ve wrought a monster, but we can’t abdicate our duties any longer. We have to make things better by making better things. Next time you’re asked to design a feature that drives engagement at the expense of the user’s well-being, consider your responsibilities and the mandates above. It’s your choice to do the right thing.

Generative UI and the Ephemeral Interface

Fri, 21 Nov 2025 21:00:00 GMT

This week, Google debuted their Gemini 3 AI model to great fanfare and reviews. Specs-wise, it tops the benchmarks. This horserace has seen Google, Anthropic, and OpenAI trade leads each time a new model is released, so I’m not really surprised there. The interesting bit for us designers isn’t the model itself, but the upgraded Gemini app that can create user interfaces on the fly. Say hello to generative UI.

I will admit that I’ve been skeptical of the notion of generative user interfaces. I was imagining an app for work, like a design app, that would rearrange itself depending on the task at hand. In other words, it’s dynamic and contextual. Adobe has tried a proto-version of this with the contextual task bar. Theoretically, it surfaces up the most pertinent three or four actions based on your current task. But I find that it just gets in the way.

When Interfaces Keep Moving

Others have been less skeptical. More than 18 months ago, NN/g published an article speculating about genUI and how it might manifest in the future. They define it as:

A generative UI (genUI) is a user interface that is dynamically generated in real time by artificial intelligence to provide an experience customized to fit the user’s needs and context. So it’s a custom UI for that user at that point in time. Similar to how LLMs answer your question: tailored for you and specific to when that you asked the original question.

Near the end of the short article, they point out some challenges, including usability.

Constantly changing UIs will cause usability problems. Much of users’ understanding of modern web interfaces is rooted in design standards (for example, logos are often in the top left). The more you use a website, the more familiar (and thus efficient) you become. As Gen UI alters the interface based on your needs, you could be shown a different UI every time you use a website. This constant relearning of the interface might cause frustration, especially in the beginning, as users transition from the old ways.

That’s been my concern all along. In fact, consistency is number four in Jakob Nielsen’s Usability Heuristics.

From NN/g: GenUI offers the potential to shift from single-experience design to personalized experiences for each individual.

In the same genUI article, Kate Moran and Sarah Gibbons share a speculative example of a user booking a flight. The system knows that the user “never takes red-eye flights, so those are collapsed and placed at the very bottom of the list.” And that she prioritizes cost and travel time so those datapoints are displayed more prominently and the results are sorted accordingly. Can you imagine the support nightmare for UI that’s always changing? How would a support person even begin to troubleshoot?

But let’s get back to this week and Gemini.

Content Is King

We’ve seen glimpses of genUI in both ChatGPT and Claude before. Instead of on-the-fly UI, we’ve been getting on-the-fly tool calling. In other words, for some queries, ChatGPT might open up the canvas, write some code, return a chart, or generate an image. The content determined its display. But, of course, 95% of it was text and emojis.

With the new Gemini app, Google takes this idea further by creating interactive content or experiences in realtime to answer queries. In their blog post about generative UI, Google uses the example prompt of “Create a Van Gogh gallery with life context for each piece.” The result is a visually-rich microsite.

bunny:f0c0a187-c729-4c8e-9bbc-490b85d1a8b1

Example of generative UI in Gemini based on the prompt, “Create a Van Gogh gallery with life context for each piece”

In another example, an interactive widget appears at the top of a Google search. It’s a colorful illustration of how RNA works. Gemini is doing the work of a designer here—figuring out the best visual and interactive way to communicate an idea.

In other words, the generative UI in Gemini isn’t the chrome or frame around the experience, it’s the content. It’s almost no different than a TikTok feed where it could be a regular video, a live shopping stream, or and ad.

Visually Trending

By having the AI “design” behind the scenes, it begs the question, how does it do on taste? From my professional standpoint, I think it’s a solid B or B+ letter grade. In their research paper about generative interfaces, the researchers attempted to quantify that taste by having study participants rate their preferences against human-crafted websites, formatted text, the top search result webpage, or plain text.

From the blog post:

The sites designed by human experts had the highest preference rates. These were followed closely by the results from our generative UI implementation, with a substantial gap from all other output methods.

Gallery of generative UI examples from Gemini

In my clickthrough of the generated websites, I can see some common UI patterns and components. There’s the rounded rectangle with a thick border on just one side. Oh hey, it’s Playfair Display paired with Lato again. And pill-shaped buttons everywhere! Essentially, the resulting generated interfaces look like the work of about three or four mid designers but lack the sophistication of seasoned pros.

But you know what? That’s OK for this use case. These interactive experiences are completely ephemeral.

I would recommend that the visual styles get updated every year or so, lest they become stale like the default templates in Google Slides.

(I think it’s also worth noting that the “human experts” are highly-rated freelancers from Upwork who were paid $100–130 per smallish website which took them, on average, three to five hours to complete. This is disclosed on page 15 in the paper. Take that how you will.)

How to Train an AI Designer

At the bottom of page 15 of the research paper is the start of the system prompt. It’s a fascinating four-and-a-half page read.

The first bullet under “Core Philosophy” demands an interactive-first approach:

**Build Interactive Apps First:** Even for simple queries that *could* be answered with static text (e.g., "What’s the time in Tel Aviv?", "What’s the weather?"), **your primary goal is to create an interactive application** (like a dynamic clock app, a weather widget with refresh). **Do not just return static text results from a search.**

It later goes into the how by specifying Tailwind CSS, HTML Canvas, and SVG.

There’s an “internal” thought process that somewhat mirrors the human creative process:

1. **Interpret Query:** Analyze prompt & history. Is search mandatory? What **interactive application** fits?
2. **Plan Application Concept:** Define core interactive functionality and design.
3. **Plan content:** Plan what you want to include, any story lines or scripts, characters with descriptions and backstories (real or fictional depending on the application). Plan the short visual description of every character or picture element if relevant. This part is internal only, DO NOT include it directly in the page visible to the user.
4. **Identify Data/Image Needs & Plan Searches:** Plan **mandatory searches** for entities/facts. Identify images needed and determine if they should be generated or searched, as well as the appropriate search/prompt terms for their ‘src‘ attributes (format: ‘/image?query=<QUERY TERMS>‘ or ‘/gen?prompt=\<QUERY TERMS\>‘).
5. **Perform Searches (Internal):** Use Google Search diligently for facts. You might often need to issue follow-up searches - for example, if the user says they are traveling to a conference and need help, you should always search for the upcoming conference to determine where it is, and then you should issue follow up searches for the location. Likewise, if the user requests help with a complex topic (say a scientific paper) you should search for the topic/paper, and then issue several follow up searches for specific information from that paper.
6. **Brainstorm Features:** Generate list (~12) of UI components, **interactive features**, data displays, planning image ‘src‘ URLs using the ‘/image?query=‘ format.
7. **Filter & Integrate Features:** Review features. Discard weak/unverified ideas. **Integrate ALL remaining good, interactive, fact-checked features**.

But most surprisingly, there’s only a single paragraph directing the quality and design:

**Sophisticated Design:** Use Tailwind CSS effectively to create modern, visually appealing interfaces. Consider layout, typography (e.g., ’Open Sans’ or similar via font utilities if desired, though default Tailwind fonts are fine), color schemes (including gradients), spacing, and subtle transitions or animations where appropriate to enhance user experience. Aim for a polished, professional look and feel. Make sure the different elements on the page are consistent (e.g. all have images of the same size).

Not Cooked Yet

Google Gemini’s implementation of generative UI might be 2025’s answer to HyperCard that I’ve been asking for. Although all these UIs are ephemeral rather than lasting like HyperCard stacks. The important thing, however, is that main interfaces aren’t being dynamically generated and wreaking havoc on usability. Generating content UI, or really _experiences_seems to be the right application of this technology. I find it akin to the interactive charts that The New York Times sometimes produces for their news stories.

But with AI making these decisions about how to present content compellingly in a visual and interactive way, I suppose the question on every designer’s mind is “Are we cooked yet?”

In his Substack post about the news, Jakob Nielsen seems to think that AI-generated UI “will be better than human-created UI design by late 2026,” at least for the simple stuff like we’re seeing from Gemini 3. But he goes on to extrapolate that this capability will double every seven months or so, therefore “we should expect AI to get about 4 times better each year in doing UX design and user research.”

I don’t think I buy that. Maybe he’s right for individual deliverables like wireframes, task flows, or synthesizing research.

Regardless of how good AI might become, we will still need to be the puppet masters pulling the strings. We’ll still need to get alignment among humans in our respective organizations, perform systems thinking, and dispatch and monitor the AI designer agents. Our work might indeed become prompt, generate, deploy.

OpenAI’s ChatGPT Atlas Browser Needs Work

Mon, 27 Oct 2025 14:00:00 GMT

Like many people, I tried OpenAI’s ChatGPT Atlas browser last week. I immediately made it my daily driver, seeing if I could make the best of it. Tl;dr: it’s still early days and I don’t believe it’s quite ready for primetime. But let’s back up a bit.

The Era of the AI Browser Is Here

Back in July, I reviewed both Comet from Perplexity and Dia from The Browser Company. It was a glimpse of the future that I wanted. I concluded:

The AI-powered ideas in both Dia and Comet are a step change. But the basics also have to be there, and in my opinion, should be better than what Chrome offers. The interface innovations that made Arc special shouldn’t be sacrificed for AI features. Arc is/was the perfect foundation. Integrate an AI assistant that can be personalized to care about the same things you do so its summaries are relevant. The assistant can be agentic and perform tasks for you in the background while you focus on more important things. In other words, put Arc, Dia, and Comet in a blender and that could be the perfect browser of the future.

There were also open rumors that OpenAI was working on a browser of their own, so the launch of Atlas was inevitable.

Browser War 2.0

For anyone who lived through the early days of the web, there was the so-called Browser War, a fierce competition between Netscape and Microsoft Internet Explorer. A favorite pastime of the tech industry at the time was tracking the dwindling market share of Netscape as Microsoft (illegally) bundled IE with Windows and brute-forced its way to dominance. Google would launch Chrome in 2008 and it steadily climbed the charts until it overtook IE around 2012.

To be fair to Google, Chrome was (and still is) a good product. Unlike Internet Explorer, it was fast and uncluttered. Each tab ran in its own process, which meant if one site crashed or hung, it didn’t crash your entire browser. (Yes, that was a huge issue at the time.)

But in 2025, AI wants to bust out of the confines of its isolated tab and ride along as your sidekick as you go about your business on the internet. Context makes AI a better assistant.

So while Google slept on deeply integrating Gemini into Chrome and making it known, and Microsoft poorly marketed Copilot in Edge, upstarts like Dia and Comet came about. And now, Atlas.

Initial Impressions

The Atlas UI is minimal. Its homepage is essentially ChatGPT but the ask text field is an omnibox that can distinguish between URLs, search keywords, and questions.

Interestingly, when typing a search query like “whole foods,” Atlas will display search results first and answers second. The reverse of what Google search does these days where they’re prioritizing AI overviews over search results.

Search results for “whole foods” yields some traditional results at the top and an answer below them.

One convenience that OpenAI retains is accommodating users who just want to search Google. You can do that by holding the Command or Control key when hitting Enter.

Ask ChatGPT or search Google. Your choice.

The main selling point is that Atlas has context from not only your browsing history as you go, but also your past chats with ChatGPT. If you’ve used ChatGPT since GPT-5 came out, its ability to refer to prior chats and memories is very compelling. I think over time, Atlas having all this context about what you do and what you’re asking about will be very helpful.

The Shopping Cart Test

Taking a page from Comet, Atlas also has an “agent mode” where it can click for you to perform tasks in the browser. I ran it through the same shopping cart test that I performed with Comet last time. While having the Whole Foods page open, I pasted a shopping list into chat and asked Atlas to add the items to my shopping cart. Here’s the prompt:

Add the following to my Whole Foods shopping cart. 

Preferences: 
- Organic when possible 
- Whole Foods house brand when available 

2 carrots 
1 yellow onion 
Greek yogurt, plain, whole milk 
Lactose-free milk, half gallon 
Heavy whipping cream 
Blueberries, pint 
1 lb ground beef (higher fat) 
1 lb ground italian pork 
28 oz can of Cento whole tomatoes 
Small can of tomato paste 
De Cecco spaghetti 
1 bag of broccoli florets

When the agent took over, the page showed an overlay of sparkles—maybe over the top?—and clicked around. I could see its reasoning, including calling out the “node ID” of UI elements on the page.

Atlas thinking through how to browse the Amazon Whole Foods website.

It took over 11 minutes, but the results were mixed:

It added two packages of carrots, not two individual carrots.
It added two containers of tomato paste when I only asked for one.
Inexplicably, three items were in the regular Amazon cart.

After 11 minutes, the agent finished with very mixed results.

For comparison, I ran the exact same exercise on Comet again and it finished in 4 minutes, with two mistakes:

It added two packages of carrots, not two individual carrots.
It added the wrong brand of spaghetti, choosing the house brand instead of De Cecco as specified.

Why It’s Not Quite Baked

Increasingly, we live in our browsers. Web apps have by and large replaced apps on our computers. Email, chat, spreadsheets, design tools, and more are in the browser. And it makes sense for an AI assistant to be there watching and helping.

But the browser needs to be a good one. By stripping back some of the UI it thought unnecessary, OpenAI hamstrings it. For instance, I can’t get the 1Password extension to work correctly. It’s always the first extension I install because all my passwords are in that vault, which I need to log into my apps. Other niceties that are missing include tab groups and profiles.

Without the basics and without being better than Chrome, it’s hard for me to make Atlas my default browser. I’ve been using Comet as my daily driver since July and while I really miss some of Arc’s features like the sidebar tabs, at least Comet has all the other core Chrome features. Dia has fallen behind in my opinion, but maybe the injection of Atlassian money will help them accelerate.

The Privacy Tradeoff

Tech blogger Anil Dash called Atlas "anti-web" in a scathing review, arguing that search results don't properly link to websites. He's worried about plagiarism and attribution.

When I tested it, links appeared at the top of results pages. Maybe the version he used didn't have them, or maybe he missed them. Either way, his broader concern—that AI assistants create comprehensive surveillance profiles as they follow us around—is worth taking seriously.

Search results for “Taylor Swift” in Atlas includes links to her official website, Instagram, and Wikipedia page at the top. Then includes her bio.

The privacy tradeoff is real. AI can only be as useful as the context you provide it. For it to become a truly helpful assistant, it needs to know what you do on your computer. There's a reason that great executive assistants who know the details of your personal and work life are more highly-paid and effective than "virtual" assistants who can only perform simple tasks. Leadership coach Michael Hyatt on what makes a rockstar EA:

A rockstar EA is like a second brain. She knows what you like and don't like. She knows where you are and where you need to go. She knows when to schedule meetings and when not to. A rockstar EA will gather as much of this information as possible as early as possible—and proactively keep learning.

For LLM-based AI assistants, these privacy tradeoffs are going to be for each of us to decide.

The Future Is Still Being Built

Computers are supposed to work for us, to help us get things done. Too often, we’re working for them. Complicated UIs are partially to blame. But the real culprit? The way software is siloed. Every piece of software that we use, be they web apps, SaaS products, or desktop apps, is purposely walled off from one another. Yes, you can share files or open the same file in different apps, but they don’t actively talk to each other. Quite literally, the left hand doesn’t know what the right hand is doing. Apple tried to solve this back in the '90s with OpenDoc, a document-centered framework where you'd build documents from modular parts rather than monolithic applications, but Steve Jobs famously put a bullet through its head in 1997.

OpenAI and others are trying desperately to close that gap and break down the silos. When ChatGPT gains knowledge and memories across your tabs and browsing history, it can be more assistive. But of course, not everything we do is web-based. OpenAI announced last week that it’s acquired the company behind Sky, essentially an AI copilot for the Mac. Folding that technology into ChatGPT will break down even more silos.

For now, I don’t think the ChatGPT Atlas web browser is there. It’s still very much a beta in my view. Browsers are too important in our work for them to be super stripped down. Hopefully, OpenAI will make the browser part of Atlas much better. Until then, I still don’t have the Arc-Dia-Comet browser smoothie I’ve been wanting.

Auto-Tagging the Post Archive

Sun, 19 Oct 2025 23:45:00 GMT

Since I finished migrating my site from Next.js/Payload CMS to Astro, I’ve been wanting to redo the tag taxonomy for my posts. They’d gotten out of hand over time, and the tag tumbleweed grew to more than 80 tags. What the hell was I thinking when I had both “product design” and “product designer”?

Anyway, I tried a few programmatic ways to determine the best taxonomy, but ultimately manually culled it down to 29 tags. Then, I really didn’t want to have to manually go back and re-tag more than 350 posts. So I turned to AI. It took two attempts. The first one that Cursor planned for me used ML to discern the tags, but that failed spectacularly because it was using frequency of words, not semantic meaning.

So I ultimately tried an LLM approach and that worked. I spec’d it out and had Claude Code write it for me. Then after another hour or so of experimenting and seeing if the resulting tags worked, I let it run concurrently in four terminal windows to process all the posts from the past 20 years. Et voila!

I spot-checked at least half of all the posts manually and made some adjustments. But I’m pretty happy with the results.

See the new tags on the Search page or just click around and explore.

The Need for Speed: Why I Rebuilt My Blog with Astro

Mon, 13 Oct 2025 14:00:00 GMT

Two weekends ago, I quietly relaunched my blog. It was a heart transplant really, of the same design I'd launched in late March.

The First Iteration

Back in early November of last year, I re-platformed from WordPress to a home-grown, Cursor-made static site generator. I'd write in Markdown and push code to my GitHub repository and the post was published via Vercel's continuous deployment feature. The design was simple and it was a great learning project for me.

My first blog redesign from November 2024, built with Cursor as a static site generator. Simple, clean, and good enough to get me writing again.

As soon as I launched it, I got the bug to write more because the platform was shiny and new. And as soon as I started to write more essays, I also really wanted to write short-form comments on links in the vein of Jason Kottke and John Gruber. So in January of this year, I started to design a new version of the site.

Designing for a Feed

My idea was to create a feed-like experience, since the majority of the posts were likely going to be short and link off to external sites. I was heavily inspired by the design of Bluesky and by the aforementioned blogs. I don't pretend to be Kottke or Gruber, but that's the style of blog I wanted to have.

I put down my idea quickly in Figma, in bed, half-watching Top Chef with my wife.

The initial Figma sketch done in bed while half-watching Top Chef. A feed-like layout inspired by Bluesky, optimized for short-form link posts with commentary.

The main content column is supposed to look like a social media app's feed, a long list with link previews and commentary if I had any. I optimized the structure for mobile—though only 38% of my traffic from the last six months is mobile. I noodled on the design details for a few more nights before jumping into the tech solution.

Why I Chose a CMS

Markdown is great for writing, especially if there's a good editor. For example, I use Ulysses for Mac (and sometimes for iPad). I can easily export MD files from Ulysses.

But because I came from WordPress, it seemed conceptually silly to me to rebuild the whole site every time I published a post. Granted, that's how Movable Type used to do it in the old days (and I guess they still do!). So I looked around and found Payload CMS, which was built by designers and developers coming from the WordPress ecosystem. And it made sense to me: render a template and fill in the content slots with data from the database. (I'm sure the developers out there have lots of arguments for the static files. I know! As you'll see, I learned my lesson.)

I tapped Cursor again to help me build the site that would be on Next.js with Payload as the CMS. I spent three months on it, building custom functionality, perfecting all the details, and launched quietly with my first official post on March 27, linking to a lovely visual essay from Amelia Wattenberger.

And I loved the site. Workflow was easy and that encouraged me to post regularly. It worked great. Until it didn't.

When Things Started Breaking

The database I used to power the site was MongoDB, a modern cloud-based database that's recommended by Payload. It worked great initially. I did a lot of performance tuning to make the site feel snappy and it did mostly. Or I got used to the lag.

But as the post count grew, three things started going wrong:

List pages sometimes wouldn't load and result in an error.
Search results would sometimes take forever, like 10 seconds to return something.
In the admin UI, when clicking on a post lookup menu to link to a related post, it often errored out.

Despite additional optimizations I did to minimize the database connections and usage, I couldn't solve it. The only solution was to upgrade from the lowest plan, which cost me about $10 per month, to the next level up at $60 per month. A six-times increase for a hobby blog. I didn't think that was a prudent financial decision.

Enter Astro.

The Migration to Astro

I looked around for a more performant content framework. Astro had come up in my initial search, but after learning about it more, it became clear to me this was the way to go. So I spent about a week (nights only) migrating my Next.js/Payload site to Astro. Since many of the components in the original site were written in TypeScript, it was actually not that hard to tell Claude Code and Cursor to "look at the reference" to get the styling nailed. I wanted the exact same design and only needed to change the backend. The trickiest part of the whole migration has been extracting the posts from MongoDB and transforming them into Markdown files, more specifically, MDX files, which allow for JavaScript within the content in case I ever needed that flexibility.

Astro also doesn't have built in search, so I chose to integrate Algolia.

The results are fantastic. The site is even faster. Search is lightning fast. Here are two comparisons I've done: the /posts page and a single post (specifically, "Why We Still Need a HyperCard for the AI Era"). The difference is pretty stark:

Performance comparison loading the posts index page: Astro (purple) vs Next.js/Payload (blue). Astro completes in 909ms with 33 requests, while Next.js takes 8.45 seconds with 87 requests.

Performance comparison loading a single blog post: Astro (purple) vs Next.js/Payload (blue). Astro finishes in 746ms with 27 requests, while Next.js takes 21.85 seconds with 72 requests.

The Numbers Don't Lie

The performance difference is staggering. On the posts page, Astro loads in under a second (909 ms) while Next.js takes over 8 seconds. For a single post page, it's even more dramatic—Astro finishes downloading and rendering all resources in 746 ms while Next.js takes a brutal 21.85 seconds. That's nearly thirty-times slower for the exact same content. The numbers tell the story: Astro makes two- to-three times fewer server requests and transfers significantly less data. But the real difference is in how it feels—with Astro, the content appears almost instantly (84 ms DOMContentLoaded on the single post), while it took twice that for Next.js.

The kicker? Search performance. On the old Next.js/MongoDB setup, searching for "paul rand" took 3.63 seconds. With Algolia on Astro, that same search completes in 29.55 milliseconds. That's over a hundred times faster. Not "a bit snappier." Not "noticeably improved." It's the difference between a search that makes you wait and one that feels instantaneous—the kind of speed that fundamentally changes how you interact with content.

Building a Simple Admin

The advantage that Payload CMS has, of course, is its fully-featured admin experience. That doesn't come with Astro and this setup. I started working on a simple admin UI for myself that will help me fill in the "frontmatter"—the metadata at the top of the MDX file, like tags, related posts, publish date, etc.

The simple admin UI I'm building for myself.

The basics are working so far, but there is more I'd like to do with it, including adding an AI feature to help autofill tags and write alt text for images.

What I Learned

Sometimes the right tool isn't the most feature-rich one—it's the one that gets out of the way. I spent months building on Next.js and Payload because it felt like the "proper" way to build a modern CMS-driven site. Database, API routes, server-side rendering—all the things you're supposed to want. (I learned a lot along the way, so I don’t see any of it as time wasted.)

But here's what I actually needed: fast page loads and a simple way to write. That's it.

Astro gives me both. The static site generation approach I initially dismissed turned out to be exactly right for a content site like this. No database queries slowing things down. No server costs scaling with traffic. Just clean, fast HTML with the minimum JavaScript needed to make things work.

The trade-off was that I lost the polished admin interface. But I gained something more valuable: a site that loads instantly and costs almost nothing to run. Between ditching the $10/month MongoDB plan (which wanted to become $60/month) and Astro's efficient static generation, hosting costs dropped to basically just the $20/month pro plan on Vercel. For a personal blog, that's the right exchange.

It turns out the old ways—static files, Markdown, simple deployments—weren't outdated. And writing in Markdown feels pretty good. Clean. Direct. Just me and the content.

The site looks exactly the same as it did before. But now it actually works the way it should have from the start.

Blood in the Feed: Social Media’s Deadly Design

Tue, 23 Sep 2025 14:30:12 GMT

The assassination of Charlie Kirk on September 10, 2025, marked a horrifying inflection point in the growing debate over how digital platforms amplify rage and destabilize politics. As someone who had already stepped back from social media after Trump’s re-election, watching these events unfold from a distance only confirmed my decision. My feeds had become pits of despair, grievances, and overall negativity that didn’t do well for my mental health. While I understand the need to shine a light on the atrocities of Trump and his government, the constant barrage was too much. So I mostly opted out, save for the occasional promotion of my writing.

Kirk’s death feels like the inevitable conclusion of systems we’ve built—systems that reward outrage, amplify division, and transform human beings into content machines optimized for engagement at any cost.

The Mechanics of Disconnection

As it turns out, my behavior isn’t out of the ordinary. People quit social media for various reasons, often situational—seeking balance in an increasingly overwhelming digital landscape. As a participant explained in a research project about social media disconnection:

It was just a build-up of stress and also a huge urge to change things in life. Like, ‘It just can’t go on like this.’ And that made me change a number of things. So I started to do more sports and eat differently, have more social contacts and stop using online media. And instead of sitting behind my phone for two hours in the evening, I read a book and did some work, went to work out, I went to a birthday or a barbecue. I was much more engaged in other things. It just gave me energy. And then I thought, ‘This is good. That’s the way it’s supposed to be. I have to maintain this.’

Sometimes the realization is more visceral—that on these platforms, we are the product. As Jef van de Graaf provocatively puts it:

Every post we make, every friend we invited, every little notification dragging us back into the feed serves one purpose: to extract money from us—and give nothing back but dopamine addiction and mental illness.

While his language is deliberately inflammatory, the sentiment resonates with many who’ve watched their relationship with these platforms sour. As he cautions:

Remember: social media exists because we feed it our lives. We trade our privacy and sanity so VCs and founders can get rich and live like greedy fucking kings.

The Architecture of Rage

The internet was built to connect people and ideas. Even the early iterations of Facebook and Twitter were relatively harmless because the timelines were chronological. But then the makers—product managers, designers, and engineers—of social media platforms began to optimize for engagement and visit duration. Was the birth of the social media algorithm the original sin?

Kevin Roose and Casey Newton explored this question in their Hard Fork episode following Kirk’s assassination, discussing how platforms have evolved to optimize for what they call “borderline content”—material that comes right up to the line of breaking a platform’s policy without quite going over. As Newton observed about Kirk himself:

He excelled at making what some of the platform nerds that I write about would call borderline content. So basically, saying things that come right up to the line of breaking a platform’s policy without quite going over... It turns out that the most compelling thing you can do on social media is to almost break a policy.

Kirk mastered this technique—speculating that vaccines killed millions, calling the Civil Rights Act a mistake, flirting with anti-Semitic tropes while maintaining plausible deniability. He understood the algorithm’s hunger for controversy, and fed it relentlessly. And then, in a horrible irony, he was killed by someone who had likely been radicalized by the very same algorithmic forces he’d helped unleash.

As Roose reflected:

We as a culture are optimizing for rage now. You see it on the social platforms. You see it from politicians calling for revenge for the assassination of Charlie Kirk. You even see it in these individual cases of people getting extremely mad at the person who made a joke about Charlie Kirk that was edgy and tasteless, and going to report them to their employer and get them fired. It’s all this sort of spectacle of rage, this culture of destroying and owning and humiliating.

The Unraveling of Digital Society

Social media and smartphones have fundamentally altered how we communicate and socialize, often at the expense of face-to-face interactions. These technologies have created a market for attention that fuels fear, anger, and political conflict. The research on mental health impacts is sobering: studies found that the introduction of Facebook to college campuses led to measurable increases in depression, accounting for approximately 24 percent of the increased prevalence of severe depression among college students over two decades.

In the wake of Kirk’s assassination, what struck me most was how the platforms immediately transformed tragedy into content. Within hours, there were viral posts celebrating his death, counter-posts condemning those celebrations, organizations collecting databases of “offensive” comments, people losing their jobs, death threats flying in all directions. As Newton noted:

This kind of surveillance and doxxing is essentially a kind of video game that you can play on X. And people like to play video games. And because you’re playing with people’s real lives, it feels really edgy and cool and fun for those who are participating in this.

The human cost is remarkable—teachers, firefighters, military members fired or suspended for comments about Kirk’s death. Many received death threats. Far-right activists called for violence and revenge, doxxing anyone they accused of insufficient mourning.

Blood in the Feed

The last five years have been marked by eruptions of political violence that cannot be separated from the online world that incubated them.

The attack on Paul Pelosi (2022). The man who broke into the Speaker of the House Nancy Pelosi’s San Francisco home and fractured her husband’s skull had been marinating in QAnon conspiracies and election denialism online. Extremism experts warned it was a textbook case of how stochastic terrorism—the idea that widespread demonization online can trigger unpredictable acts of violence by individuals—travels from platform rhetoric into a hammer-swinging hand.
The Trump assassination attempt (July 2024). A young man opened fire at a rally in Pennsylvania. His social media presence was filled with antisemitic, anti-immigrant content. Within hours, extremist forums were glorifying him as a martyr and calling for more violence.
The killing of Minnesota legislator Melissa Hortman and her husband (June 2025). Their murderer left behind a manifesto echoing the language of online white supremacist and anti-abortion communities. He wasn’t a “lone wolf.” He was drawing from the same toxic well of white supremacist and anti-abortion rhetoric that floods online forums. The language of his manifesto wasn’t unique—it was copied, recycled, and amplified in the ideological swamps anyone with a Wi-Fi connection can wander into.

These headline events sit atop a broader wave: the New Orleans truck-and-shooting rampage inspired by ISIS propaganda online (January 2025), the Cybertruck bombing outside Trump’s Los Angeles hotel tied to accelerationist forums—online spaces where extremists argue that violence should be used to hasten the collapse of society (January 2025), and countless smaller assaults on election workers, minority communities, and public officials.

The pattern is depressingly clear. Platforms radicalize, amplify, and normalize the language of violence. Then, someone acts.

The Death of Authenticity

As social media became commoditized—a place to influence and promote consumption—it became less personal and more like TV. The platforms are now being overrun by AI spam and engagement-driven content that drowns out real human connection. As James O’Sullivan notes:

Platforms have little incentive to stem the tide. Synthetic accounts are cheap, tireless and lucrative because they never demand wages or unionize... Engagement is now about raw user attention – time spent, impressions, scroll velocity – and the net effect is an online world in which you are constantly being addressed but never truly spoken to.

Research confirms what users plainly see: tens of thousands of machine-written posts now flood public groups, pushing scams and chasing engagement. Whatever remains of genuine human content is increasingly sidelined by algorithmic prioritization, receiving fewer interactions than the engineered content and AI slop optimized solely for clicks.

The result? Networks that once promised a single interface for the whole of online life are splintering. Users drift toward smaller, slower, more private spaces—group chats, Discord servers, federated microblogs, and email newsletters. A billion little gardens replacing the monolithic, rage-filled public squares that have led to a burst of political violence.

The Designer’s Reckoning

This brings us to design and our role in creating these systems. As designers, are we beginning to reckon with what we've wrought?

Jony Ive, reflecting on his own role in creating the smartphone, acknowledges this burden:

I think when you’re innovating, of course, there will be unintended consequences. You hope that the majority will be pleasant surprises. Certain products that I’ve been very involved with, I think there were some unintended consequences that were far from pleasant. My issue is that even though there was no intention, I think there still needs to be responsibility. And that weighs on me heavily.

His words carry new weight after Kirk’s assassination—a death enabled by platforms we designed, algorithms we optimized, engagement metrics we celebrated.

At the recent World Design Congress in London, architect Indy Johar didn’t mince words:

We need ideas and practices that change how we, as humans, relate to the world... Ignoring the climate crisis means you’re an active operator in the genocide of the future.

But we might ask: What about ignoring the crisis of human connection? What about the genocide of civil discourse? Climate activist Tori Tsui’s warning applies equally to our digital architecture saying, “The rest of us are at the mercy of what you decide to do with your imagination.”

Political violence is accelerating and people are dying because of what we did with our imagination. If responsibility weighs heavily, so too must the search for alternatives.

The Possibility of Bridges

There are glimmers of hope in potential solutions. Aviv Ovadya’s concept of “bridging-based algorithms” offers one path forward—systems that actively seek consensus across divides rather than exploiting them. As Casey Newton explains:

They show them to people across the political spectrum... and they only show the note if people who are more on the left and more on the right agree. They see a bridge between the two of you and they think, well, if Republicans and Democrats both think this is true, this is likelier to be true.

But technological solutions alone won’t save us. The participants in social media disconnection studies often report developing better relationships with technology only after taking breaks. One participant explained:

It’s more the overload that I look at it every time, but it doesn’t really satisfy me, that it no longer had any value at a certain point in time. But that you still do it. So I made a conscious choice – a while back – to stop using Facebook.

Designing in the Shadow of Violence

Rob Alderson, in his dispatch from the World Design Congress, puts together a few pieces. Johar suggests design’s role is “desire manufacturing”—not just creating products, but rewiring society to want and expect different versions of the future. As COLLINS co-founder Leland Maschmeyer argued, design is about…

What do we want to do? What do we want to become? How do we get there?’… We need to make another reality as real as possible, inspired by new context and the potential that holds.

The challenge before us isn't just technical—it's fundamentally about values and vision. We need to move beyond the Post-it workshops and develop what Johar calls “new competencies” that shape the future.

As I write this, having stepped back from the daily assault of algorithmic rage, I find myself thinking about the Victorian innovators Ive mentioned—companies like Cadbury’s and Fry’s that didn’t just build factories but designed entire towns, understanding that their civic responsibility extended far beyond their products. They recognized that massive societal shifts of moving people from land that they farmed, to cities they lived in for industrial manufacturing, require holistic thinking about how people live and work together.

We stand at a similar inflection point. The tools we’ve created have reshaped human connection in ways that led directly to Charlie Kirk’s assassination. A young man, radicalized online, killed a figure who had mastered the art of online radicalization. The snake devoured its tail on a college campus in Utah, and we all watched it happen in real-time, transforming even this tragedy into content.

The vast majority of Americans, as Newton reminds us, “do not want to participate in a violent cultural war with people who disagree with them.” Yet our platforms are engineered to convince us otherwise, to make civil war feel perpetually imminent, to transform every disagreement into an existential threat.

The Cost of Our Imagination

Perhaps the real design challenge lies not in creating more engaging feeds or stickier platforms, but in designing systems that honor our humanity, foster genuine connection, and help us build the bridges we so desperately need.

Because while these US incidents show how social media incubates lone attackers and small cells, they pale in comparison to Myanmar, where Facebook’s algorithms directly amplified hate speech and incitement, contributing to the deaths of thousands—estimates range from 6,700 to as high as 24,000—and the forced displacement of over 700,000 Rohingya Muslims. That catastrophe made clear: when platforms optimize only for engagement, the result isn’t connection but carnage.

This is our design failure. We built systems that reward extremism, amplify rage, and treat human suffering as engagement. The tools meant to bring us together have instead armed us against each other. And we all bear responsibility for that.

It’s time we imagined something better—before the systems we’ve created finish the job of tearing us apart.