Luke Wroblewski gets at something that’s been gnawing at me for years: Figma as the source of truth gets stale as soon as it’s handed off. The code, the final user-facing screen in the browser or on their device is the source of truth.

I’ve seen the same pattern play out… design teams invest a lot of time in creating a system, then struggle to keep it up to date as the actual product evolves. Inevitably the design system ends up describing a product that no longer exists.

But now with AI agents, he argues, there’s another way:

When agents write most of the code, the design system can become part of what I’ve called the AI steering layer: the context that keeps every website update aligned with brand, design, and development guidelines. Put simply, a design system for agents is a steering layer for a site’s design and front-end code.

With AI agents, anyone on a team can update a website. Marketing adds landing pages, engineering adds docs, a PM tweaks the pricing page. Each of their agents will happily implement its own tone and voice, colors, spacing, etc. unless something steers them toward a unified whole.

That’s the case for collaborative steering. A design lead and front-end lead define the grid, fonts, colors, spacing, and components once, and everyone’s agents are “snapped to” it. The team keeps shipping and the site keeps its integrity.

Agreed. It’s DESIGN.md and other related brand, style, and design system context. Still need a design system though and shared components that live in the code.

I’ve long seen software development as the canary for AI. Mat​hia⁠s S​chäf⁠er details how the web dev education industry—books, courses, YouTube channels for building websites—has essentially been wiped out. Quoting developer/educators like Baldur Bjarnason, Salma Alam-Naylor, and Josh W. Comeau, there’s an air of defeated bleakness because people are turning to LLMs for answers and for coding itself.

Bjarnason says the “demand for web dev ebooks had cratered.” Alam-Naylor concurs, putting the blame on the training data used for LLMs:

The future feels bleak for educators. Rich curriculums we craft intentionally and carefully for real human audiences are now routinely stolen and regurgitated by predictive algorithms. The Chat Bots, with their sycophantic tone of voice, are deliberately engineered to erase our own personalities, hard work and craft entirely from the equation.

The only conclusion I can draw from this is that my experience, skills, empathy and teaching expertise no longer hold the value they once did in this volatile industry (if they ever really did?).

S​chäf⁠er spends 90% of his essay laying out how the industry’s been decimated. He tries to end on a positive, or at least, supportive note saying:

I just believe in a resilient web that is not that easy to lock in a cage. To rebuild the field of web development, it requires a network of people who support each other, get a grip on web technologies, dig out best practices and establish new ones, and share their insights.

Of course, this decimation is happening in other fields as well. Demand for freelance writing has dropped 30%. Translators have seen their jobs disappear. Chegg, the education company that rents textbooks and sells study help and tutoring, laid off 45% of its staff. I’d always imagined Dario Amodei’s bloodbath warning to be about hiring. It is, but it’s also about the shifting of work from humans to AI.

In other words, I’m not buying iStockPhoto credit packs anymore because I use Midjourney. So that part of Getty Images’s business suffers, leading to lower revenue and potentially layoffs. Or I use Claude Code instead of hiring a freelance developer on Upwork. All these decisions to shift tasks to AI lead to fewer humans doing that work.

Patrick Neeman, writing in UX Collective revisits the Double Diamond and design thinking. By going back into history, he argues why the Double Diamond is no longer relevant today.

The Design Council launched the Double Diamond model in 2004: two diamonds, problem then solution, both of equal size. Four years later IDEO’s CEO Tim Brown made the case in Harvard Business Review for Design Thinking as the process, putting designers and researchers at the start of innovation and at the start of the investment cycle, not the end.

Despite Fortune’s claim that IDEO invented human centered design — I even hesistate to link to it from here for obvious reasons—the movement started with Herbert Simon, whose 1969 The Sciences of the Artificial proposed the science of design thinking, and it was built out at Stanford, where Rolf Faste ran the design program before David Kelley took it to IDEO. The Design Council drew the shape for the other.

[…]

The lineage holds more names than Simon and Faste. Robert McKim published Experiences in Visual Thinking in 1972 while teaching at Stanford, Faste expanded that work into the 1990s, and Kelley founded IDEO in 1991. The first prominent book carrying the term was Peter Rowe’s Design Thinking in 1987, about architects and urban planners.

Notice what those people had in common:

• Simon wrote about engineering and administration
• Faste taught mechanical engineers
• Rowe was writing about buildings and urban planning
• None of them were building software

Every founding discipline made things that were slow, costly, and impossible to take back, and the method inherited their constraints along with their rigor.

That’s always been the crux: designers and designing is cheap; engineers and engineering is expensive. So spend more time on research and design before committing to coding the thing. But as Neeman writes, prototyping three things in an afternoon with AI is now trivial:

At that price [an afternoon] you stop debating which of three directions is right and build all three, because the debate costs more than the answer.

This gets at something I think a lot about from my time at Apple—creative selection, or exploring all the possibilities to discover the right solution. It’s now made a lot easier with AI.

As a young designer who was really into music, designing album covers was always something I really wanted to do. I had always admired the surrealistic work of Storm Thorgerson for Pink Floyd or the moodiness of Vaughn Oliver’s work for 4AD. I had fun in art school designing mixtape covers, but that was the closest I’d ever gotten to creating cover art.

Fast-forward to 2001 when Wilco released their now-classic album, Yankee Hotel Foxtrot. You know the cover, a mostly empty beige square with twin scalloped-sided towers rising from the bottom in black and white. That photo by Sam Jones of the Marina City apartment buildings in Chicago—the band’s hometown—combined with the lyrics from “Ashes of American Flags” indelibly captured the mood of America still reeling from the 9/11 attacks that happened two weeks prior. The band nor the album cover designer could have anticipated the coincidence.

Through twists and turns, the release of the album was digital at first. Wilco’s label rejected the album so the band left the label, negotiated to get the rights, and released the album themselves. They streamed it first on their website before being signed onto another label and having a retail release the following spring.

When I got the album, I pored through the credits and spotted the name of the designer: Lawrence Azerrad. I was pleasantly surprised and shared it with my colleagues at the time, for Azerrad, like me and most of my designer friends, was an alumnus of California College of the Arts. He was in my graphic design class.

Azerrad and I reconnected years later. For a design conference in Chicago that I was co-producing, we held a session at Wilco’s Loft, their home base and studio. Certainly one of my dreams come true!

What surprises me and what I admire about Azerrad and his work with Jeff Tweedy and Wilco specifically, is how much it’s not about him. I remember him telling me about sessions where he’d just set up his computer as the band was rehearsing or recording, and they’d jam while he designed. Tweedy would come in, give some feedback, and they’d jam on the design together. Rinse and repeat. The way Azerrad designs these covers, it’s more like he’s channeling the artist’s creative energy, and their collaboration is the output.

Rachel Cabitt recently interviewed Azerrad for the 25th anniversary of the album’s release. He says:

…as our connection to culture becomes more digitized, as AI plays a bigger role in our lives, and as discovering music and art through our phones gets almost effortless, it’s on creatives to find new ways to stretch toward deeper connection, to provoke more awe and wonder, not less. Because art, in all its forms, can get us to think more deeply about who we are, what we’re doing with our time here, and what we want to leave behind.

Right on.

Celine Nguyen, writing for Asterisk Magazine, questions the promise that taste will protect us from AI. She asks how we acquire taste and why we’d make economic survival its purpose. This is how she describes the tech industry’s view:

Taste, then, is that ineffable thing that makes you, and your business, irreplaceable. It separates the winners from the permanent underclass. It seems to be objectively measurable, or at the very least hierarchical, much like employee compensation or financial capital. To have good taste is to have more of it than other people. But to understand what taste is and how it’s cultivated, we may need to return to an earlier moment in history — when automation led to similar anxieties about human distinctiveness and economic competitiveness.

The promise depends on taste being beyond AI’s reach. Nguyen questions that premise: as literary scholar Leif Weatherby tells her, models already draw on human judgments of taste.

Her history of design education offers another approach. Britain responded to industrial competition by funding schools and museums. She describes how Bauhaus artist and educator Josef Albers taught at Black Mountain College:

The key insight of the Bauhaus’s foundation year was to treat aesthetic perception as a domain-independent skill — shaped by material literacy and craft knowledge, but not in thrall to a particular medium. But the foundation year that Albers brought to America wasn’t just about transmitting a single, preferred form of perception from teacher to student. Instead, students developed a shared “understanding of different ways of seeing and representing” through critiques “coming from the [other] students and then from the teacher.” (These critiques, Albers noted dryly, also “diminish[ed] the tendency to overestimate one’s own work.”) His approach encouraged students to sharpen their “intuitive perception,” and simultaneously practice conveying these perceptions to others.

Nguyen also describes how her interest in Belgian fashion informed her work designing software. She resists reducing those influences to status-seeking or imitation. By the end, she’s asking technologists to reconsider what cultivating taste is for:

Anxious technologists ought to free themselves from tyranny, but that doesn’t mean they need to give up on taste. They may need, however, to reconsider how they pursue it. Our tastes may be personal and idiosyncratic — but they are refined, by and large, when we relate to each other. Explaining our tastes is how we train our perceptual abilities, and our ability to participate in a pluralistic world. It’s a world in which our differences are energizing, not deflating: “The goal,” as the critic Carl Wilson wrote, “is not that we all end up with the same taste.” In an essay on musical taste — republished, years later, as a book with the seductively judgmental subtitle Why Other People Have Such Bad Taste — Wilson suggests that we learn to “relish the plenitude of tastes,” including when someone else’s tastes are “alien to our own.”

It’s true that our tastes can help with minor decisions: the music you listen to in the evenings, the shoes you buy when your Salomons wear out, and when to use an em dash (or, for the advanced aesthetes, an en). And they inform our larger decisions, too: what research problems to pursue, which films get screened, what startups get funded, what features you ship. But the lifelong project of training our tastes might serve a higher purpose than building a personal brand or profitable business. Our tastes are how we understand ourselves — and communicating them is how we understand each other.

Lightspark’s chief design officer Geoff Teehan, writing in Design Field Notes, traces the work that comes with adding a UI control:

By details, I don’t just mean the small visual decisions. Every feature, control, mode, state, exception, and bit of behavior becomes something a team has to design and someone has to understand. There’s only so much attention to go around. Same for time, taste, and patience.

A button seems harmless enough, but someone has to decide where it goes, what it says, what it looks like, what happens when you press it, what happens when you can’t, and what happens after you do. Add another and now you don’t just have two buttons. You have the relationship between them.

Teehan’s examples distinguish reducing that work from simply hiding controls. Teenage Engineering’s gorgeous OP-1 combines a synthesizer, sampler, sequencer, recorder, and mixer. It still takes practice to use. But its four colored knobs correspond to colors on the screen, giving the musician a consistent way to make adjustments across different functions. The colors do a job here. Removing them to make the instrument look simpler would undermine the relationship Teehan describes.

He closes with what a team can do when it has fewer details to maintain:

Removing something gives you time back. Time to reconsider the typography, rewrite three words, make an interaction feel right, move something two pixels, tune the sound, or notice what becomes annoying after the twentieth use.

Most people won’t notice any of it. Fine. They shouldn’t have to.

Minimalism isn’t the point. You can make something sparse and still make it bad. The goal isn’t to have the fewest things. It’s to have few enough things that you can care deeply about every one of them.

Peter Merholz, who has urged design leaders to connect their work to what the business values, is reconsidering that advice. A company can track the screens a team produces while overlooking the exploration that helped it choose what to build. That’s what he means by design’s “legibility gap.” He explains why predictable work gets recognized:

This is not some fault of design, but instead reflects the values of business operations. Organizations value predictability, so that they can plan, budget, and communicate likely outcomes to their stakeholders. Predictability requires determinacy, where the nature of the work (its processes and outputs) are understood ahead of time—engineering will take 6 weeks to work through these Jira tickets; marketing will spend $50,000 to draw this amount of traffic. Determinacy in turn defines legibility, the qualities of work that can be seen, appreciated, valued, and accounted for.

Much of UX/Design work is indeterminate, and thus illegible. Examples include:

• You explore four concepts and choose one. The three abandoned efforts are invisible, and you’re asked why you didn’t just start with the workable one.
• Research reveals the requirements were misguided, so you reframe them around actual customer need. The roadmap retains the same name, so it appears nothing has changed.
• You draft the experience principles that will inform hundreds of downstream decisions, but none of which will be traced back to them.

I’ve supported connecting design work to an existing metric, with the qualification that a number can’t capture everything design work contributes. Here, he’s reconsidering whether the business’s existing criteria are sufficient.

His warning comes from a forestry example: in Merholz’s account, clearing a forest for timber production destroyed the undergrowth and other life that sustained it. The first generation flourished, but the next collapsed. He applies that warning to design leadership:

This legibility frame illuminates a potent detail that had escaped me. Where in the past I argued that design leadership is about translation and connection (I have used the phrase “connect design to what the business values” countless times), the real work is subtler and actually much more difficult.

If we want UX/Design to avoid the fate of the forest’s second generation, the real work of leadership is to evolve what businesses see as ‘legible.’ We need them to widen their aperture to appreciate the value of indeterminate work, which is open-ended, exploratory, emotional, meaningful, even beautiful.

Merholz leaves the practical question open: how does a leader persuade the business to support exploration whose result can’t be specified in advance? An existing metric gives that conversation a starting point, but it can’t settle which unmeasured work deserves support.

And it’s a question that I personally continue to grapple with.

The apps are still there. Just a step away, hidden. You ask an AI personal agent to move an appointment or cancel a subscription, and it handles the software for you. Writing in Design + AI, Felix Haas describes what happens to the products that are hidden away:

Watching this happen has clarified something I’ve been thinking about for a while. We are witnessing a new step being inserted in front of every interface we’ve ever designed. In the last years, using software meant going to the software, opening the app, learning its layout, and navigating its particular logic. Now you increasingly interact with one interface that is connected to all the other interfaces, and the moment that layer works well enough, the interfaces behind it begin to fade from view. They don’t fade because they got worse, but because nobody is looking at them anymore.

That is what an invisible interface actually means to me, and it has nothing to do with minimalism or fewer buttons. It means that the interface of the product you built, the thing your team obsessed over and tested and polished for years, basically becomes a back-end, and its primary user is no longer a person but an agent acting on a person’s behalf.

Haas gives the underlying service a design requirement of its own: make its capabilities and current state understandable to the agent. Then he turns to the person delegating the task. They may skip the app’s navigation, but the agent now has access to their money and messages. That makes the handoff back to the person consequential:

So how do you design for trust when there is no interface to carry it? I believe it lives in three places. It lives in how the agent communicates, in its tone, its honesty, and its restraint, in whether it admits what it doesn’t know and asks before it assumes, because every sentence is now a design decision and the conversation itself becomes the brand. It lives in how you show what is happening on the other side, not through a wall of logs but through a considered kind of transparency, the reassuring feeling that the machine’s work is visible whenever you care to look. And it lives in the approval moment, that brief flash where an interface does appear right before an action is taken, carrying exactly enough context for a confident yes or no. As the interface shrinks, that moment becomes one of the highest-craft surfaces in all of software, because the fewer pixels that remain, the more each one weighs.

A cyberpunk toy-robot landing page gives Nick Babich a test case for the Design plugin in Claude Code. Writing for UX Planet, he starts with /design:design-critique this design, then uses the findings to request changes:

And the nice thing about doing a critique in Claude Code is that you can use a report that AI generated for you as an input. You can provide a follow-up prompt asking AI to fix the issues it found for you.

He narrows the next pass to the primary button with /design:ux-copy primary call to action button:

The great thing about Claude is that it has a project context. It means that it can use the knowledge it has about this particular product and business to find the right words.

Similar to the previous task, Claude generated a nice report with suggested text labels. I can also prompt Claude to change the call-to-action button text to the first option it suggests (Reserve a unit).

I’d check what the button actually commits the customer to before accepting that suggestion. A reservation is a specific promise, and the copy needs to match what happens after clicking.

Babich finishes with /design:design-handoff this design and a warning about what goes to engineering:

Similar to an AI-generated design critique, it’s not a good idea to use a design handoff file as-is without any changes. You need to review the file, validate the information in it, and only after that send it to the dev team.

Take ownership of what the AI generates.

Design educator Michael Buckley, writing for UX Collective, asks design schools to reconsider how they recruit students. He starts with what happens when those students get to class:

I see the mismatch most clearly when students reach the parts of a project that precede the visual work. They may be eager to design screens but impatient with research, resistant to technical constraints, or inclined to treat strategy as documentation to complete before the real design begins. Technology is sometimes learned well enough to operate but not well enough to question.

These reactions are not simply failures of effort. Many students entered the field expecting a professional outlet for artistic creativity. A discipline increasingly concerned with behavior, systems, evidence, and consequences can feel like a change in the terms of that promise.

An interest in making beautiful work is a good reason to study design. But students also need to learn strategic and systems thinking. The school owes them a description of the profession that makes those expectations clear. They shouldn’t have to discover the difference after they’ve enrolled.

Buckley brings the question back to recruitment and admissions:

Changing the curriculum without changing the recruitment pitch leaves that mismatch intact. Programs that present design primarily as a practical outlet for creativity will attract students who expect creative expression to organize the profession. Their frustration is understandable when the education they encounter reflects the realities of contemporary design rather than the false expectations that brought them to the field.

Design programs should therefore reconsider what they advertise and what they evaluate during admissions. A visual portfolio can remain part of the process without serving as the only meaningful evidence of potential. Applicants could also explain how they understood a problem, considered conflicting needs, or changed a decision after encountering new evidence. An imperfect artifact supported by thoughtful reasoning may reveal more than a polished portfolio organized around personal style.

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.