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

On a morning train, Aaron Horwath, writing in Noema about AI and knowledge work, watched a fellow commuter spend over half an hour talking through financial metrics, including margins and cost structures. Then the man pulled a pair of knitting needles from his bag. He was making a pink winter hat for his niece, and Horwath noticed a glint of pride and excitement.

The hat was more than an escape from work. It was tangible, made by his own hands for someone he knew. That contrast gives Horwath’s essay its real subject. AI job anxiety is the backdrop; the deeper rupture comes when abstract corporate work loses its remaining sense of participation and ownership.

Knowledge work’s one saving grace, until recently, was that it was still executed by humans. We were needed. It was flesh-and-blood humans who sat down to work through a challenge, built the slide deck, wrote the customer response and developed the strategy. Even if it was existentially meaningless, there was human thought, collaborative work and creativity poured into that work, giving it life.

Now, AI agents are increasingly executing much of that work for Knowledge Workers. It is common for people responsible for integrating these tools into their organizations, myself included, to describe the future of work as one in which all humans will essentially be managers of armies of AI agents. That seems pretty great. Let the software compile the reports, chase down the data, format the deck, draft the first pass of documentation and handle the dozens of small, repetitive tasks that used to quietly eat an afternoon. But in many cases, employees under pressure from leaders to produce more are using AI agents for far more than grunt work: formulating complete business strategies, generating full marketing campaigns, building entire websites, drafting strategy for whole divisions of an organization. From a single email to an entire corporate strategy, the outputs of individuals, teams and organizations are increasingly generated in an instant by AI.

Horwath distinguishes between using software to remove drudgery and using it to remove the process through which people learn together and take responsibility for what they make. In design, critique and mentoring can look like bureaucracy, even though they are how designers develop judgment and ownership of a decision.

Research suggests this group needs that environment to do their best work. Harvard Business School’s Teresa Amabile spent decades studying what produces genuinely creative, high-quality output. Her Intrinsic Motivation Principle determines that people do their most creative and innovative work when motivated by the work itself — the interest, the challenge, the enjoyment — not by outcomes or metrics. The environments that kill creativity are political, risk-averse and relentlessly outcome-focused. The environments that stimulate it are collaborative, idea-driven and free. The messy middle, in other words, isn’t inefficient. It’s the condition under which genuinely valuable work gets produced.

It’s important to note that the impact of removing the messy middle from the work experience of these two groups is asymmetrical: For outcome-first people, it is a victory. For experience-first people, it undermines the foundation of work.

The messy middle carries more than delay. It is where people argue, teach, notice, revise, and become accountable to one another. Automating production can be a gift. Automating away every encounter that nurtures ownership may push workers away.

The knitted pink hat reveals what efficiency metrics miss: people care about work they can recognize as their own and connect to another person. For design teams, the risk is faster production with fewer chances to develop judgment together.

Dan Maccarone, product strategist and co-founder of the design studio Charming Robot, draws a line between what expertise can be documented and what must still be learned through first-hand experience:

The move nobody makes: run both plays on purpose. Structure what you can, and still teach it to a person.

The trap is thinking you have to choose between them like my co-founder clients. But you don’t. The better move is to run both plays at once, on purpose: write down everything about your judgment that will survive being written down, and build the apprenticeship for everything that won’t.

Start with the writing-down, because there’s a catch everyone hits. Getting your judgment out of your head isn’t the same as dumping your files into Claude. Do that and you get mush. The model grabs the loudest thing you’ve ever said and hands it back with total confidence.

In design, AI guardrails can store the reasoning, conditions, and exceptions behind a product decision. Apprenticeship gives people decisions in context through critique and design reviews, where correction becomes pattern recognition. Reading the expert’s answer is not the same as learning how to arrive at one.

Trust it like you’d trust a very sharp new hire who’s read everything and lived nothing: useful, fast, and occasionally, cheerfully, wrong.

Maccarone’s prescription is to document the method and pair it with apprenticeship, so people learn when to use their own judgement.

Andy Budd, Clearleft co-founder and longtime design leader, argues that AI may make design organizations smaller while making some design roles larger. His bull case is that designers who can move across product, craft, commerce, and implementation gain agency instead of getting stuck in production hell.

The best designers start to look less like traditional product designers and more like hybrid product leaders. They still care about interaction, hierarchy, language, flow, brand and craft, but they also understand the commercial shape of the problem. They can make trade-offs. They can prototype in code, or close enough to code. They can use AI to explore options quickly, then use judgment to throw most of them away. They can sit with a founder or PM and move from a vague product concern to something tangible by the end of the day.

Budd on the bear case and the danger of plausible design:

The problem is not that these people will suddenly become great designers. The problem is that many companies do not know the difference between great design and plausible design. Plausible design is dangerous. It looks coherent in a product review. It uses the right components. The spacing is fine. The copy is not embarrassing. The flow mostly works. Nobody in the meeting feels strongly enough to object. So it ships.

Budd’s point is that these outcomes can arrive together: cheaper execution can expand the role of designers while giving companies that never valued design a faster route to mediocrity.

Matt Shumer, writer of the viral “Something Big Is Happening” essay, argues that most agent workflows try to prevent mistakes by specifying every move. His Gauntlet Loop takes a different approach: define what good looks like, then let the agents decide how to reach it.

You give a lead agent a goal and a real example of what great looks like. The lead agent decides how to break the goal into the smallest pieces that can be improved separately. Each piece gets its own builder and a separate critic with fresh context.

The builder makes something. The critic compares it against the reference example. If the reference example wins, the critic explains the biggest remaining gap and sends the work back to the builder. The builder fixes it. Then another round begins.

That continues until the result reaches the bar (or, more likely, you decide it is ready).

The agents get specificity about the outcome, not a recipe for producing it. On a design team, one agent could decide how to build a prototype while a fresh critique agent—Shumer calls them critics—compares the result with a reference and an explicit quality bar. Shumer separates the critic so freedom in execution does not weaken the judgment:

The builder and critic should be separate agents.

The builder has seen every decision it made. It remembers why it made them. That makes it very good at explaining why its work is reasonable.

You do not want reasonable. You want an independent judgment.

Spawn a fresh critic and give it the goal, the bar, the relevant rules, and the actual artifact. Do not give it the builder’s history or explanation.

Smarter agents can work with fewer procedural rules when their output remains inspectable. Shumer puts it into practice with a goal, reference, artifact, and independent review.

I’m am a pretty big Star Trek fan. As any good GenXer, I grew up with Star Wars, but I loved and still love the Star Trek universe. It just tickles the nerdier side of my brain.

I love this essay by Patrick Neeman exploring how Star Trek correctly predicted aspects of modern AI.

Neeman:

Star Trek’s track record is a design brief, not a trivia game. The lesson is not that the writers were psychic. It is that they reasoned about interaction and consequence, and those reason forward better than hardware guesses do.

• Design the conversation before the capability. The Trek computer worked as an idea because the interaction model was sound long before the intelligence was. Get the way people ask and receive right first, and let the underlying capability catch up to a surface that already makes sense.
• Treat plain language as a real interface, with real failure states. Natural-language input is not a magic layer that removes design work; it moves the work to disambiguation, confirmation, and recovery. Design what happens when the system mishears as carefully as when it hears.
• Show your seams on translation and transcription by design. These systems are mostly right, which is the dangerous kind of wrong. Surface confidence, make correction cheap, and never present a probabilistic output as settled fact.
• Put the consequence questions in the review, not the retro. If a feature optimizes for a metric, ask early what it does when it optimizes too well. The show’s warnings all came from goals specified narrowly and pursued faithfully.

“Plain language as interface” is happening all around us. We are now coding by using plain language. We’re designing using plain language. The chatbox has been derided as a terrible interface for AI by skeptical designers, including myself. But I think it has staying power precisely because of its support for plain language.

In Jason Lemkin’s account of SaaStr’s break with Adobe Marketo, the formal cancellation is almost beside the point. SaaStr had already moved most of Marketo’s work elsewhere:

And once you do that once, you start asking the obvious question. We’ve now migrated almost all of Marketo’s functionality onto Salesforce. Not because Salesforce has better features. Because Salesforce has an API our agents can actually use. One day you look up and realize you’re paying $60K a year for a product you’ve already routed around.

That is the new B2B churn motion. It isn’t a feature bake-off. It’s an agent-operability test, and legacy vendors are failing it quietly, one migrated workflow at a time, before they ever show up on the churn report.

I do think this is where a lot of software, especially B2B software is headed. Even in my own day-to-day, I’m loathe to use tools that don’t allow me to connect to one of my AI agents. Zoom out to an enterprise context and now agent operability becomes a product-quality problem that can eventually lead to churn.

Lemkin’s advice:

If you build or run a B2B company, the Marketo story is a checklist of what not to become.

Make your product operable by an agent, now. Not next year. The question is no longer “is our UI good.” It’s “can a customer’s agent do real work against our API without a human babysitting it.” If the answer is no, you are already on a churn clock you can’t see. Webhooks, an SDK, an MCP server, clean auth, real history. This is table stakes in 2026.

Judgment and craft may help a designer survive today’s freelance market. But Madeleine Morley, writing for Fast Company, gives us little reason to believe that either would guarantee economic security.

She interviewed Cari Sekendur, founder of the independent branding and web-design studio Butter.

In Fast Company ’s report, more than half of designers surveyed believe AI is undercutting their rates, and 68% believe it is eroding the value of human creativity.

“Clients now expect more while paying less,” wrote one survey respondent on AI’s effect on the industry. “Many clients are taking advantage of AI to underestimate our professionalism and pricing,” said another.

Morley writes that only 22% of survey respondents reported losing work because of AI. But the lowish number hides a sense that “AI isn’t replacing design, but it is changing how clients perceive it.” A designer can keep getting hired and still lose leverage over what the work pays and demands.

That pressure isn’t distributed evenly. She describes what has happened among illustrators doing smaller jobs:

Eric Carter, an illustrator whose clients include The New York Times, believes the disruption has been most acute at the lower end of the market. “There is this whole gig economy of illustrators doing smaller jobs,” he says from his studio in Los Angeles. “Fiverr was already cheapening everything… the bottom was already pretty low. And then having AI replace that, it just cut it out.”

Carter has been insulated from that shift because, as he puts it, “I get paid to think.” This idea—that a designer’s value is increasingly about their taste and approach as opposed to pure craft or technical ability—reverberates throughout the freelance industry. “You can’t automate taste and creativity,” one survey respondent wrote. Another: “Ideas and taste is what is needed to succeed.” And another: “AI is only as good as the strategy and input.”

Carter’s “I get paid to think” is encouraging, but it comes with a nasty condition. Judgment and recognizable craft offer more protection when clients already know whose judgment they’re buying. I wrote about the same trap in my series on the design talent crisis: entry-level work is how designers develop and prove their judgment, yet it’s the first work the market is stripping away.

Morley concludes:

What is evident across the survey data and multiple interviewers is that the labor of design is increasingly fragmented in today’s creative industry. Designers are forced to sell their labor in multiple markets simply to maintain the same standard of living that they used to and the market is not compensating highly skilled creative work in the way it did even a few years ago.

All of this raises bigger questions. For many years now, the freelance creative has been not only someone who simply sells their craft, but an entrepreneur expected to market themselves and build a personal brand. Diversification and resilience are emerging as absolutely vital and central capacities for freelancers navigating the age of AI. What gets lost in the urgent need to find sources of income and to adapt are questions like: Shouldn’t clients pay more? Why are corporations cutting budgets? The burden, as always, shifts to the individual.

Creativity researcher Keith Sawyer described art and design school as a place where students learn to see their own work: they bring unfinished work into critique, hear what others see in it, and practice identifying the gap between intention and result.

David Hoang turns that studio lesson into exercises early-career designers can continue long after school:

To train the eye, spend time doing three things: Capture, Collect, and Curate. To Capture, bring the tools that work best for you: a physical notebook, camera, recorder, or phone. As you walk around, travel, read a book, or surf the internet, Collect what matters. The point isn’t volume but discernment. I keep folders on my Mac for interesting textures, color palettes, fonts applied in the wild, and shapes found in nature. Finally, Curate what you captured. Don’t bury it in a Photo Library with tens of thousands of images. Put your observations somewhere you can revisit daily. Print them out or make a mood board. Whatever you choose, give your trained eye the proper attention.

Hoang then moves from observation to making. He recommends rebuilding strong interfaces from scratch, with the original on the canvas beside your work:

For interface designers, my recommendation is to copy from the masters. By copy, I don’t mean taking a screenshot and putting it in Codex or cloning from a UI library. Look at the work and reproduce it in your UI drawing tool. Put the screenshot on the canvas and reconstruct it from scratch. As you do this, note the margins, spacing, and font sizes. Ask why they work. What deliberate decisions produced this output?

And designers have to explain those decisions. Hoang treats critiques, presentations, and written rationales as more practice because each forces intuition into words. All of it feeds the same loop:

Experience isn’t time spent; it’s evidence of what you can do. The proof of work comes first. Design intuition can feel mysterious because the reasoning behind it becomes difficult to see. An experienced designer may recognize that something is wrong before anyone can explain why.

Edward de Bono argued that creativity isn’t an innate talent but a deliberate skill anyone can develop. I believe this, but it requires rigorous training.

This is why the repetitions matter. Every time you notice a pattern, reconstruct an interface, study an aesthetic movement, or defend a design decision, you give your intuition more evidence to draw from. Over time, the distance between seeing, understanding, and making gets shorter. Your eye begins to match your hand, and your hand begins to keep pace with your judgment.

Intent is one of my go-to coding workspaces. By default, it’s spec-driven and uses swarms of agents to execute the work, with a brainy orchestrator agent coordinating it all.

Ryan Mather, interviewing the product lead for Intent, designer-developer Amelia Wattenberger for AI Design Field Guide, asks how she designs when software behavior itself can change:

It’s a new dimension in which apps can be dynamic. We had image maps exported from Photoshop with a certain resolution, and then we were like, “wait, screens are going to be different sizes — this isn’t going to work anymore.” So we needed layout algorithms. Then users could interact and change what’s on the page — so we made them dynamic through time. Users had preferences — so we made them dynamic based on the user. And now there’s an additional dimension where even the app behavior itself can be completely changed - custom to you.

So designing now is a dance of, what are the primitives to add to the structure? Are we using bricks or another building block? And then the user can fully configure the app’s behavior, which I think is the only way to build a product now. Otherwise it’ll be stale in five months. Someone else will build a new app that does something around the workflows that people want.

Stable application chrome can provide continuity. In configurable software, Wattenberger locates that continuity in the objects people use to compose a workflow: the workspace that contains a task, the spec that humans and agents edit, and the subtasks that make delegation visible.

She describes what happens when those objects disappear:

I think about a straw that’s really bendy, and someone trying to do a thing with it — it’s just not a very powerful thing. Or clay — you can’t build super big things with clay, and you can’t go really quickly, because it’s infinitely moldable. Anything that’s generic is the jack of all trades, master of none. If you want something really powerful, you need some structure there. You need bones, you need muscles, some affordances. You can’t just be like, “oh, it’s a pile of goop, and stuff arises from the goop, that’s not what we all want.”

Mather then asks how far configurability can go. Wattenberger:

I have a feeling that applications as a paradigm will not last much longer, at least as the main way we interact with computers. Things will be way more modular and definitely decoupled from the data. There will also be a strong remix culture, because people don’t want to create everything they want from scratch, but they also want the ability to customize the things they use. So things are going to get super wacky.

OpenDoc, for example, imagined documents as containers for live, editable components supplied by different tools, rather than files owned by a single monolithic application. Computer scientists have been chasing variations of this modular model for years. AI, and the capabilities it gives users, adds a new dimension: the behavior of the application itself can now be remixed.

The startup grind is often the same: ship fast, but maintain a high bar of quality. At least that’s the sentiment. Those things are in opposition and the system incentivizes people to just move on.

Miguel Fernandez, writing for Slack Design, describes why shared standards matter:

Craft is subjective, until it isn’t. Disagreement surfaces the moment you have to define it. Is this interaction good enough? Is this component polished? Without shared standards, these discussions become battles of personal taste rather than principled decisions. You can’t argue craft in a document. You can only experience it.

That makes the quality bar a cross-functional working agreement rather than a designer’s private standard. Fernandez continues:

It seems like craft competes with velocity. Engineering and Product are often rewarded for shipping, not refining. Craft requires slowing down at key moments, which feels costly when measured against sprint commitments. The incentive systems work against craft, but this is a false trade-off: craft debt compounds just like technical debt, and eventually you pay for it in churn, reputation, and the slow erosion of what made your product special.

Fernandez then quotes Linear co-founder and CEO Karri Saarinen on the conditions beyond the individual:

“Craft is the mindset that creates quality. But it’s not enough. You need to have the right skills and ideas. You need individuals who take their profession and craft seriously, then build teams that work this way together, and have a company that creates the conditions for it. Not only incentivizing with deadlines and metrics, but also caring if the experience is good enough.”

At Apple, my boss Hiroki Asai, then the VP of Graphic Design, often gave me the same feedback: “This needs to be more considered.” Meaning, spend more time with it. Keep your quality bar high.

That memory came back while listening to Michael Riddering interview Charlie Deets, a former Safari designer now working on Dia, on Dive Club. Riddering:

It’s that extra loop and practice of consideration that I find often is the only way that I can get to simplicity.

I might have the right idea as my knee-jerk reaction. Like we put in a lot of reps, like that’s not uncommon for me. Sometimes I return back to the idea.

But then knowing that this is directionally correct, but then going through it one more time and say, “Okay, how what can I distill or cut or combine?”

Deets connects Riddering’s extra loop to Apple’s willingness to interrupt its own momentum:

Yeah, this is something I think Apple just does better than anyone else, and I think it’s partially because of sort of this one-year release cycle thing. At any point in that cycle you can say, “Is this really the right way?” And you can go back to the beginning.

And people almost are expect that disruption as part of the process. Like it’s very much part of the process to just say, “Actually we’re on the wrong path. Let’s start over from this position.”

Reopening the work also asks something of the team. Deets again:

And I think that requires a lot of confidence and it requires a lot of low ego or something.

That was Hiroki’s lesson, too. “More considered” meant that the work could be further iterated upon.

Quotes lightly edited for clarity.

Album-cover and gig-poster artists capture the feeling of music while building a visual identity around it. I respect anyone who can pull off both.

Paul Moore, writing for It’s Nice That, talks with artist and album-cover designer Robert Beatty about old versions of Photoshop, scavenged technology, imperfect memories, and the unexpected contrasts in his work. Beatty’s approach to working with musicians gets at the translation involved:

Honestly there’s not really a huge difference in the way I approach things based on the genre of the music, it’s more what the artist is trying to accomplish or get across than the way it sounds. It’s often the way the artist communicates their ideas or aren’t able to that really informs the way I approach making album artwork. It’s definitely rare that a musician has as much understanding and articulation when talking about visual art as they do music, which is I guess why people come to me to help figure out how to convey their music in a visual medium. I don’t know if having an understanding of both music and art really changes the way I make art for music, but I approach them the same way with a very improvisatory and open mind. And sometimes it’s the contrast between the music and the art that makes something interesting.

That contrast leaves room for the image to carry the music’s mood without illustrating the sound literally. Beatty describes the response he’s after in one line:

I’m trying to make something that works on an almost primeval level.

I love that idea: style can draw you in, but the image still has to connect before you’ve decoded its references. Moore’s full interview with Beatty also covers creative friction and making videos that move with music rather than simply decorating it.

Paul Bakaus says he helped turn Impeccable from what he calls a “vibed personal skill” into a design toolkit. He says hundreds of thousands of designers and developers now use it. Three of his techniques show how much of that improvement came from engineering around model behavior instead of polishing a prompt.

The first is “Make them argue · two blind reviewers beat one confident guess”:

For a concrete example, /impeccable critique, Impeccable’s design review command, runs both deterministic checks against your code (to detect stuff like low contrast quickly and decisively) and reviews the design like a human would. But early versions had a major flaw that produced bad critiques: hand the LLM the detector output up front and it skews BOTH ways:

1. detector noisy → condemns a strong page over fixable nits (false alarm)
2. detector silent → rubber-stamps a generic page (meaningless clean bill)

To debias, critique now spawns two sub-agents that never see each other’s work: A = an LLM design director (hierarchy, slop, heuristics), B = the deterministic detector + browser evidence. When the sub-agents finish, the main agent synthesizes (weave, never concatenate) the results from both for a balanced critique. Two blind opinions beat one confident guess.

I agree with the architecture. Review independence matters as much for agents as it does for human teams; the reviewer needs a perspective the maker didn’t already shape.

Bakaus’s second technique is “Force divergence · escape the cluster, don’t chase it with bans”:

Bans just move the model from one region of latent space into another. The escape is sideways, not a longer denylist.

Here are three techniques that produce higher divergence (cheapest but weakest first):

1. Shave the safe picks: make the model name its top 3 fonts, then discard all three. Out-rank yourself.
2. Generate ~50, a blind sub-agent keeps the 5 most distinct. (Lives in Radiant’s codebase, not Impeccable yet.)
3. Seed from outside the model: palette.mjs --from 8f2a starts in a region the model never picks on its own.

This is a better response to repetitive AI aesthetics than accumulating another denylist of fonts and visual effects. The intervention changes the candidate set instead of pleading for a better choice.

The third is “Give them memory · runs that compound instead of restarting”:

Most skill authors treat skills as stateless prompts, but there’s no rule that says a skill can’t have state. Keep in mind that skills can be bundled with scripts that can be run anywhere during the lifecycle of the skill!

Impeccable’s critique and polish commands use this technique quite effectively:

1. /critique writes a snapshot per target (score, P0/P1, markdown + frontmatter)
2. /polish reads the latest snapshot as its fix backlog

One non-obvious detail that makes this work across a team: the snapshot slug comes from the resolved file path, not from how you phrased the request. A teammate pointing at the same file inherits the same memory, and the score trend (24, then 28, then 32) survives across sessions.

This one is immediately practical: save the work on disk, then let the next command pick it up.

If you’re configuring agents for product and design work, start by cleaning up their context. Anthropic’s Thariq Shihipar offers several recommendations; three are especially useful here:

First, replace blanket prohibitions with an instruction that lets the model read the code around it:

In the new system prompt we say: Write code that reads like the surrounding code: match its comment density, naming, and idiom.

That trades a brittle universal rule for a concrete standard the model can inspect.

Second, move specialized guidance out of the always-on context and load it only when the task calls for it:

Since then, Claude Code has gotten very competent at using progressive disclosure- loading the right context at the right times. For example, we moved verification and code review into their own skills that Claude Code could selectively call.

For design and product agents, that leaves room for richer task-specific standards without crowding every session with irrelevant rules.

Finally, Shihipar on what belongs in CLAUDE.md:

Keep your CLAUDE.md lightweight and briefly describe what your repo is for, but spend most of the tokens on gotchas inside of the codebase. For example, you may organize your code to keep types in one monolithic file and nowhere else. Avoid stating ‘the obvious’ things Claude should know by looking at your file system or your repo.

Use progressive disclosure heavily, for example if you have several unique instructions on how to verify your work, create a verification skill and reference it from your CLAUDE.md.

Product designer and UX Planet editor-in-chief Nick Babich describes software development shifting from production to direction. The design version is familiar by now: as interface production gets cheaper, the work beyond the artifact is defining the right problem, directing agents, evaluating output, and owning the result. Babich traces the same shift in software:

Software development as manual code production is dying.

Software development as translating detailed tickets into predictable implementation is dying.

Software development as a protected technical craft that non-programmers cannot access is dying.

But software engineering is evolving into something broader:

Problem definition + architecture + agent orchestration + verification + product judgment + accountability

This changes the role of the developer.

The most valuable skill is no longer the ability to write code.

It is the ability to define the right problem, provide agents with the right context, evaluate their decisions, and verify that the final result actually works.

Software developers are becoming software creators.

I agree. Replace code with interface production and developer with designer, and Babich could be describing our profession. But there’s a problem both fields share: judgment is built by doing the low-stakes work AI now handles.

Junior developers were historically hired to complete simple implementation tasks such as:

• Build a basic interface;
• Write repetitive tests;
• Fix small bugs;

and these tasks allow them to learn from experienced colleagues and grow professionally.

But in 2026, these tasks are precisely the tasks coding agents handle best.

The loop engineering theme explained how to replace turn-by-turn prompting with a system that discovers work, assigns it, checks the result, and remembers what comes next. AI engineering writer and former Google engineering leader Addy Osmani scales that idea into a software factory and adds the governing constraint: the work can move only as fast as humans can review it.

A software factory is many harnessed loops running at once, fed by a queue of work and drained through a review gate into production, with humans owning the whole thing from above. It is not a bigger agent; it is an org chart made of loops.

Osmani follows that definition through the factory’s wiring diagram:

By and large, every box in this diagram is almost zero cost: generation, tests, scanning. They all run at scale for negligible cost. There is only one expensive box that proves stubbornly resistant to scaling, and that’s the review gate. That shiny amber box is “judgment”, and where the crux of the argument about whether we can make development faster and more frequent resides.

For Osmani, the review gate sets the pace. More generation only helps when verification scales with it; otherwise the factory manufactures a queue of code no one has the attention to understand. Imagine a conveyor belt of products being assembled together, only to pile up at the end, waiting for a poor human quality checker.

Osmani turns that constraint into architecture:

You might be thinking that all sounds unglamorous. You’re right. The safety net is made up of perfectly ordinary architectural practices we’ve always known about and mostly ignored: good types and method signatures so that mistakes are caught by the compiler instead of in production; test seams where we can pin behavior and make change observable; laying out the code so the next reader, human or model, knows where to find the thing they care about; keeping call stacks short and legible; keeping component boundaries well defined so a change doesn’t have a huge blast radius; and dependency injection so we can swap out one piece for another. None of it is new. We’ve always said we care about good architecture. But now that we’re using automated coding agents, that architecture is finally doing a second job as a cheap and hard-to-fake safety net against the mistakes the agent will make.

Put plainly, structure the work so mistakes are easy to spot and changing one thing doesn’t break everything else.

For designers, that means clear rules for each component, documented states, testable prototypes, and explicit review criteria. Build loops that can keep moving without you, but let them move only as far as those checks can prove the work is sound.

Kate Conger, writing in The New York Times, shows how Google’s AI Mode can include links to the open web while making them mostly irrelevant. The product gathers information from other sites, assembles an answer, and keeps the user inside Google. That goes beyond the earlier drop in publisher referrals linked to AI Overviews: Google is reconstructing the trip across the web inside its own interface.

Conger starts with Google co-founder Larry Page’s 2004 promise and the bargain that made Google powerful:

“We believe a well-functioning society should have abundant, free and unbiased access to high-quality information,” Mr. Page said.

Google fulfilled that responsibility by acting as a gateway to the internet. It answered people’s search queries with lists of hyperlinks, pushing users out to what is known as the “open web” — the millions of websites run by merchants, publishers, universities and others — for more information. In the ensuing decades, Google became one of the planet’s richest and most powerful companies by directing people to the vastness of the open web.

Now in the age of artificial intelligence, Google appears to be shrinking back from the open web — and may be imperiling it.

That enclosure is a product behavior, not a login requirement. Conger gives a simple example:

While someone might once have Googled a soccer player’s World Cup performance and clicked to a sports site or a social media thread for commentary, a bot now crawls the web for that information and returns the player’s statistics to the user, who stays on Google.

Google says it still sends billions of clicks and highlights links to the web. But those links now compete with an answer designed to remove the need for them. Conger ends with the contradiction:

In May, Vox Media, which owns The Verge and other publications, began selling some of its sites. Jim Bankoff, Vox Media’s chief executive, said the “decimation of search traffic” had influenced his decision to explore other ways of reaching readers, like a podcast network, and ultimately to sell about half of the company to James Murdoch. In June, The Verge and several other Vox Media websites were sold to Penske Media.

Google has often said it was “sending out more traffic and the web is bigger than ever,” Mr. Patel said. “And then right next to that is a bunch of publishers whose businesses are getting destroyed.”

I’ve started using AI this way in a lot of my daily work. In my day job, after diving into a problem, I give Claude the right context and iterate with it to get to a problem brief. In my freelance work, I set the parameters—the concept, style, or general functionality—then iterate with the AI.

AI product manager and builder Karo Zieminski, writing in Product with Attitude, calls this “AI-assisted craft”:

AI-assisted craft means the human sets the intention and the standard for the work, then directs how it gets made. AI gets a defined supporting role. Supporting, as in: it does not get to make the decisions. The practice applies across knowledge work and digital creation, from writing and research to coding and design.

Zieminski separates assistance from direction:

AI-assisted. The human is the primary maker. The choices, mistakes, revisions, and final form are theirs. AI is one of the tools they use.

AI-directed. The model produces the work; the human directs it. That direction must be consequential enough to shape the result. One prompt followed by a shrug is generation with supervision theatre.

Both require the human to make consequential choices. In my workflows, that happens throughout the iteration, not only when I write the first prompt.

Zieminski’s bounded-task rule makes that concrete:

“Improve this” is not a bounded task.

Give the model a job with sharp edges: do this, not that.

Research for me, BUT bring me facts, not conclusions. Challenge my assumptions, BUT do that through Socratic questions so I have to do the thinking. Explain this code block, BUT test whether I understood it. Suggest design fixes BUT don’t bleach my personality out of it. Whatever it is, leave space for my judgment.

I agree, with one small addition: setting the boundary starts the work. AI can’t answer the question at the other end for me: Would another change improve it, or is it time to stop asking?

Companies may be cutting the very workers AI helps most.

A Stanford Institute for Economic Policy Research policy brief by Neale Mahoney, Erika McEntarfer, and Karsen Wahal finds no economy-wide “AI jobs apocalypse.” But its early evidence creates a possible paradox: employment among less-experienced workers has declined in AI-exposed roles, even as experiments show that AI often gives them the largest productivity boost.

Recent graduates are facing the most challenging job market in years, with unemployment rates for new grads reaching 5.6 percent in early 2026, up 1.6 percentage points from three years earlier. This rise has fueled concerns that AI is replacing many of the jobs recent graduates once sought. Junior roles often involve routine research, analysis, and writing tasks that can now largely be done with AI. Consistent with this intuition is empirical evidence that AI may be dampening demand for new hires.

In a widely discussed paper, Brynjolfsson, Chandar, and Chen report a notable decline in employment among early-career workers in AI-exposed occupations, notably software developers and customer service representatives, since ChatGPT’s launch in 2022. As shown in Figure 2, by contrast, employment among older workers in those same occupations remained relatively stable or continued to grow. The authors liken these young workers to “canaries in the coal mine,” the first to experience labor market disruption from AI. Other researchers have since identified similar negative effects on the hiring of young AI-exposed workers in the U.S. and the U.K., beginning in 2022.

The authors are careful not to pin the entire decline on AI. The Federal Reserve’s rate hikes, the end of pandemic staffing surges, and weaker on-the-job learning in remote roles all muddy the timeline. But the hiring decline itself is real, and younger workers in AI-exposed jobs are taking the hit.

Design’s vanishing bottom rung looks even more precarious against this evidence. The brief does not study designers specifically or establish that AI caused the decline. But if employers are closing junior roles in anticipation of AI, that is a business decision, not a technical inevitability. And the productivity findings make that logic even stranger:

In experimental settings, generative AI tools — such as chatbots and coding tools — have often been found to disproportionately improve the performance of less experienced and poorer performing workers. In one such study, researchers analyzed the impact of a generative AI assistant on customer support agents in a large call center. The assistant increased overall productivity by 15 percent, with gains highly concentrated among novice and less-skilled workers, who saw a 30 percent improvement in the number of issues resolved per hour. There was no performance improvement among highly skilled customer service agents, whose response quality fell slightly.

Other studies also show that AI tools generally speed up task completion, though the effects vary by task, context, and skill level. Figure 3 summarizes research findings on the impact of AI tools on speed across a variety of tasks. In software development, the use of GitHub Copilot — an AI tool that suggests code and functions — allowed tasks to be completed 56 percent faster, with gains concentrated among less-experienced programmers. More modest impacts on software development were found in a separate paper, with effects ranging from 10 percent to 30 percent, depending on the firm where it was deployed.

If companies stop hiring the people who benefit most from these tools, who exactly do they expect to become tomorrow’s senior talent?

Experience is usually treated as an advantage, as exemplified by Google product leader Jules Walter defining what product sense is in Lenny’s Newsletter:

Product sense is the skill of consistently being able to craft products (or make changes to existing products) that have the intended impact on their users. Product sense relies on (1) empathy to discover meaningful user needs and (2) creativity to come up with solutions that effectively address those needs.

Quoting Walter, Tanner Kohler, a researcher at Nielsen Norman Group, argues that it can become a trap when the current problem only looks familiar. He contrasts his definition of product sense with Walter’s:

Product sense is the ability to recognize when current problems match past successes or failures and reliably estimate how similar solutions will affect the desired outcomes.

[…]

This definition improves on Walter’s because it turns product sense from a loose combination of empathy and creativity into a measurable decision-making skill. It specifies the mechanism behind strong product judgment: recognizing when a current problem resembles past successes or failures, predicting likely outcomes, and knowing when those comparisons are reliable. That makes product sense easier to recognize, practice, and improve.

Pattern recognition gets most of the credit when we talk about senior judgment. For designers, calibration means knowing when a pattern that worked before no longer fits the problem in front of you.

Kohler then limits where experience can be trusted:

Our definition requires people with strong product sense to know both when an experience-based pattern is likely to work and when it is not. That judgment is the “sense.” It is not magical, does not come automatically with time, and remains limited to a person’s domain of expertise.

Consider a fire chief experienced with small building fires advising a crew during a skyscraper fire, a NICU nurse caring for an adult patient, or a chess grandmaster playing checkers. Do the cues they learned in one domain still apply?

Daniel Kahneman and Gary Klein point out that any new decision-making environment needs to provide sufficient familiar clues for an expert to accurately match the patterns they’ve learned to the current situation.

Kohler warns that AI can also interrupt the decision–implementation–measurement–reflection loop that creates those patterns:

Buzzwords come and go. There’s nothing wrong with the term “product sense.” The problem is believing that, with little data, an ever increasing velocity, and more work and decision making outsourced to AI, people can develop a “sense” for what to do without rigorous thinking.

Intuition comes with time and repeated exposure to real product decisions and results. AI may rob you of the chance to develop product sense if you aren’t careful. Stay in the ring, own your decisions, and face the results. This is what will make you valuable for years to come.

Most software companies organize product work around squads. Users don’t care. Their workflows cut across the boundaries we draw between teams, so a local decision about a table, filter, or bulk action can become a product-wide inconsistency.

In my conversation with Denis Cristea on UX Spotlight by Userlytics, I described how this happens:

We have this notion in modern software companies around squads and how a squad will own a particular surface area in a product. You’ve got your product manager, product designer, engineering lead, and then a bunch of engineers. So that’s your classic triad and team makeup. Theoretically everyone owns their roadmaps, talks to customers, and decides what to build.

Users don’t just work in one module. Users often work in multiple modules. So they’re already crossing the org chart, if you will. […] When thinking about the entire user experience, you already have to coordinate across different teams.

Meanwhile, you’ve got another module, another group, another team who wants to work on something similar, but they’re not talking to each other. When that happens, that’s when you get the inconsistent user experience. They might solve the same interaction differently.

A design system standardizes the components each squad uses. Weekly critique lets designers see the decisions being made across those squads before separate implementations harden.

I used the example of bulk actions at BuildOps:

The other thing that we’ve been doing a lot on my team at BuildOps, the design team, is the weekly design crit. That’s a way for us to keep the connective tissue together and ensure that the experience across the different modules stays as consistent as we can.

Going back to the bulk actions example, if one team needs it and a designer builds that experience, other designers will see it and say, “Okay, that will actually help my area too. After you design it and create the components, let me take that and put it in my area too, and argue with my product manager to prioritize that work.”

Critique coordinates the product while the squads remain autonomous. It gives teams a shared view of unfinished decisions and a place to resolve them before users have to deal with the seams.

Product managers can use the same ritual:

I would recommend that product managers think about implementing something that designers do, which is critiques. I don’t think product managers have this ritual of sharing what they’re working on and how they’re thinking through problems.

When you build a culture of sharing and oversharing, and also wanting to make everyone else’s work better by giving them good constructive feedback, that’s when the whole product is going to get lifted up.

Quotes lightly edited for clarity.