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).

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:

• Not to step on each other's work
• Communicate among themselves: say when they're done, delegate tasks, review each other's output., etc.
• Interface with humans when needed: asking clarifying questions, request permissions, etc.
• Get through workflows in parallel, sequence, and asynchronously

So how does Intent enable all this for developers?

Focused context

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.

Agent roles

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.

Intelligent handoffs

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.

Many agents, many devices

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.

To illustrate, the Ask LukeW feature on my Website (which answers digital product design questions using my writings and files) could follow the examples above and start with a seemingly simple interface: just a greeting and an open text field.

While it looks simple, it can be anything but. People regularly struggle with knowing what to ask. To address this, Ask LukeW includes an always changing set of suggested questions to give people both a place to start and a sense of the kinds of questions they can ask. In usability testing, we consistently found that even just reading suggested questions helped people understand the site's purpose and how they could use it.

But even with suggested questions, people still have to ask a question to get started. After updating the retrieval system powering Ask LukeW, I realized things could be different. The new system supported time-based questions like: what did you write about recently? After seeing the results for this question a few times, I decided to just turn it into an answer.

Each day, I grab my most recent tweets, articles, and files and compile a "what's Luke thinking about now" answer automatically. That answer shows up above the suggested questions and gives people something to read and/or respond to without needing to ask anything.

It's a small change but one that addresses one of the most common AI product issues: capability awareness. In other words, how do I know what this product can do? It also aligns with a larger theme I've been poking at: skip the tools and make the outcome. In this case, starting with an answer vs. requiring a question.

While an increasing number of software companies have adopted agentic features in their applications, as usual it is developers that are pushing things forward. The most forward leaning developers I work with today are supervising many agents on many projects at once. Hundreds and in some cases more agents coordinating to build, test, and ship software. Which, as you might expect, is a lot to manage. And developer applications born in the chat era of AI products aren't keeping up.

To account for this, we recently redesigned, rebuilt, and open-sourced our developer tool, Intent. Intent scales agent work by turning tasks into separate workspaces, each with an isolated copy of your files so agents don't step on each other's work. Each workspace runs on a living spec and a coordinator that breaks work down, delegates to specialized sub-agents, and keeps things moving without requiring babysitting. There's also a higher level agent to check-in and manage work across both multiple workspaces and multiple devices.

That's a lot of feature talk. But the point is between isolated workspaces, specialist agents, living specs, and more, the product is designed to provide observability (see what’s happening) and introspection (figure out why) over large amounts of agentic work.

While an increasing number of developers are now comfortable no longer manually reviewing AI agent code changes and just interacting with coordinator agents that manage other agents, they still need enough control to dive in, see what's happening, and course correct if needed. But as these systems mature and trust builds, we'll shift to another stage of AI product evolution.

Just like most computer users don't know or care about the code their applications run on their computer much less the deeper code their operating system runs to interact with a computer's hardware, they soon won't know or care how their agents use the applications on their computers. A new layer of abstraction will allow people to get work done in ways that don't require them to know about (and much less know how to use) the software we spend all our time interfacing with today.

In my last post, I highlighted how Apple's Knowledge Navigator video informed by John Sculley's conversations with Alan Kay (who was an Apple Fellow at the time) pointed the way toward human-centric computing. Increasingly feels like the next stage of AI products will feel a lot more like that vision as we inevitably add another layer of abstraction.

For most of its history, software has been deterministic. An application's behavior was thought through by developers and hard-coded in: how to check for errors, where to save data, and so on. This rigidity usually made its way to the user interface. Think Web forms with strict input requirements or a limited set of filters for search.

The end result was that people had to adapt their behavior to computers, not the other way around. We learned what little icons meant, remembered which menu item features were in, and tried to resolve (often cryptic) error messages when they came up. Not how most of us would want to spend our day.

Increasingly, though, we have technology that can flip this paradigm on its head. Fast and inexpensive AI models allow software to bend to humans instead. As always, examples help. Search and forms are a huge part of today's software, and both used to force people into computer speak. Today, semantic search replaces a rigid set of filters by turning your question into whatever query syntax is needed behind the scenes.

Multi-modal parsing does the same for input, taking images, documents, or web pages and turning them into the structured entries a database requires.

The common theme in both of these examples is the computer adapting to the human. Instead of making people speak and use computer, computer figures out what people want and gets it done. Add enough bits of intelligence into software and the process of using software becomes dramatically different.

The vision I keep coming back to (minus the bowtie) that illustrates just how different is Apple's 1987 Knowledge Navigator video. Put simply, it makes computing... natural.

There's no voice commands to memorize, it uses natural language. There's no query syntax to learn, it uses fuzzy search. There's no cursors, it uses direct manipulation through touch. All this together lets people act like people, not like computers. Which has always been the goal.

Not all questions are the same. Some are time bound: "What did you write about Web forms in 2010?" Some require specific a format: "Any videos where you talk about onboarding?" Some want a concrete number: "How many talks did you give in Seattle?" Some are just off topic: "Ever dance with a capybara?" Despite this, the way Ask LukeW previously found answers was always the same.

When someone asked a question before, the system ran through four searches at once: semantic and keyword across both titles and contents. Why so many searches at once? A relevant detail can sit deep inside an article whose title looks unrelated, and a strong title match can surface a whole relevant file instead of just passages. The results that come back get merged, deduplicated so we don't repeat the same content multiple times, and re-ranked before being used to answer someone's question.

This approach worked well enough to answer the 50,000+ questions people asked to date. But since it was architected three years ago, things have progressed. Very fast and capable AI models can now layer bits of intelligence into places they previously would have been to slow and expensive to use. Context windows for models have massively expanded in size and new models and ways to embed content open up better ways to do retrieval. So... it was time to rebuild.

We added a lightweight classifier that analyzes each question being asked and decides how best to search for results: a date range, a recency ordering, a comparison, a specific media type, a count, or a casual conversation. Because a question can be both temporal and media-specific at once (for examples) each classification can stack together. This allows us to better answer...

Temporal Questions

The old system was mostly blind to when I said something. Now it isn't. You can ask things anchored to a moment or a span of time. And it handles the harder version, where the question is about change over time.

• What are you thinking about most recently?
• What did you say about mobile in 2008?
• How have your views changed on AI agents?
• What's the biggest difference between how you thought about AI two years ago and now?

Retrieval Questions

Often people don't want an answer, they want a particular artifact. They half-remember it and describe it. The system now figures out you're after one specific thing and gets it.

• Show me a video of your "AI Ate My Website" talk.
• You wrote an article about Mad Libs forms?
• The podcast where you talked about working at Google?

Quantitative Questions

These are closer to database queries than "find me relevant text" fuzzy text searches. We now recognize that and answer with actual counts and lists instead of a vague summary.

• What are your 10 most recent articles?
• How many talks did you give in 2012?

Visual Questions

Some questions are best answered visually, and the response should be an image, not a paragraph describing one. We re-indexed every image posted on my site and can serve up to three per answer. We also cite specific PDF pages and drop in a slide when appropriate.

• What's the difference between AR and VR?
• Why top-aligned labels in forms?
• How to design a pull to refresh feature?

Casual Questions

Sometimes people just want to have fun and ask about random topics. These used to get rejected when no result came back with a message saying I hadn't written about it. Now it recognizes a casual question and answers in kind, often with one of the thousands of LukeW character images people have generated thrown in for personality.

• Ever fight a panda?
• What kind of trails do you like?
• Ever clone yourself?

The new retreival system also breaks content into much smaller chunks (yes that's the technical term) to better match specific sentences instead of losing them in a big blob (not a technical term). But small chunks lose their surrounding text and thereby important context, so we pull also in neighboring chunks with each result.

There's still a re-ranking step to make sure we're using only the most relevant results to generate answers. But we tuned things to use 75% re-ranked results and 25% of results from our original embedding search, just to make sure the re-ranker is not over-powering the final result set.

Last but not least we diversify the results so there's not mulitple near-identical chunks that might overpower an answer. But because we now pull in neighbors, a small important set (say the 2008 results) can get washed out by a bigger pile from another result. So we diversify within each result separately.

But Does It Work?

Yes that's a lot of steps but it adds up to better answers. How do we know? Evals of course, this is an AI application after all. But as usual, automatic evals are not enough. Ours was confident the new system was better. But just to be sure, I compared 100 old vs new results by voting on them manually and guess what? The old system won.

Turns out we had a bug, which got fixed. But I mention it because, automatic evals tell you the things moved in the right direction. Human evals find the specific failures you'd otherwise be blind to.

Big thanks to Lukas Seklir, Jerome Paulos, and Sam Breed for this round of changes. I've written about many of the others updates to Ask LukeW over the years, if you want to go deeper into any of it, have at it:

• New Ways into Web Content: rethinking how to design software with AI
• Integrated Audio Experiences & Memory: enabling specific content experiences
• Expanding Conversational User Interfaces: extending chat user interfaces
• Integrated Video Experiences: adding video experiences to conversational UI
• Integrated PDF Experiences: unique considerations when adding PDF experiences
• Dynamic Preview Cards: improving how generated answers are shared
• Text Generation Differences: testing the impact of AI new models
• PDF Parsing with Vision Models: using AI vision models to extract PDF contents
• Streaming Citations: citing relevant articles, videos, PDFs, etc. in real-time
• Streaming Inline Images: indexing & displaying relevant images in answers
• Custom Re-ranker: improving content retrieval to answer more questions
• Usability Study: testing a conversational AI interface with designers
• Generation Model Testing: a personal benchmark for AI model evaluation

Digital image editing has always been canvas-centric. In Photoshop (used by something like 90% of creative professionals) you're adding, removing, or changing pixels. The application doesn't really know what it's looking at because there's no semantic understanding of the subject matter baked in. It's just pixels and, therefore, lots of pixel manipulation tools.

When every object in an image is identified and addressable, you can edit by changing the subject itself. Move the cat here. Make it a sunny day. Make the cat's eyes green. Popular tools like Photoshop were built before these kinds of capabilities existed so they put pixel manipulation front and center instead of behind the scenes. Object-centric editing flips this.

Large Layout Models

Most image models use text as their internal representation: a language model expands your prompt into a long description, and a diffusion model renders that into pixels. Text can say a lot, but it says it loosely, and loose input means loose control. To see that in action, just tweak a prompt and watch the whole image change.

Reve's new model is trained to think in layouts instead of prose. A layout is a structured, hierarchical description of an image where every element has a location, a size, a description, and attributes like color. The model takes layouts, instructions, and images as input, works out a layout in its thinking, and then renders the pixels. Layout is to an image what HTML is to a webpage.

When every image is built from a layout, all the elements in it are addressable. A designer can change the color of a car without regenerating the whole image. An interior decorator can move chairs around a room. Shadows, reflections, and perspective stay coherent because the model understands how the pieces relate, not just which colors land where on a canvas.

Because a layout is a readable, structured format, it can also be it a shared interface between people and AI agents. A agent can reason about a layout the way it reasons about code. That enables new forms of human machine collaboration that canvas-centric approaches can't. And we'll see a lot of new creative tools as a result.

When building, and even more-so maintaining, websites and software applications, cohesion matters. A consistent brand enforced by intentional use of visuals, colors, fonts, etc. Coding standards, libraries and frameworks, a common development process, etc. Today's AI models can handle all that and more but how do teams make sure they handle it all the way they'd like? And do so repeatedly.

The answer boils down to context: prompting models with clear, comprehensive and relevant instructions. Better context, better results. So how can we encode context into our applications so not only every update to a Website or application stays aligned but every person on a team does too? In our recent projects we've relied on a steering layer.

So what's a steering layer? Put simply, it's how context gets enforced across a project, a team, and even, a company. Every Website or application at its core has a codebase and a set of tools for people to modify that codebase. That's how features ship, performance improves, and ideally software companies make money. A steering layer (conceptually) sits in between the tools and the codebase.

Examples, please. Let's start with a really simple one. My LukeW Character Maker is a small application that allows anyone to make on-brand (for LukeW) image assets. It consists of a tool that allows people to create, review, save, and share assets. A steering layer composed of guidelines, reference images, and prompt rewriting. And the code that runs everything.

The steering layer is responsible for enforcing an AI image model's output aligns with the LukeW character's style, colors, appropriate use guidelines, and more. The LukeW Character Maker tool allows anyone to easily stay on brand when making a LukeW brand asset. And the codebase makes it all happen.

At this point, it's worth noting that the steering layer often lives in the codebase. When it's just text files, reference images, etc. It makes perfect sense to leverage the version control, review process, and team collaboration native to code. But not everyone on a team is comfortable, nor should have to be, working as a developer. For the cases where designers, copywriters, PMs, and others should contribute to and maintain the steering layer, a UI for doing so separate from the codebase makes sense.

As another example, we recently launched a Website for our Agentic HR company, Sol. The steering layer for the website consists of a set of design tokens, development instructions in an agents.md file, and some agent skills. These live in the codebase with everything else. But anyone using AI agents to update the site (with a tool like Intent) is "snapped to" the design and development guidelines in the steering layer. This allows everyone on the team to make Website fixes and add new content without diverging from the design and development guidelines.

It's also worth noting that a steering layer isn't limited to a few text or image files. In the case of the Ask LukeW feature on this Website, the steering layer is composed of not only instructions and examples, but multiple retrieval systems I've iterated on for the past few years as well. Their job is to find the right context for any given question and dynamically apply them to steer results. There's also a whole set of admin tools for managing what's in the context they pull from but that's a whole other topic.

With each new project, we're looking at better ways to make the steering layer visible (and for some, editable) to teams. We're also building steering layer powered tools that enable more people in an organization to contribute to projects without sacrificing cohesion. So... more to come.

When I instruct a coding agent to write a large chunk of code, I can roughly tell what's happening, but I don't have years of professional software development under my belt. I can play a developer on TV. But in real life, I'm a pretty crappy one. The same is true in reverse: a developer can generate a layout, but they don't have the years of pattern recognition that tell a designer what matters and what to throw out.

In other words, the "do it all yourself" approach spreads us thinly across multiple complex and important jobs. That's not a superpower. Unless you want to live out the real-life adventures of Mediocre Man.

Your Unique Value

Years ago at Yahoo!, we built an internal class for designers called Board to Board (from the drawing board to the boardroom). The whole point was instead of convincing people design needs "a seat at the table" by trying to act like business leaders, figure out what designers bring that nobody else at the table has so you get invited. Pattern recognition. Visual communication that makes concepts clear. Those same skills turn out to matter enormously for telling the story of a company, not just a screen.

The lesson was double down on the thing you're uniquely good at and apply it elsewhere. Don't dilute it trying to be a passable version of other roles.

Encode your Expertise

Similarly we can use AI today to do more jobs or to make our one job have much more reach. We've been building this into how we design and build Web sites and applications using collaborative steering. It allows a designer to put rigor and focus on the grid, the typography, motion rules, and color system of an application. They encode that into a shared context that both people and agents apply. A developer does the same with how code gets organized, written, and tested.

In practice this design and development "intent" ends up as text files outlining instructions that AI agents use when building software. Anyone using agents within a codebase with collaborative steering stays aligned with this intent because their agents make use of it when doing work.

With this approach, designers don't have to be present to influence how things are laid out, their intent is scaled with each AI agent. The grid is the grid no matter how many agents are writing code in parallel.

Precision is the skill

Collaborative steering doesn't mean dumping every possible bit of design or development context into agent instructions. It's being precise about what matters because with AI agents today, the more you pile in, the less useful it gets.

And that's where expertise kicks in. Knowing the three to five things that actually matter, in what order, and how they need to be done, is the value add. It's the part you can't fake by playing a role you never trained for. And it's the part worth encoding for everyone else.

AI doesn't mean you should go be everyone. It means you can scale the thing you're uniquely wired for.

Many AI-driven productivity tools have evolved from chatting with an AI model to guiding the work of agents capable of a lot more than just answers. But when everyone on a team runs their own agents they guide them towards the outcomes they want, towards their version of things. So in a agentic world, it becomes even easier for perspectives to drift apart. As one design leader recently put it at the Design Futures Assembly: when anybody can build what they want, you feel it in the product because you ship fifteen different ideas instead of one unified point of view.

One of the reasons this happens is that people use different ways to guide agents. Agent markdown files, skills markdown files, system prompts, agent prompts, memory, MCP servers, and so on. The combination all of these disparate elements influences the outcomes AI agents produce.

That's complicated enough for an individual but multiply it across a team and it becomes really difficult to work on the same thing together. Everyone's agents are optimized for their own perspective, not a shared one. And the elements influencing them are scattered across people's computers, codebases, and servers.

We need a different approach for simplifying context management not only for individuals but for groups as well. Think of it as collaborative steering: a mechanism for guiding agents that's collaboratively created, edited, and maintained by teams.

Why collaborative steering? Because, even with all-knowing AI, people have specific expertise and experiences that when brought together make products better. Designers versed in interaction design principles, brand voice, visual design integrity. Engineers focused on performance optimization, easy to maintain code structures, infrastructure choices. But ensuring these distinct roles produce a coherent whole has always been hard. AI can help.

In several of our recent projects we've used Intent, to define project-level context that steers agentic workflows toward shared goals, not away from them. We're currently applying what we learned to larger scale and more ambitious work, which I'll share in the coming weeks.

But after seeing how far we've gotten already, I'm pretty certain that the era of everyone on a team piloting their own disconnected agents can't be the end state. The tools that figure out how to make collaborative steering natural and lightweight are going to change how teams, not just individuals, build.

I was recently in a meeting discussing improvements to a specific part of a product. The backend engineer came in with a mockup. The product manager came in with a mockup. And the front end developer already had a working build. Three different disciplines all showing up with their version of what the UI could be, all enabled by AI tools. Given this reality, designers should worry about AI taking their jobs right? Well if the job is making mockups, then yes.

Here's what happened in that meeting. Seeing each person's concepts led me to ask the more important design questions. How do these features interact? What are the relationships between them? We discussed the system, its objects, and the mental model that made most sense for our target users.

We got to a shared understanding of the data we needed to support the UI, how it should be structured and how it interrelates with the rest of the product. Back-end, front-end, PM, and design on the same page. Which makes sense because these are the conversations that drive clarity and coherence in a product. Not "do you like this in my mockup or that in some other person's mockup?"

Later, I was reminded of a point I heard an educator make at the recent Design Futures Assembly. He noted at their business school, they'd give students case studies to analyze. Pretty much every student used AI to blast through the analysis in minutes. At first, the professors tried to stop students from using AI. But quickly they realized they should encourage it.

When all the students came in with the baseline analysis behind them, the conversation could progress to the next level. Before, it took the whole class hour just to get to the basic conclusions. Now, within ten minutes, they're on to much deeper and meatier topics. The majority of the class is spent expanding from the baseline as opposed to getting everybody there.

When everybody comes in with a baseline, we can skip past "here's my idea, here's my idea" and get straight to the meaty questions. The ones that rarely got discussed because we used to spend our time analyzing one person's mockups.

It's not that where things lay out on an application screen doesn't matter (it does). It's that the layout should stem from the underlying purpose of an application and how we represent the system that enables it to people.

The mockup was never the hard part. AI has made that abundantly clear.

Changing Tools, Changing Roles

Almost all designers are using AI tools multiple times a week. The average number of AI tools in a designer's toolkit doubled in the last year. And that's just off-the-shelf tools. It doesn't include the ones people are building themselves.

At the same time, design leaders and organizations are looking for the go-to stack: what tools should my team be using? The honest answer from the people closest to the frontier was... there isn't one. At some of the best teams, the stack is dozens of internal tools that change month to month. The muscle we all need to build might not be picking the one tool. It might be getting comfortable with a highly dynamic toolkit.

Because designers aren't just using new tools. They're making them. And the gap between "off-the-shelf tool" and "thing I built this morning" is collapsing. People at the assembly were building custom agents that crawl codebases and write wikis of user mental models. They were shipping to internal app stores, building custom workflows, and more.

Close to half of designers shipped AI-generated code to production. At early-stage companies, it's more. At public companies, it's less. But in all cases, designers are asking themselves: now that anyone can ship code, what can I uniquely do that others cannot?

When seeing all this, organizations start asking designers to change how they work, ship code, build tools, move faster. But they haven't made any formal changes to job roles, performance reviews, etc. The expectations are moving way faster than the incentive structures.

At one of the big companies, designers who were empowered to ship to production started fixing small annoyances that customers hit 50 times a day. The customer response was overwhelmingly positive. But those fixes weren't what product management would have prioritized. How does that get resolved?

And Then What?

When everyone can ship, you get a different kind of problem. One design leader described it perfectly: they let everyone build and push whatever they wanted. And you could feel it in the product, because nothing made sense together.

Several people at the assembly used the word "editorial" to describe where design leadership is heading. Less about making the thing, more about deciding what gets made and ensuring it all holds together. The skill of saying no is becoming one of the most important skills in the profession.

One tool company founder used the word "coherence" instead of editorial, which I liked even more. Across every medium, you know when something feels singular, like it came from one shared point of view. That's what's at stake when everyone has the power to build.

Yet anything you think the models can't do, they probably will do faster than you expect. And taste, the thing designers most often cite as their safe island? Consensus was choosing a good UI or even generating one is pattern matching, and models do that and will keep doing it better.

But several people pointed to something harder to automate: figuring out what to ask in the first place. Reading between the lines in a user research session. Noticing the tiny turn of phrase that reveals what someone actually needs. Deciding what matters, not just what works. Will models also outpace us there? We'll find out soon.

The role is expanding. The boundaries are blurring. Designers are building, coding, shipping, making tools. Whether the organizations around them are ready for that is a different question. The measurement, the incentives, the processes, none of that has caught up yet. And until it does, we're in a strange in-between: doing different work in the same old organizations.

Someone at the assembly asked the question directly: what do we call ourselves? It got a laugh but it's a real tension underneath all the practical changes. Designers can ship code. PMs can make prototypes. Engineers can generate UIs. The boundaries that used to define the role are blurring.

For my part, I've always held the most important role of designers is fighting for the coherency, simplicity, and visual communication needed to humanize technology in a way that makes it work for people, not the other way around. New tools don't change this. New ways of working together do. Which is what we dug into into our Design Futures session Finally, the Handoff is Dead (full notes at the link).

Big thanks to Jeffrey Veen for hosting and everyone I got time to reconnect with and meet. Let's do it again soon.

Most companies have years of cemented process. Changing how designers and developers work together means unwinding habits, tools, and politics that have been building for a long time. We're in a different situation because we're spinning up new companies regularly. Which means we can recreate the design/dev process each time. And as the technology evolves and we learn what works, we adapt and carry those lessons into the next one. Today we'll share our current approach.

Where a lot of the discourse on AI is these days, and where a lot of AI tools are at, is individual empowerment. Designers saying: "I can finally ship code, I don't even need developers anymore." Developers saying the reverse.

But very few people are actually asking the question: how do we use AI to work better together?

Because pretty much everybody, in this room and beyond, is working with other people. And that's where the magic lies. Being able to pull multiple folks, their skills, and their experience together to create something better than you could do yourself.

Why doesn't this kind of collaboration happen already? As user experience, front-end development, and product management have matured as disciplines, we've fallen into a throw-it-over-the-wall modality. Partially because as these roles have matured, specific tools have been made for designers, like Figma. Likewise specific tools for developers, tools for PMs, et.c

And now we're adding a lot more tools, thanks to AI. So we're all able to produce more at a higher rate. Which means we're more throwing stuff over the wall faster. That's why you hear stories of developers just being overwhelmed with PRs as everyone starts "shipping" their ideas.

That applies to big complex projects but also nearly everything we do. Like publishing a blog post on your Web site. Maybe these days, the PM writes the content in ChatGPT, the designer makes the assets in Nano Banana, the developer writes the code in Codex. Everyone's productive, but are they aligned?

To help solve this, we've been building an app called Intent. The goal: make it easier to build software together. For any task, you spin up a workspace, which is a bundle of everything you need. Files (an isolated copy of the codebase, so you can change without messing up what others are doing), context (specs, scratchpad, data from external systems via MCP, etc), and agents (with tools and the ability to delegate and orchestrate work). Because these are all in one bundle, it becomes easier to put things down, pick them up, and hand them off.

Here's why that matters in practice. A designer keeps working where they already work (like Figma or paper) and brings their expertise into the workspace: grid, typography. That all gets encoded. A developer gets to work in their tools: CSS frameworks, deployment, structure. Same surface, different expertise.

The same surface that makes it easy to collaborate with people on your team is the same one that makes it easy to collaborate with agents. And true collaboration means respecting everyone's taste. So any workspace that gets spun up will align with how the designer encoded the styles to work and how the developer encoded the code to work.

To illustrate as a designer, I've got a Figma file with a grid and layouts. I go into a workspace in Intent and say: "Agent, look at the Figma file. Create the grid. Here's what the breakpoints are." Now that's encoded in the workspace and anybody that creates a new page or drops in a new asset, it works within that system.

I can also set up how animations should work to give everything made in the workspace silky smooth transitions.

Same idea on the developer side. The dev can say: here's the agent's MD file, here's how we're testing the code, here's the tailwind config. The agent encodes all of that.

Taste gets baked into code files and markdown files in the repo. And because things are built on top of the same version control that developers use, it gets automatically included into every new workspace.

The great thing is that this same pattern works for anybody on the team. An illustrator can use their own tools to make assets. A content writer can write their copy in Word.

Then anybody on the team can spin up a workspace and say: we're making a blog post, here are the assets, here's the Word doc. Because that workspace already includes the designer and developer's tastes, what pops out the other end is a blog post that's fully aligned with the rest of the site.

You can also run these workspaces in parallel so many people can be working on different parts of the experience simultaneously. And because every workspace is encoded in the same way, everything that gets added ends up unified by default.

This gives us massive parallelism and the ability to accommodate all kinds of last-minute requests. Which, even in an age of AI, still happen. Here's me busting out 10 last-minute 8pm asks in minutes using multiple workspaces without messing up the design or code integrity of the site.

AI tools are making individuals faster, but speed isn't the problem. Cohesion is. When taste is encoded into a shared workspace in Intent, designers keep designing, developers keep developing, and everything that comes out the other end holds together. No handoffs necessary.

You're Not a Hammer User

We don't call carpenters "hammer users." We call them carpenters. We focus on what they make. Yet the tech industry turned everyone into "users." The goal should be letting people accomplish what they came to do without forcing them to be conscious of operating a computer. That's been the north star for decades, and it's finally starting to feel possible.

Photoshop has thirty-plus years of interface built around manipulating pixels. But when you want to edit a photo, you're thinking "make her hair flow to the left," not "select these pixels and apply a transform." At Reve, we've been building around object-oriented editing, where you interact with semantic objects (a woman, hair, a vase) instead of drawing selection boxes. It matches how people actually think.

UI for AI

A developer I work with has this great framing for how people relate to AI agents. Some treat them like pets and some treat them like cattle. If you design for pet people, you show the full trace, every step expanded, every decision explained. But that creates walls of information that cattle people will never read. If you design for cattle people, you roll everything up into a clean result. But pet people feel blind and anxious. Depending on which group you're hearing from, you may up end up with very different UI.

Across every AI product I've worked on, three challenges keep showing up. Capability awareness: what can this thing actually do? Context awareness: what is it paying attention to right now? And walls of text: reasoning traces, tool calls, all streaming at you. We're making progress, but some of these may never fully go away.

Everyone talks about using a company's data with AI agents. The problem is most of that data is stale. Your CRM gets touched when someone remembers to. The real source of truth is the sales call happening right now, the Slack conversation from this morning. Code is a rare exception because the codebase is actually current. Almost nothing else is.

Jump In or..

I've lived through the birth and growth of the Web and mobile. Designers who aren't adapting to the new reality of AI are going to feel the ground shift even more than in those earlier tech transitions. You have capabilities right now that didn't exist a year ago. Go make things.

Listen to the full conversation on the UX Institute podcast.

Design First

We started the way most Web projects start these days: in Figma. Visual explorations of what the style, wireframes for the structure, then bringing the two together into full page layouts. Our designer set up the grid, typography scales, color variables, buttons, and reusable components. Your typical design system.

This process took about two weeks and was pretty standard. Desktop and mobile comps, a couple rounds of feedback on visuals and copy, iterating until we had a visual style, a rough structure, and directional content. Just a solid Web design process.

Development Foundation

Once the designs were in a good place, our developer jumped in. But not by staring at a Figma file and manually translating pixels into code. Instead, he opened up Intent, set up the project scaffolding (Astro, Tailwind), connected to the Figma MCP, and wrote an agents.md file that pointed to all the artboards.

Then he kicked off a series of workspaces. The first one pulled the design tokens into Tailwind. The second started laying out the first page using those tokens. After that, he was able to break off into parallel workspaces, one for each page. Desktop layouts first, then separate passes for mobile.

This whole phase, the front-end infrastructure, took maybe one or two days of actual work. And by the end, every page existed in code, using the design system, at roughly 85% fidelity. Not pixel perfect, but pretty damn close.

Parallel Work

Once he deployed the site to a staging URL, the three of us started working in Intent simultaneously: our designer, our front-end developer, and me handling product/project management. Though we all were using the same tool, we each worked our own way.

Our designer set up a grid overlay so he could visually verify alignment. He would tell the agent "align to column three" and it would snap things into place (way better than guessing at percentage values). He preffered staying in one workspace to tweak alignment and refine grid positioning across a full page before committing things.

Once the pages were structurally solid, he moved on to animations. Entrance effects on homepage elements, scroll-triggered transitions, etc.. Work that normally takes days of back-and-forth between a designer specifying timing curves and a developer implementing them happened in about hours. He still maintained manual control where it mattered, finding the exact easing curve he wanted then telling the agent to use it. The implementation was handled for him so he could focus on how things felt.

Meanwhile, I was doing content and product work. Dumping in blog posts from Word docs, adding image assets, making text changes based on feedback from the broader team. My approach was simple: small discrete tasks with a single agent. Fix one thing, commit. Fix another thing, commit. Once I had four or five commits, I'd open a pull request, toss out the workspace, and start a new one. The design tokens and setup our developer created ensured my changes were all inline with our design and development architecture.

Our developer's job during this phase was partly creative and partly managerial. He handled the templatized pages (news, product detail) where variable content meant design rules mattered more. He also kept an eye on pull requests, merged changes, resolved conflicts, and updated the agents.md file when he noticed patterns emerging in the code that should be standardized.

For example, when he saw icons being added in a way that wouldn't scale, he set up a better pattern and documented it. The next time anyone needed to add icons, the agent just followed the convention automatically. He used Intent for conflict resolution too, pulling up conflicting branches and having the agent sort them out. Out of maybe 30 or 40 pull requests across the project, only five needed real manual intervention.

Same tool, three different workflows, nobody waiting on each other.

Crunch Time

Every web project has a crunch period right before launch and ours was no different. The broader team started paying attention (as they always do at the very end), and feedback flooded in. But because the three of us could all be in Intent making changes at the same time, the crunch was way more manageable than usual.

The biggest win was that any one of us could contribute meaningfully to the codebase without breaking the design system, code structure, or the site. That's a fundamentally different dynamic than waiting for a developer to make every change.

A New Way of Working?

It wasn't perfect. CSS layout struggles are still a thing. Git seems to keep finding ways to bite you. And there's still a learning curve for non-developers, even with agents handling the hard parts.

But without the handoff, everyone builds. And that makes all the difference.