2026-10-09 22:00:00
After seeing lots of posts over the years arguing that design has become homogenized, I decided to pull together historical and modern designs for a few different product categories: TVs, phones, cars, etc. You don't have to squint to see the pattern... but why?
Do we eventually reach a final form? Does everything just trend toward average as mediocrity seeps in? Is it driven by what's possible or cost-effective in the supply chain? Or does everybody just copy everybody else? Here's the reasons I see people argue most often.
Once a product's purpose becomes clear, design can get out of the way. A TV is for watching a picture, so the ideal TV is mostly picture. Same for smartphones, cash registers, etc.
The more mature a technology, the more it competes on price and specs. Standing out is risky and expensive so less companies do it. The ones that do tend to be smaller so they have less resources and reach, making it hard to go beyond niche markets.
Nature does it too. Crustaceans keep independently evolving into crab-like shapes: a pattern we call carcinisation. Someone suggested the consumer product version should be called "crabitalism".
Aerodynamics, thermals, and materials push cars and planes toward the same shapes. Constraints do the same. Planes are designed around airports, and cars around safety standards. Change the job (an F1 car, a fighter jet) and the design changes with it.
Software is even more susceptible. Every app is already being chat-ified (video below) even though we're only a few years out from ChatGPT's release. Hardware convergence often took decades.
On that note, AI hardware is currently a bunch of experiments: pins, glasses, earbuds, and even pendants. We'll see which of them (if any) make it into the right-hand column, but for now it's a design playground.
2026-10-05 22:00:00
In today's AI-powered software, you manage agents, they manage more agents, and those agents manage even more agents. Chat threads break with that scale. We need to know what agents are planning, what they've already done, and how best to steer them. In other words we need different ways of seeing things.
When most people think about staying on top of agent activity, they jump to management views: an inbox like those found in Slack and email; a dashboard like those found in monitoring apps. Effectively these answer the question "what are my agents doing right now?"
I took a look at inboxes, Kanban boards, task lists, dashboards, and calendars in a post last year about agent management interface patterns. But while these kinds of agent views currently get all the attention, more specific and dynamic views may actually be more useful.
That's why in Intent, our large scale agent coordination tool for developers, we've built in multiple ways to see what's going on. Intent lets you create any number of documents (we call them notes) when working on a task, so you can have the specific views you need when you need them. A few examples:
Agents can draw architecture maps, flowcharts, sequence diagrams, and state machines inside notes and chats so you know what they are planning to do, and how, before spending the tokens.
Stepped walk-throughs move you through a diagram one stage at a time, each with a short explanation and the relevant parts highlighted. This not only makes plans easier to follow but also helps you quickly understand the current state of things. Boxes that reference files or notes open them when you click so can go deeper if needed.
Agents can take before and after screenshots of their UI changes and place them side by side in a note letting you judge results without reading any code. These notes can update with each change or stick around as a historical record. Agents in Intent can also pin a screenshot to show progress at a glance.
A app or website's design system can also be viewed as a note: colors, type styles, spacing, corner rounding, animation timings, and components with their variants, all in one place. Keeping a view like this open while you work makes "which padding?" one glance away. Agents read the same notes, so their UI work lines up with your references.
Of course, lots of views aren't much help if you can't set them up in a way that's useful. Every panel in Intent can hold a stack of agents, notes, files, terminals, and browser tabs. Drag things between panels, drop one on an edge to split off a new panel, and zoom any panel to full screen if you need focus.
Yes, chat still has a place for kicking off, moving along, and redirecting work. But as agents keep multiplying, a configurable workspace of useful views goes a long way toward steerings thing toward the outcomes you want.
2026-10-01 22:00:00
For as long as I've been working on design systems (20+ years, oof!), I've seen the same pattern play out... design teams invest a lot of time in creating a system, then struggle to keep it up to date as the actual product evolves. Inevitably the design system ends up describing a product that no longer exists.
The most common way to address this was to throw more resources at the problem: design system teams and/or centralized design reviews. But now, AI agents give design systems a different path forward. When agents write most of the code, the design system can become part of what I've called the AI steering layer: the context that keeps every website update aligned with brand, design, and development guidelines. Put simply, a design system for agents is a steering layer for a site's design and front-end code.
With AI agents, anyone on a team can update a website. Marketing adds landing pages, engineering adds docs, a PM tweaks the pricing page. Each of their agents will happily implement its own tone and voice, colors, spacing, etc. unless something steers them toward a unified whole.
That's the case for collaborative steering. A design lead and front-end lead define the grid, fonts, colors, spacing, and components once, and everyone's agents are "snapped to" it. The team keeps shipping and the site keeps its integrity. So what does that look like in practice? Here are a few examples from our recent projects.
On the Intent website, an AGENTS.md file tells AI agents to reuse the theme classes and CSS variables in the site's global stylesheet instead of duplicating color, typography, or grid values. That stylesheet defines colors, fonts, type sizes, the responsive grid, and light and dark themes as design tokens (named values the whole site shares). A design system page shows it all as live examples agents can inspect.
When someone asks an agent to add a new button, it reuses the existing Button component and its styling, which also adapts to dark mode automatically. And no human has to look anything up.
Intent's design system started from Figma specs that were automatically translated into code using a Figma MCP connection. After that, the code itself became the source of truth and was updated with a new body font, responsive layouts, dark mode, and more as the site evolved. We've even had agents write changes back to the original Figma files. But since the code is the source of truth, that hasn't been necessary in practice.
Sol and Aria's websites follow the same approach (links go to their design system pages), each with design tokens, agent instructions, and a design system page that stays current because it's built from the same code as the site.
Design teams have spent years trying to get people to actually read their design system documentation. Agents read it every single time.
2026-09-24 22:00:00
The software profession has spent years designing, developing, and shipping tools. Tools that, when learned, give people the power to create reports, videos, programs, and much more. But the pervasiveness of tools may have implanted the wrong instinct in our heads in a world of AI. Tool first, outcome second can now (and perhaps should) be flipped on its head.
Loads of AI use today is building a lot more of the tools we're used to, but much faster. With today's capabilities, though, we can actually skip the tools and jump straight to the outcomes they enable. A tool was always just a means to an end. If AI can get you to the end directly, why stop at the tool?
As usual, a concrete example helps. Two years ago, we built an AI-powered newsroom called Exposit. The system would find, aggregate, and report on global news. Behind the scenes AI agents would do the curating, writing, and editing that you'd find in a physical news room.
So it's not surprising that we presented the end result like a news site: headlines, articles, categories, etc. People could search, scroll, or navigate to find the news they were interested in. In other words, we built a news tool. Like all the other news sites out there, just run by AI.
As we continued to iterate on the product, we added a feature that allowed people to ask about a specific topic or news story and we'd compile a personalized report for them based on the latest news, related events, people, locations, and more. Really quickly this feature became the dominant way people used the site.
I've come to refer to this approach as just-in-time content: generated in real-time, for a specific person, with a specific need, at a specific moment. Instead of writing something once and hoping it fits everyone who comes along, you build a corpus that can be recombined endlessly and produce a timely, relevant answer on demand.
From the personalized report on Exposit, people could go deeper into articles, topics, entities, sources, and more. In other words, they started from the outcome: here's the news that you asked for. And if they wanted to, later engaged with the tool(s). Outcome first, tool second.
I do a similar thing on the Ask LukeW feature of this Website. Originally people had to ask a question before they got anything. Now each day I grab my most recent tweets, articles, and files and compile a "what's Luke thinking about now" answer automatically, so people get something to read without needing to ask anything. It's a small change, but it aligns with that larger theme: skip the tools and make the outcome. In this case, starting with an answer instead of requiring a question.
Now I ask myself (and pester others with): are you building another tool, or are you delivering the outcome the tool was supposed to produce? I've found just asking that question inspires new ways of solving problems.
2026-09-18 22:00:00
A persistent attribute of AI-powered applications is their propensity to generate text: lots and lots of text. Text requires scanning and scrolling for the useful bits and too much of it gets pretty monotonous pretty quick. So I've been working on more visual replies for my personal AI, Ask LukeW and just launched a big improvement.
Ask LukeW provides answers to digital product design and strategy questions using my corpus of thousands of articles, hundreds of presentations, and (more recently) thousands of images. To make the images I've created for my articles and talks searchable, an ingestion pipeline watches for new image uploads. When an image is added to my site, an AI model examines its contents and produces a title and description for the image. The title and description are both saved, and each is turned into an embedding so the image is also searchable semantically.
When someone asks a question, a retrieval system not only searches for any relevant images semantically (using the embeddings) but also using more traditional keyword search. This brings back a ranked list of images that the AI answering someone's question can choose to include in its response. The better the retrieval, the more likely an answer can include relevant images that break up what would otherwise be a wall of text.
For instance here's a comparison of the same question without a relevant image and with one. Most prefer the answer plus visuals version.
But with this system, images were rarely included in replies despite there being plenty of good candidates. Why? Looking at the titles and descriptions generated by AI during the aforementioned ingestion process provides some answers. Consider this image from an article about off-canvas responsive images.
When ingested this image was given a title of "Green block layout comparison". I mean, that's technically correct but who is going to ask a question about green block layouts? So despite a reasonable title, this image would pretty much never show up in results. Thankfully, we can learn how it should show up by looking at the article in which the image appeared.
For the past 30 years, when I've added images to my articles, I always included an ALT tag: a very common accessibility best practice that gives screen readers and more a useful description of images in Web pages. The ALT tag for this particular graphic was "Why Off Canvas Layouts?". Same image, totally different description. While neither is perfect, both descriptions are useful for retrieval.
As I often say "AI begets more AI" so the answer (of course) was to use a fast, yet smart, AI model to combine any existing ALT tags for images with their previously generated titles. For the image above that became: "Green block layout comparison showing why off canvas layouts are used". Wordy, but much better.
And since we can be wordy, the model writing the new title for each image can now also make use of the full visual description if it wants to. Here's another image to illustrate that.
The ingestion pipeline titled this image "Image Prompt Enhance Feature". The ALT tag was "Reve enhance feature". But the new title became "Reve enhance feature showing a prompt editor expanding a brief Spider-Man prompt into a detailed version" by pulling a bit from the full description. Much better.
So what's the impact of all this? More answers with images of course. Sticking with our example above, here's how images now show up in What are off canvas layouts?
Of course, this system needs to be dynamic. If I upload an image, it gets titled from the picture alone. If that same image shows up in a later article, it gets retitled. Updating ALT tags in old posts does the same thing. Lastly, If I ever rename an image manually, the pipeline won't overwrite it. AI begets more AI, but it should still defer to us humans for the last word (for now).
2026-09-10 22:00:00
As AI can agents tackle more work, we naturally assign more work to them. The most notable example this week was OpenAI's use of 10,000 concurrent agents to propose a solution to the Navier–Stokes Millennium Prize Problem. That's a lot of agents. How do you keep them all on task?
While I don't know how OpenAI coordinated their agents, I do know a lot about the large scale agent coordination techniques in Intent. Intent is primarily for software developers and therefore aligned with their workflows, but how it enables agent orchestration can underpin a wide range of domains. In fact, developers have used Intent's underlying system for reducing their electricity bill, making restaurant reservations, and more.
But first, what's agent coordination? I'd say: aligning lots of instances of back and forth messaging with AI models that have been trained to use tools in order to make progress on a unified task or goal. Coordination helps agents:
So how does Intent enable all this for developers?
Every task runs on its own copy of your files in a dedicated workspace. That isolation keeps agents from overwriting each other's changes. A living spec lives in each workspace and keeps the agents coordinated, recording what got decided and why along the way. The spec allows each agent picking up work to know what came before and what's next.
Human have different jobs (ideally based on what they're good at) and so should agents. Intent comes with a set of default agent roles: a coordinator breaks work into pieces and delegates them; implementer agents write the code; verifier agents check that code against acceptance criteria.
You can also add your own specialists. for example, if your team has conventions worth enforcing (a particular testing approach, a security review step), you can encode that as a reusable role and it shows up in the mix like any other agent.
When writing the spec for a task, a coordinator agent will outline how to get the work done: in what order, by whom, and how. As each agent makes progress, they can determine if need to wait for something else to happen and wake up only when needed. For instance, an agent can monitor a pull request in the background, answer review comments as they arrive, and push when everything's ready.
Handoffs can happen between agents as well. When an agent determines its work is done it can do a back-and-forth with a new agent to then move things forward. This allows new agents to only carry important information forward.
With isolated workspaces, focused context, agent roles, and handoffs, you can scale. Not just many agents per workspace, but many parallel workspaces, and many workspaces on multiple devices. Yes, that's a lot of work happening at once.
Not that long ago, a single agent finishing a coding task felt like magic. Now we're orchestrating thousands of them across devices. As with many things in AI, developer workflows and tooling are the most mature examples of large scale agent coordination. But the underlying approaches (focused context, agent roles, and intelligent handoffs) apply to a lot more than just writing code.
