When does a repeated element deserve its own component? Anton Sten is using an AI agent to build his design system. He measures its value by the decisions it saves people. Here’s his filter for what belongs:

Lately I’ve been using a simple filter before adding anything to a system. Does it show up often enough to deserve a shared solution? Does it have behavior or states that need to stay consistent? Is there an actual rule here that we want to encode rather than leave to individual judgment? And, just as importantly, is this something someone is willing to own over time?

The third question is the one I keep coming back to. Repetition alone isn’t enough. Something becomes valuable as part of a system when it captures a decision we don’t want humans or agents to keep making independently.

I’d treat the owner question as part of that decision, too. Someone has to remain responsible for the rule as the product changes. Otherwise, the team has standardized something without deciding who can resolve the next exception.

Once a rule is shared, people and agents still need to recognize when it applies. Sten uses token names to show how:

Take naming. green-600 tells you what something looks like. text/success tells you what it’s for. A designer with years of context may know which green is appropriate, and an engineer may remember which one the team normally uses, but an agent only has the system in front of it.

The more intent the system contains, the less any of its users have to infer. Semantic naming is not just a preference in that context; it carries the decision across design, code and the agents working between them. That clarity helps people too, but agents expose just how much ambiguity we’ve historically allowed humans to compensate for.

In a YouTube walkthrough, Michael Shimeles demonstrates how a file of instructions coordinates his coding agents. His “software factory” uses reusable skills, each describing how to do a particular job:

I built my own software factory. Now, when you hear that phrase, you’re probably thinking of a giant custom harness, and that could be far from the truth. To be frank, a proper software factory is more about your workflow, skills, and domain knowledge more than it is the harness. So, a software factory should be harness agnostic and model agnostic.

The harness is the software that runs the coding agent and gives it access to tools.

Shimeles’s instruction file, AGENTS.md, specifies four stages: isolate, build, prove, and ship. First, each agent gets separate working files and a branch for its task, using Git worktrees. That prevents agents from overwriting each other’s working files, though shared resources still need coordination. During the build, a skill specifies how to organize the code. Shimeles explains:

This is just basically a way I like code to be structured because if it ever come a time where I have to manually review this code like it’s 2022 or something then it’s written in a way that is easy for me to digest and get used to. Right?

So for the developers you might disagree with a service architecture. You might want it written in a different way. The point for this is get this skill written in such a way where the code written makes sense to you. For me, a service layer architecture makes sense for me.

Then the agent runs checks and captures the changed behavior. For a visual change, before-and-after images accompany the request to merge the code, called a pull request or PR. An automated code reviewer, Greptile, supplies feedback for the agent to address before passing the PR to Shimeles:

This is not getting merged by me until I get a five out of five. So, my software factory will continue to read the feedback from Greile and then will only give me the PR URL once it’s got a five out of five. Once we’ve reached five out of five status, it’s my job to look at before and after. It’s my job to read the description and then I just merge.

The score doesn’t guarantee correct code. I’d treat the before-and-after evidence as something to inspect separately from the reviewer’s confidence. His shared skills limit the number of review iterations and spell out what’s needed to capture evidence, so there’s setup and adaptation involved in copying this workflow.

Candace Wilson and her design team wanted engineers to reuse the code from their AI-assisted prototypes. The goal was to preserve details that can get lost when someone rebuilds a design. Writing for Bootcamp, she describes what happened at handoff:

By the time development picked up the prototype, something that looked almost finished on the surface could still be difficult to use as a starting point. We had pages that had grown into thousands of lines of code, unclear component boundaries, and sometimes implementations that didn’t match the design intent. A responsive experience, for example, could end up built more like separate adaptive layouts. In trying to reduce the visual handoff gap, we had sometimes created a different problem: an architectural handoff gap. Development then had to interpret, separate, refactor, or rebuild that work before it fit the production environment. Design had moved faster, but some of that effort had simply moved downstream.

This is the double-edged sword with designers using AI to write code. It looks done or good enough to us, but in reality, the generated code might be hiding a bunch of tech debt.

She allows for looser code when the prototype is disposable. For code another team is expected to build on, she proposes a different standard:

Prototype code does not need to be production-ready, but it should be production-useful.

For the kind of handoff I am talking about, that means the code should be structured well enough that development can extract from it without first untangling the entire thing. Component boundaries should be clear. Reusable pieces should actually be reusable. Responsive behavior should match the design intent. The prototype does not need to mirror the production codebase exactly, but it should be close enough that the handoff preserves some of the speed we gained by building in code in the first place.

I joined Jason Giles on UserTesting’s Insights Unlocked podcast to talk about AI and product design. The trust discussion drew on a story from BuildOps, where our customer base is commercial contractors. From UserTesting’s episode write-up:

When Roger’s team spoke with technicians about ambitious AI capabilities, the initial response was decidedly practical.

“Just give us the basics first,” Roger recalled hearing. “Just make sure the app is reliable and it’s speedy and we can do what we do.”

Only after those needs were addressed did the conversation shift. When the team described an AI experience that could reduce tedious end-of-day typing, technicians saw the value.

That request for reliability was entirely compatible with wanting to get work done faster. Technicians were spending 10–20 minutes on job notes in their trucks after a day of hard, often sweaty physical work. When my team spoke with technicians, a feature idea came out of it:

From that customer research came an AI feature called Visit Summaries. Instead of typing everything, technicians can press a prominent microphone button and talk. AI cleans up the account and incorporates relevant context about the property, equipment, parts used, and so forth.

The sequence matters. The team did not begin with AI and search for somewhere to wedge it in. It began with observing a person experiencing friction and then finding a way AI could help.

When customers ask us to fix the basics, we should treat that as guidance for what to build next, including with AI.

It took Marek Minor about a year to redraw Cursor’s icon system: more than 600 icons in two sizes and two styles, with every exploration and final variant drawn by hand.

The scale only hints at the effort. Minor tested differences as small as 0.25 pixels, made 156 explorations of the hamburger icon, and tracked more than 155 recurring elements and visual properties. He also built the Figma files, migration dashboard, companion site, and release pipeline needed to migrate an old font with 645 codepoints without breaking references. Writing on his blog, he explains the construction method that holds the set together:

The icons in this set are closer to technical drawings than to organic shapes – diagrams with a friendly finish. The construction method is consistent across the set: start with lines that run horizontally, vertically, or at 45°, allow other angles where the concept demands them, then round the corners until the shape follows the idea. A cloud, for example, isn’t built from circles. It starts as straight segments that get rounded joins. A fire icon is built the same way, from angled segments with rounded corners. Freeform curves, or curves taken from circles, are extremely rare in the set.

This construction logic is what makes 600+ icons feel like the work of one hand. It also suits a coding tool: precise and engineered, with the rounded corners and round stroke caps keeping it from turning cold.

Brett Queener, a partner at Bonfire Ventures, uses “harness” at the scale of an entire product in his newsletter Tales from The Bonfire:

The Horse is the LLM model: enormously powerful, fundamentally unpredictable, not something you command so much as ride.

The Harness is the application layer fitted to that animal for one rider and the entire job that rider does, holding the ontology, the interaction model, and the learning loop.

The Hay is everything the horse and harness need to stay healthy at scale: orchestration, governance, cost routing, security, observability, data infrastructure.

The horse is the AI model. The hay is the collection of services that keeps it running. The harness is the product someone uses for the whole job. It holds what the system has learned about that job: the facts, relationships, exceptions, and rules Queener calls its “ontology.” It also decides which steps need the user’s attention and uses previous results to improve the next attempt.

The developer harness keeps its instructions, tools, and files stable while models change. Queener applies the same principle to an AI business. A company can use cheaper models for routine tasks and save the most capable models for difficult judgment. This keeps its cost of goods sold (COGS) low and protects its profit margins:

First, no smart harness maker will wed themselves to one model provider. Every good CTO I talk to has already abstracted the model away from the product. Not out of loyalty. Out of survival: which model is best changes every 60 to 90 days, and prices move by an order of magnitude.

Portability is also a margin discipline, and it’s most of the difference between the companies quietly running healthy gross margins and the ones complaining in public about COGS. A large share of what runs in production never touches a frontier model: classification, extraction, routing, summarization, retrieval. Reserve the frontier for the hard, ambiguous, high-stakes judgment and send everything else to a pony. Run every call to the biggest model because it’s easier and your gross margin belongs to somebody else’s price list.

The graph describes how jobs and results move through the system. Queener shows that the same graph can serve two roles. An off-the-shelf tool for coordinating any AI system is hay. Once a company fits that coordination to its own agents, rules, and way of working, it becomes part of the harness.

But coordinating the work is not enough. The harness must retain what it learns even when larger customers reach it through another interface, such as Claude, instead of a screen provided by the harness itself. It must also learn from results. Queener calls the tests that score its work “evals.” The system that feeds those scores and corrections back in so future behavior changes is the reinforcement learning, or RL, platform:

It owns the interaction model for that role. Not a chat box, and not necessarily a UI at all. What the rider is asked, what they approve, what they never have to look at again, what escalates and how. Which doesn’t require pixels: upmarket this increasingly gets consumed headless, rendered inside Claude or something the customer built on Vercel. Serve that, but treat headless demand as a scoreboard rather than an architecture, because yours is the surface holding the ontology and the loop and the memory of this rider, so its ceiling should be higher than a general assistant’s at your rider’s own job. The test is what survives a change of surface. Swap the front end next year: if everything they taught the system is still there, you were the harness. If not, you were endpoints with good docs.

It owns the eval and RL platform. The dividing line is whether a graded outcome changes future behavior without an engineer deciding what to change. Everybody has dashboards, and a human reading one and then writing code is a feedback process, not a loop. The test: can you point at a behavior your product has today that nobody on your team designed?

And it is singular. One rider, one harness. Nobody runs three of these at once any more than they drive to work in two cars. Not “fewer apps,” but one, per rider, per job.

Patrick Morgan, writing in his newsletter Unknown Arts, starts with the boundary his system is designed around:

The problem is that prototype code and production code serve fundamentally different purposes. Production code needs to optimize for shipping and maintaining a performant product at scale while prototype code needs to optimize for speed, flexibility, and divergence. I wrote more about this distinction in my article Prototype Code Is Not Production Code (And That’s Okay).

You need both sides of that spectrum to design and ship a good product. A prototype should be able to change direction quickly, without worrying about scale or production constraints, while still benefiting from shared foundations, reusable primitives, and a connection to the product it may influence. So I started looking for an environment with the freedom of a prototype, but enough shared structure for the work to compound over time.

Morgan argues for giving exploratory code enough shared structure that designers can move quickly without severing each experiment from what the team already knows.

As more people used the environment, I started curating more of the context around the work directly into it, including our design principles, personas, and project briefs. As I wrote in AI Needs a Plan, the best agent work usually starts with a written brief, not a one-shot prompt.

By then, the environment had grown from a place to make prototypes into a shared foundation of tools and context that helps people and agents understand how our team designs.

In Morgan’s account, the prototype is not the only thing that compounds. The team’s principles, personas, briefs, foundations, and prior decisions do too, because people and agents can reach them from the same working environment. That shared home is the Design OS: a codebase separate from production where people and agents can reuse the team’s context instead of starting each prototype from scratch.

A codebase gives the Design OS somewhere to live. It lets design intent be shared, connected to other assets, and put into practice.

That has always been possible in theory, but until recently code wasn’t very accessible to designers. Agents change that dynamic by acting as translators into and out of code. They can turn a designer’s plain-English intent into working software, then translate that software back into something the designer can use and evaluate.

This builds on the argument I made in AI Runs on Text. So Should You.: when your thinking lives in plain text, it becomes an asset that both you and AI can read, reuse, and extend. Code just happens to be a more structured form of plain text, which makes it easier for agents to interpret and act on reliably.

The goal here is not to make designers write code. It’s to make design intent executable. When a codebase holds the team’s foundations, conventions, and decisions, an agent can translate a designer’s instructions into working artifacts and carry that context forward. Each new piece of work can then build on what came before it.

A harness is the environment around agentic work: the models, instructions, skills, tools, and files that let agents do the job. A graph describes how work moves through that environment. Anatoli Kopadze, writing an article on X, starts with two familiar parts:

A graph is just a plan for your AI work, drawn out so you can see it. It answers two questions: which jobs need to happen, and which job has to wait for which.

There are only two parts, and getting them straight fixes most of the confusion.

A box is called a node. It’s one job: one agent doing one task, with one thing going in and one thing coming out. Researching a competitor. Writing a draft. Checking a claim.

An arrow is called an edge. It just means one job needs what another job produced, so it has to wait for it. And the arrow only counts when something real actually passes along it.

That last condition changes how you design the workflow. A list written as “do A, then B” looks sequential even when B never uses A’s result. Kopadze’s test is to remove those false dependencies so independent jobs can run at the same time:

Look at the AI workflow you run today and walk it step by step. At each step, ask one thing: does this step actually need the result of the one before it?

If yes, the edge is real. Keep the order. If no, there is no edge, and the wait is wasted. Those two jobs can run at the same time.

Take a simple one: “review file A for bugs, then review file B for bugs.” It reads like a sequence, but the check on file B never looks at what file A returned. They only run one after another because that is the order you typed them in. Run them side by side and the whole thing finishes in the time of the slower single file, not the two added together.

This resembles building an automation in n8n: each node has a job, and the connections determine what data it receives and when it can run. AI adds another requirement, though. The agent checking a result should not inherit the worker’s reasoning and simply agree with it:

So you never let the agent that did the work check the work.

You put a separate node on the edge. Its only job is to try to kill the finding before it moves on. If it survives, it passes. If not, it dies right there.

Here is the catch nobody names: that checker needs a clean context.

Give it the same chat the worker had and it is not checking anything, it is nodding along to itself in a different font. A graph of agents sharing one context is just a single loop in a costume, and it breaks the same way, only later and pricier.

So make the verifier fresh. Own context. Checking a real signal, not “did the agent say it is done” but “does the test actually pass.”

Scott Fryxell, writing on his blog, has built his workday around a harness: a shared setup for instructions, tools, files, and scripts that he can use from Cursor, Claude, or the Pi coding agent. The durable workflow matters more than whichever AI tool happens to be attached to it.

Single developer projects can build to the caliber and consistency of large development teams. You can and should build bespoke applications and you don’t have to sweat onboarding experienced engineers; if they know their stack backwards and forwards they’ll quickly know how to contribute to yours. But most of all, I have learned that the harness is the thing; the fulcrum from which my expectations meet the LLM’s capabilities.

At the moment my rig is supported by two subscriptions (Cursor, Claude) that I can augment with Pi as needed. All three share my skills and AGENTS.md. Though I am using three TUIs, I have a unified experience. This has commodified the models for me; there is no magic sauce or special experience in Claude or Cursor that I need in order to be productive. I have zero anxiety about the transition from Cursor to Codex at the end of this month.

Fryxell also assigns different kinds of work to different models. He uses frontier models for planning, the first task, and parts of review, while cheaper models handle routine work. Here, “frontier” means the most capable models available:

I can run Deepseek on most maintenance and simple tasks. It’s when I am exploring a serious feature or large refactor with lots of moving parts that I reach for the frontier. Recently I learned about prewalk2, Can Bölük’s technique that uses frontier for the planning phase and first task, then hands off once the pattern is set. I paired it with the planner/worker/critic split from Building an Advanced Agentic Harness3 - a single prompt that plans, executes, and critiques itself confuses its own objectives, so each role gets isolated instead. I built both into a skill, with a supporting Pi extension that can take over at any stage of work.

Exploration leads to a plan formalized into an explicit DAG (directed acyclic graph) task list. Then a worker takes over, focusing on implementing the DAG one node at a time. Once complete, I bring in the critic to simplify and question what was implemented. Often this phase will push back enough that the worker phase is revisited. But once satisfied, the critic gives way to a promoter, which is my reminder that a job is not complete until you’ve properly communicated it to others.

The task plan is only one part of the harness. It also keeps the plans, files, scripts, and notes in one place where Fryxell can inspect and reuse them. He calls the command-line apps TUIs, short for text-based user interfaces. Those apps can change while the work stays put:

The harness is self-contained to support more than a home directory (sandboxing, a web interface, File System Access API, Docker, Deno executable, etc).

These concepts are still forming in my mind so I’ve been referencing npm start, cursor-agent, claude as TUIs to keep the concept of a harness clear. All TUIs share the harness.

Remaining auditable is important enough that the TUIs are instructed to keep things inside the artifacts/ directory. Cursor uses .gitignore to ignore files, which I think is smart, so a git-less root is required. I have a skill that syncs the harness with the repo in the work directory. Skills, extensions, and AGENTS.md are first-class citizens at the root, waiting to be modified and built upon. TUIs have to toe the line.

In this past weekend’s newsletter “Software for Someone,” I argued that cheap code makes tiny, personal tools viable even when they never become businesses. On Behind the Craft, host Peter Yang talks with Amol Jain, head of engineering at the AI coding platform Replit, about the other branch: what still has to be true when the maker wants strangers to pay.

Quotes lightly edited for clarity.

Jain starts with a repeat founder who knew the market but couldn’t build the product himself:

As AI was taking off, he sort of realized that there was an opportunity to help people measure their AI proficiency and even get certified for it, especially enterprises and companies. He’s nontechnical and didn’t know how to build it.

He went to an agency that quoted him $100,000-plus to build this platform. That didn’t sit right with him. He had heard of Replit, so he jumped on and essentially within three days was able to build the whole thing end to end.

He built and launched it, and within the first two months, he was already at $180,000-plus in revenue. As a repeat founder, he had great product intuition. He knew how to distribute and sell. He just didn’t know how to build, and a tool like Replit made it easy for him to do that.

The agency quote makes the cost collapse vivid. But the business didn’t appear merely because software became cheaper. Jain credits what the founder already had before Replit supplied the missing implementation: product intuition, sales ability, and distribution.

That pattern also explains why generic apps are getting easier to make and harder to sell:

Software is becoming rather easy to build, so a lot of generic use cases—meal planners or exercise trackers—are getting commoditized. People are building their own versions, and I can see agents swallowing many of them as skills.

Everyone has an agent that has a skill that does this. That said, the overall pie of businesses is still expanding. If you look at Stripe data, you can see the number of businesses being created going up.

It’s because of the unique advantages that people have: their expertise, judgment or taste, community, and network. People are tapping those advantages to create tangible businesses. These don’t have to be massive businesses. There is a lot of success you can have with a small business that thrives.

We see pool cleaners, nurses, jewelers, and others with domain expertise who couldn’t turn that knowledge into businesses before. Now they can bring those ideas to life. The key is finding and leaning into that specific advantage.

A household tool can succeed by being useful to one household. For anyone turning a prototype into a product, usefulness is only the starting point. Once anyone can generate a comparable interface, the commercial question becomes: what does this product offer that a prompt cannot reproduce? Jain applies that test to the software companies that survive cheap code:

If the cost of code goes to zero, what do you pay for? The things that stand that test are trust, data, infrastructure, physical things, labor, and networks. Software that offers those things—where it’s not just an interface over some data—is valuable and will continue to exist.

Salesforce, Workday, social networks, and DoorDash are Jain’s examples of company’s with such moats. Their value comes from data, regulatory risk, networks, or physical labor rather than the UI alone.

Software developer raf, who learned the craft by building and breaking web applications, describes a new apprenticeship problem that starts with an apparent success: a beginner can generate competent work on day one.

I’ll tell you this much: it’s not from consuming good work. You cannot read a hundred excellent programs and absorb the judgement by osmosis, any more than you can become a chef by eating in good restaurants. Taste is built the slow, stupid, humiliating way: you make something bad, you are forced to live with it, it fails in front of you, and some part of you files the failure away. Then you do it again. The palate is an accretion of your own mistakes, sat with long enough to sting.

The friction was not an obstacle to developing taste. The friction was the curriculum. Every wall I cursed while climbing it was, without my noticing, teaching me which walls were worth climbing. The cost that rationed my output also educated my judgement, because paying the cost over and over is how you learn what is worth paying for.

For designers, the old bottleneck did two jobs at once. Producing a weak concept, defending it in critique, watching it fail with users, and revising it made bad choices costly enough to remember. AI can compress that cycle into a polished mockup before a beginner has learned what to reject.

raf on the cost of taste:

This is the quiet cruelty of the situation and I do not have a comforting way to phrase it. Taste is slow. It says “no, again.” It sends the plausible thing back because plausible is not the same as right, and while it is doing that, the person without it has already shipped, closed the ticket, and moved on. The market timed you both with the same stopwatch and it did not see the difference. It cannot see the difference. Taste does not show up in the diff.

That makes critique more important, not less. Design teams need to value frank feedback from the skeptics in the room, not only the ones who ship fast.

Yep! Type Foundry has a useful two-part check for choosing a UI typeface. It gets past whether the typeface looks like a clean sans-serif and tests whether labels will sit properly inside controls:

TL;DR, two things make a UI font easy to work with:

1. Cap-centered vertical metrics—the space above the cap height equals the space below the baseline. Result: labels center optically on buttons and align with icons, and you can use a single padding token instead of hand-tuned CSS.
2. Tall x-height—lowercase letters reach 70–75% of cap height. Result: the word nearly fills its box, so it looks evenly centered.

Adam Waxman built five personal tools using his household’s rules and data from several apps. Most work the same way:

Aggregate data, add an LLM. The cost drop doesn’t just mean more apps, it means apps can be far more personal. Most of mine follow the same shape: pull data from multiple sources, combine it in one place, and use an LLM to generate insights from the full picture. My fitness app combines nutrition, sleep, weight, and training data that lives in four separate apps, then uses that context to make recommendations none of them could alone. I think this pattern will spread to professional tools too.

Two more lessons:

Ephemeral is fine. We used the sleep app for about four months. Our son sleeps through the night now, so we retired it. If the app had taken me months to build, that might sting. Because it took a week, I’m just glad it worked when we needed it.

AI floods big markets and unlocks small ones. Yes, AI produces endless derivative apps. But the same tools also let me build apps for my household that no company would bother making. Beyond my household, I built nycjazz.guide for NYC jazz fans and claudecodedaily.com for Claude Code developers, audiences too small for a business but worth serving.

These fleeting micro-apps change what is worth designing. An app no longer needs a large market or a long life to be useful. They also avoid the customer adoption problem Andy Budd describes: Waxman starts with one household and one problem, not a market he has to win over.

These personal apps depend on other products letting people use their data:

Good APIs matter more than ever. I switched from Cronometer to FatSecret because FatSecret had a better API. My fitness app pulls from Strava, Oura, Withings, and FatSecret, and the quality of each integration depends on how well the API is designed. As more people build personal software, users will expect their apps to have APIs and MCPs worth connecting to.

Designers now need to ask whether people can get their data out. If a service keeps that data locked inside, people can’t use it to build tools that fit their own lives.

I’ve always been more interested in making something than selling it. That instinct serves the craft, but it can be dangerous for the business. Building offers control and a concrete result; earning customer trust and adoption requires getting out of that comfort zone.

Andy Budd, who has spent the past five years working with early-stage founders, describes the handoff:

Founders often assume that once they’ve built something significantly better, the hardest part is behind them. In reality, once the fun product-shaping bit is done, a different kind of work starts.

You have to get strangers to care. You have to explain the problem repeatedly without becoming boring, show the product, make videos, write posts, go to events, ask customers for introductions and follow up with people who didn’t reply. You have to sit through sales calls where somebody spends 25 minutes explaining their procurement process, and hear “this looks great, come back next year” over and over again.

Making the product better can become a way to avoid selling it.

So they retreat to where they feel useful.

They decide the onboarding needs improving. They rebuild the dashboard. They add the feature three prospects mentioned. They convince themselves that sales are slow because the product isn’t quite good enough yet and that one more release will finally make the market pay attention.

Sometimes they’re right. But often they’re polishing the product because polishing the product feels like progress, while trying to persuade people to change deeply embedded behaviour mostly gives you rejection, indifference and unanswered emails.

Joost de Valk, creator of the Yoast SEO plugin for WordPress, has a better architectural answer to separate sites for agents: maintain one site with several interfaces.

Before you rush off to build a separate site for agents: we’ve done that before. Remember m-dot sites? Remember AMP? Parallel versions of your website always drift out of sync, and then they die. The answer isn’t a second website. It’s one source of truth with multiple renderings, where the machine-friendly surface is generated from the same content the human one is.

For website owners, keeping the publishing system accurate matters more than polishing any one rendering. For designers, the concrete consequence is to define the content model and available actions at the system level, then test every interface against the same rules. De Valk on what those interfaces need to support:

A website used to be an HTML thing, in some cases with an API. That’s no longer enough. If your website matters to you, it should at the very least also be an MCP server, and in many cases even ship a command-line client. That way agents can interact with your business directly: check availability, place the order, book the slot.

The specific standards will churn. MCP is today’s answer; something else will come after it. The durable point is this: a website is becoming a bundle of interfaces. One for humans, several for machines, and the machine ones don’t just answer questions, they take actions.

More and more buying decisions happen away from your site: in AI answers, in chat interfaces, in agent-mediated transactions. This is the uncomfortable one. You can rage against it or you can plan for it.

The website doesn’t die in that world. Its role shifts. It becomes the canonical source of truth about your business: the system of record that feeds every surface where the actual decision gets made. If an AI assistant recommends you, it’s because your home base gave it every reason to. Thin, stale, machine-hostile websites simply won’t be recommended.

Arin Bhowmick, SAP’s chief design officer, shifts the software-death debate from apps to operating context. Rather than treating the model’s capabilities as the whole story, he asks where enterprise software’s enduring value actually sits:

Despite the cliché premise, I found it insightful, an honest take from one of the “Big Four” on AI and SaaS. In it, PwC’s TMT leader Dallas Dolen says enterprise software isn’t dead. His clients are redirecting their software budgets toward AI, and the systems going in on top of the stack they already run, keeping what runs the business and building the intelligence on top. They are betting that the value sits in what they have spent years assembling.

There’s a good reason for that. An AI model can answer almost anything, but on its own, it knows nothing about your company: how it runs, which data to trust, what it is allowed to touch…

The model is the “cheap” part, while the expensive one is the business knowledge around it, the processes, exceptions and rules a company encodes over decades. That context provided by software is what makes an AI agent useful.

The existing stack becomes the policy layer for whatever intelligence sits above it. That context determines more than what the agent knows. It sets the boundaries of action: when the system can proceed, when a person must approve, what happens when the evidence conflicts, and who is accountable afterward. Bhowmick turns those boundaries into the design brief:

Once design “owns” the judgment a system applies on its own, a new set of questions lands on every designer’s desk:

• When should an agent act?
• When should it stop and ask first?
• What does it show before it does something it can’t undo?
• When it isn’t sure, does it say so, or hand you a confident guess?
• When it gets something wrong, who answers for it?
• How does a person take back control when they need to?

Often, the most useful move an agent can make is to admit when it’s unsure and hand the decision back. We have to design that handoff so it feels natural. If it reads as the software confessing a mistake, people lose trust.

I’ve started asking Claude Design for multiple directions on a canvas, then sending the promising ones through another pass before I choose. In a conversation between Michael Riddering and designer/builder Kyle Zantos on Dive Club, Zantos builds the missing part of that workflow: an interface for reviewing what the agents made.

Zantos uses a standalone HTML artifact to render the proposals and collect decisions in the same place:

You act as the orchestrator and the quality-control reviewer and send out Opus 4.8 sub agents to execute these audits as each skill does it. Compile the results, but at the end of it, compile it all, remove the duplicates, and then present me an HTML doc that has all the proposed changes and then options for me to approve, deny, or discuss them, and then have a way at the bottom to copy all of what I put in here and just paste it right back into my session with Claude.

Zantos on combining decisions across different parts of a product:

Then be like, “Oh, no, not that. That’s terrible. I hate that.” Or just like, “Yes, but add this other thing.” Or, “I really like what you did in number two on number six that’s in a totally different area of the app or the site or whatever that I’m working on, but grab the technique that we used in the second point of this doc.” So just visualizing everything from your agents has been huge.

Product designer and educator Aliena Cai argues that AI is changing the work, but isn’t replacing one kind of product designer with another. I think her survey shows that replacement can happen without cutting jobs:

The survey found that 60% of design leaders actually expect to keep or grow design headcount. Only 10% of design leaders expect to reduce design headcount, and 8% of design leaders say they are shifting investment towards hybrid roles like design engineers. However, expectations for design talent have shifted. 50% of design leaders are looking for a greater emphasis on AI tool fluency when it comes to hiring. And 48% of design leaders are placing greater emphasis on systems thinking and strategic skills. I would just call it business sense or product sense.

If you’re a manager, you may have heard the terms “rotate people out” and “upskill the role.” That might be happening here. The number of design jobs may stay the same, but the requirements are changing. Experienced designers will be asked to use AI, think about the wider system, and understand the business. If they don’t, they’ll be managed out. People entering the field will face that higher bar from the start. Some who would have qualified for the old job won’t qualify for the new one.

AI fluency here means using the tools to make and revise working prototypes. Designers still need to understand the user and business problem, check what the tools produce, and decide what should ship. Cai gives similar advice:

Based on everything I shared today, I think that if you are an experienced product designer, then there are two things you can do right now to secure your career for the future. Number one is to improve AI fluency. And number two is improve your business sense. But AI fluency really doesn’t mean just using AI for everything, because AI, at the end of the day, is an amplification tool, and it amplifies your design skill and product sense. Just like I said, it brings great ideas to life faster, but it can also bring bad ideas to life faster.

I couldn’t agree more with the AI fluency point. That’s why I’ve been reading and writing about it for over a year.

Podcaster Lenny Rachitsky interviewed Ian Silber, OpenAI’s head of product design.

Ian Silber discusses task-specific UIs. He shows how ChatGPT’s transcript can make room for them:

Another good example is, then once you actually ask it to do something, the chat transcript doesn’t need to be purely text, right? We’ve seen these now evolve so far from what it was with when ChatGPT just launched. It’s no longer just a pure chat bot.

It actually has many features within that, right? So a good example is what we call writing blocks. You ask it to write you a letter or an email.

And it now contains that email in a block that you can directly manipulate, and you can type with it, and you can brainstorm, and you can edit little bits and parts of it. You can copy just that. And that has made that interaction much better.

And we’re seeing the same thing with image generation and creating special tools for that kind of mode. And I think that’s where the UI is going to start to really continue to evolve. How do we make if you come at this and you’re a designer? Maybe ChatGPT should actually really look different or have different affordances. Or you’re a data scientist or you’re using this to run your home, your your personal life.

Maybe it should really kind of work or look differently.

Chat is useful at the beginning of an interaction because users can express ambiguous intent in plain language. The UI can then provide task-specific controls. These might be a writing surface for an email or image controls for a picture. A designer might need another set of affordances. Silber’s example turns the post-chat argument into a product architecture already appearing inside chat. In other words, generative UI.

Chat usually collapses two jobs: understanding what someone wants and giving them the right environment to finish it. Silber on how one entry point could handle both:

And hopefully all of this gets simpler as we do it too, right? When we think of the super app, I think eventually we really think of the idea of especially for our broad consumer base. We do think that there should be this one universal input that you can ask that knows when it needs to answer really quickly, or it should be chatty, or whether it should go off and do work for you.

And so, that’s a big excitement that we can get to. How can we continue to simplify the experience such that you shouldn’t have to think about how this works. You shouldn’t have to think about what model you’re on or what sort of speed you’re using. That goes back to the balancing the different kind of personas and user needs. Of course we want to expose that for the right people, but then we want to make sure that we can get a default experience that works great for for most people.

Quotes slightly edited for clarity.

In an interview with Ryan Mather, Federico Villa, and Robin Chen, OpenAI product designer Benjamin Zweig explains why designing memory for ChatGPT required studying how people remember. The work moved beyond the UI. Zweig had to turn invisible human judgment into training examples and evaluation rules that would shape the model’s behavior:

And the core of it all really is, how do you turn qualitative decisions into a quantifiable rubric? That’s exactly how you train a model to get better at any task.

Here, this meant formalizing the very human skill of determining what’s worth remembering, both in terms of what you save and when you recall it. If you ask a person to explain how they make that decision, they’re not going to have a clear answer for you. It’s an inherently human thing. So what you do is you look at a bunch of examples, apply your human intuition to make a decision, and then look for patterns and ways to turn that intuition into a heuristic that you can train against. That’s a new skill for many designers, and a new way of thinking and working.

Organizations often miss work their metrics were not built to see. AI agents face a similar problem when they encounter something their rules cannot handle. Service designer and University of Michigan urban-technology professor Ron Bronson turns to Stafford Beer’s idea of algedonic signaling: a way to report an exception outside the usual channels.

One reply to the thread referenced algedonic signalling, which sent me back to Stafford Beer.

In the Viable System Model, an algedonic signal is an exception channel: information that can move outside the normal reporting structure when actual conditions have departed badly enough from what the system expects. Beer wasn’t thinking about “agent welfare” and to be honest, neither am I. At least it relates to anthropamorizing an agent’s welfare, when in reality what i care about exclusively is what gets done well, what’s gets done successfully and ensuring an agent stays within the boundaries of its remit. So, the usefulness of the idea here doesn’t depend on deciding whether a model experiences anything like pain because that’s stupid and makes me angry, even as a suggestion.

But a system that operates with some autonomy needs a way to tell the rest of the system when ordinary control is no longer adequate.

Bronson separates two jobs. A judgment router decides whether an agent is allowed to act. An exception channel gives the agent somewhere to report a situation the router does not understand.

An agent can be completely authorized to perform the task in front of it and still encounter something it doesn’t know what to do with. The API returns 200, but the answers contradict each other. A tool works exactly as documented while exposing some behavior that looks dangerous, or the task can be completed but the agent finds something else that seems wrong and goes on a goose hunt.. Nothing has necessarily crossed an authorization threshold because none of this is within the original parameters, but it’s also not outside of them.

That makes the exit door a different piece of infrastructure from the gate.

An alert matters only if the system responds. Bronson’s diagram shows that it can let the work continue, stop the task, or change its rules for next time. Otherwise, it has only recorded the problem.

The author of the thread built a small pipe from an agent to Teams and called it distress_call. and the key is this, there should be somewhere for the agent to go when it needs to alert something is off.

The judgment router still matters because somebody eventually has to decide what an agent is authorized to do, when its discretion ends and where accountability sits, but the exit door takes that concept a step further and helps us track the inconsistencies, and perhaps the errors to better spot problems that might consequential.

For Agent Experience, that expands the design surface considerably. Making an environment easy for an agent to operate is only part of the job. We also have to decide how an agent stops.

The system learns only if the alert changes what happens next time. The next agent should stop sooner or call the right person.

Service designer Daniel T Santos uses British cybernetician Stafford Beer’s Viable System Model to explain why strategic design work can disappear in plain sight:

System 1 is operations: these are the units that produce the countable output. The screen ships, the order moves, the revenue lands. System 1 is legible by construction, because the organisation was built to count what it produces.

System 4 is strategy and coherence. This is the outward and forward-facing work: sensing the environment, holding coherence across the parts, deciding what the service should become. This is where research that reframes a requirement lives. Where the journey gets held together across channels that each have their own backlog. Where the principles that shape a hundred downstream decisions are set.

System 4 work produces no countable artefact in the quarter it is done. So the organisation, looking through a System 1 lens, does not see it. Peter Merholz recently called this design’s legibility gap, and it is worth reading. Beer gives it a mechanism: the work is not illegible because it is done badly or explained poorly. It is illegible because it sits in a tier the measurement system does not read.

The organization cannot value work that it doesn’t measure. Santos’s answer is “a shared unit of account”:

Indeterminate work becomes legible when it is anchored to a number the organisation already counts.

Anchored instead of translated or championed!

You take the System 4 work and you attach it to the System 1 metric it was quietly moving all along. You decide, up front, which existing operational or financial number this work should shift if it succeeds.

Santos knows a number cannot capture everything design contributes. But organizations already manage by numbers. Linking design work to one it affects at least makes the work visible.

Jem Gold’s encounter-language—describing how a design should feel rather than what it is made of—puts the intended experience into words. Design systems leader Yesenia Perez-Cruz, who led Shopify’s Polaris system, takes the next step: giving a team enough shared structure to express product meaning coherently, screen after screen.

Many design languages are really style guides. They define typography, color, spacing, shadows, illustrations, and icons, but say little about how to represent the concepts at the center of the product.

If you remove the opinions from container components while the design language still teaches people to place text and controls inside boxes, you will simply end up with more text and controls inside boxes.

Composability creates room to shape. A design language teaches teams what to shape toward.

Instead of treating a design language as a collection of visual rules, we should think of it as a tool for solving communication problems.

It can help to compare it to written language.

Written language has subject matter, vocabulary, grammar, emphasis, and voice. A product design language needs the same: a model of what it must communicate, recognizable visual signs, rules for composing them, ways to direct attention, and a distinct visual character.

Perez-Cruz starts with the product model: the objects, states, actions, and relationships the interface must make understandable. From there, her language needs a vocabulary that makes those concepts recognizable wherever they appear.

A language needs recognizable signs with stable meanings.

You might think of them as:

• Nouns: visual signifiers for orders, customers, articles, or projects
• Verbs: symbols and labels for adding, removing, deleting, publishing, or fulfilling
• Attributes and states: draft, published, paid, delayed, fulfilled, or critical
• Semantic roles: informational, cautionary, destructive, selected, or inactive

At Shopify, an order was most recognizably identified by its order number. A customer could be identified through a consistent customer symbol and name. These signifiers followed the resource wherever it appeared, helping merchants recognize it across different workflows.

The vocabulary also included consistent symbols and labels for common actions, distinct treatments for static attributes and changing lifecycle states, and semantic color roles for informational, cautionary, destructive, successful, and active states.

A product’s visual vocabulary creates recognizable forms.

But vocabulary alone can’t communicate a complete thought.

In Perez-Cruz’s model, stable signs solve recognition; grammar explains how those signs relate. That dependency is what turns a collection of reusable elements into a language capable of expressing a product’s structure.

After defining the vocabulary, you need to define how to combine it into meaningful compositions.

To me, this boils down to a basic question: what do you primarily use to create structure? Shapes, lines, or space?

The combination that you use depends on what relationships and information need to be understandable at a glance.

Those might include:

• Sequential relationships: steps in a workflow, stages of delivery, or progress over time
• Linked relationships: dependencies, inputs and outputs, or causes and effects
• Nested relationships: items within orders, files within folders, or variants within products
• Comparisons: choices, performance between periods, or a value relative to a benchmark
• Movement and change: work velocity, article engagement, momentum, or growth

Grammar describes the recurring visual structures used to communicate those ideas.

Perez-Cruz’s model lets a product’s personality grow from its own logic rather than decoration laid on top.

Have you ever walked into a fast food restaurant lit with overhead fluorescent lights and knew immediately that it might be a bad idea? Or if you walk into a slightly more upscale eatery with warm, incandescent light and it immediately feels inviting?

Creative technologist Jem Gold illustrates a similar phenomenon in UI design. There are mechanical specs about pixel values and hex colors. And there are guidelines for the experiential quality of the product.

Good design absolutely talks about feeling, atmosphere, taste, mood, audience, pacing, the embodied experience of arrival. But that work gets compressed too early into machine-readable implementation language. The moment a design intent becomes a token, the temperature drops out of it.

I keep coming back to this distinction:

Object-language describes the artifact. Warm neutral palette. Elegant serif typography. Subtle texture. Soft cards. Generous spacing.

Encounter-language describes the experience of meeting the artifact. Stepping out of your car into a eucalyptus grove. The taste of the pacific air in Mendocino. Golden hour sunshine kissing your forehead. Copal smoke wafting through a mountain cabin. The page has already exhaled before you arrive. A room prepared for attention. Clarity without sterility. Intellect without deadness.

The second kind of language contains more design direction. It carries sensation, mood, pacing, social meaning, and implied structure all at once. A single sensory scene can encode color, spacing, contrast, materiality, ornament, and density without naming any of those directly.

It is precise along a different axis.

That difference becomes real once models can turn atmosphere into visual form. Encounter-language gives the model a clearer target, but you still need taste to decide whether the result feels right. Gold extends the argument from direction to judgment:

The model generates possibilities, but taste remains in the loop as judgment. Does this still feel like the intent, or did it collapse into aesthetic costume? Only after a design tastes right do you derive tokens, typography scales, spacing rules, and component behavior. If our design specs only teach the model what the interface is made of, they have already forgotten what the interface is for.

Ageism in design is real. In my last job search a couple of years ago, I got zero callbacks. I landed a new role via connections.

What’s kept me sane and relevant has been curiosity. Tom May, writing in Creative Bloom:

One thing does need to stay sharp, though. As creative director Olivia Downing explains: “The secret sauce is you have to stay curious. About culture, about platforms, about all of it. You don’t have to be on social media, but I believe it’s our job to understand the importance and relevance of the medium.”